[PYTHONMAC-SIG] Future stuff for the Alpha python mode

[Guido van Rossum]

> It is taking me a bit longer than I planned to get out another version of
> the python mode for Alpha, so I thought I would tell you what I have planed
> and get some feedback.

OK, you asked for feedback -- here it is.

First, I've been using your Python mode for Alpha quite a bit now, so
here are some things based on real use.

My main gripe is that I don't see an obvious way to change the default
indentation the way I want to.  I'm not very experienced in using
Alpha, so maybe it's there somewhere, but I didn't find anything
obvious.  I want a feature that Emacs mode has, and which is necessary
for compatibility with files originating on Unix: while a tab
character is worth 8 spaces, the block indentation is worth 4 spaces.
So you will find that the first level is indented with 4 spaces, the
2nd level is indented with a single tab, the 3rd level is indented
with a tab plus 4 spaces, the 4th level with 2 tabs, and so on.  This
style is used extensively by many standard library modules -- in fact
it is the default style for Emacs nowadays.  Notice that setting the
*tab stop* to 4 spaces is the wrong thing to do here: it would make
the 1st and 2nd level indistinguishable.  Please don't tell me that I
have to convert all tabs to spaces.

My other gripe is that the coloring is a bit too colorful to my taste.
For instance, it colors parentheses -- well, this is okay, I suppose
-- but it also colors various plain identifiers in ways that are more
confusing than useful.  In particular, it seems to know most (but not
all!) standard methods and built-in function names, and will color
these names even where they occur as local variables or methods of
unrelated objects.  I'd rather not see identifiers colored at all,
except in clearly recognizable syntactical positions (e.g. Emacs
colors the name of a function or class definition different).  I've
also noticed that the coloring is very sensitive to backspacing --
oftentimes, when colors look really weird, typing Control-L will fix
them.

> What has eaten up the most time is overhualing the template insertion
> facilities that are avaliable in Alpha.  Included in the alpha distribution
> is a set of files that support a template facility known as ElectricAlias.

I've seen this in the HTML mode, and personally, don't care for them.
I'm so used to typing the full syntax that remembering the key
sequences for the templates rarely saves me any time.

> This hasn't been touched since '92, and Alpha author has expressed surprise
> that it still works given all the changes alpha has undergone since then.
> There is a grad student at Havard that has written a lot of code for alpha,
> much of which has eventually been incorporated into the distribution over
> the years, who publishes a set of utilities know as "VincesAdditions".  It
> includes a very nice set of utilities for creating templates, however, some
> of the things he does make it hard to use with python.  I've been working
> on a version that let's you change things so they are more conducive to
> working in python.  This is just about done and could be released
> separately (along with some python templates) if anyone is interested.
> 
> A number of people found the colorizing excessive and/or garrish in the
> choice of colors.  If you have come up with your own set of colors that you
> like, and/or you have turned off colorizing of certain groups of words,
> please pass this back to me.  I'm working on making this more sanely
> customizable.

Ah thanks.  Disabling coloring for the "known functions and methods"
by default would go a long way for me...

> I've written routines that parse the include and from...includ...
> statements in such a way that option-clicking on the titlebar will produce
> a pop-up of the module names.  Selecting one of these will open the
> associated file.  You can also cmd-double click a module name and open its
> file. (note: Alpha 6.5 has a bug in its pop-up routine, you might have to
> uses a later beta version --usally pretty stable)

Ah this is cool (except for the Alpha beta).

> Two things on this, one - I had to make a copy of the search paths from the
> pref app, do people modify this a lot?  Can I use an AE to get the current
> settings.  Secondly, some of the modules do not seem to have veiwable
> source code, (they exist as shared Libraries?)  I just  inform you that
> these modules can't be viewed.  Are there other such modules in places
> other than the Plug-ins folder?  Can you query python for the interface?
> (hopefully with a AE so I could open a window with the interface).

I believe the Python interpreter itself has very little AE support
(you can write AE-aware Python scripts, but that's another thing), but
Jack should answer this one, really.  The modules without viewable
source code most likely are extensions written in C.  Some will be
built in (e.g. sys), others can be available as shared libraries
(e.g. _tkinter) -- but on the 68k, unless you want to use CFM68k, all
such modules are built in.  Python's "imp" module has an interface
find_module('name') which gives details about what kind of module it
is (without actually importing it).  See the library reference manual
section describing imp.  To find the current module search path, use
sys.path.

> A couple of people have asked about string colorizing, Alpha's string
> colorizing is built in, delimited by double quotes and constrained to be on
> a single line, so I don't think I can correct this, however, as I mentioned
> in a recent reply;
> >
> >>
> >>...The one thing
> >>that would be nice to have (I don't know how easy it is to do this in
> >>Alpha) would be to have strings colored properly. I looks like it only
> >>handles double quote strings, and not single quotes or triple quotes.
> >>When I use Emacs Python mode, I find that the syntax coloring of strings
> >>is probably the most useful part of syntax coloring: you can see right
> >>away when you've left off a terminating quote.
> >>
> >I have not figured out anyway to do this yet, the string hilighting that
> >Alpha supports is built in and locked to double quotes occuring on a
> >single line.  Perhaps I can come up with a string-delimiter balance
> >function similar to the paren,brace,baracket balancer that momentarily
> >hilites the opening delimiter when you type the close.
> 
>  Would that be Okay?

Seems fine for me.  Are you serious that Alpha can't hilite
single-quote delimited strings?

> To support the commenting of programs, (creating and maintaing), I'am
> considering the following sheme;
> 
> A module would be parsed for definitions and any existing comments.  A file
> would be created with only these parts (i.e. definiton heads and existing
> comments--no bodies).  These files would be given the module name and a new
> extension (say .pyd), perhaps they would all end up in a "Doc" subfolder of
> the parent module's folder.  This new file would be easy to naviagate and
> add comments to.  Things like instant templates for presenting a table of
> the arguments and explantion would be provided.

Except that .pyd is a bad choice because it means "PYTHON DLL" on
Windows platforms.  Sooner or later someone cross mounting file
systems would be confused.  Maybe use .pyi for Python interface, or
.py-doc.

Not sure how this feature would be used, personally -- I'd rather keep
all my meta info in comments and doc strings in the source file rather
than in a separate file.  It also sounds like a scheme that would be
cumbersome when you're *not* using Alpha...

> Using this scheme, long comments could be kept separate from the code.  You
> would only have to merge them when you are distributing the modules.  Alpha
> could support hypertext tags between the two.  There are a lot of ways to
> go with this, any ideas?
> 
> Any feedback or other ideas welcome,
> 
> Tom Fetherston
> Pittsburgh, PA USA

--Guido van Rossum (home page: http://www.python.org/~guido/)

=================
PYTHONMAC-SIG  - SIG on Python for the Apple Macintosh

send messages to: pythonmac-sig@python.org
administrivia to: pythonmac-sig-request@python.org
=================