a couple IDLE questions

[Guido van Rossum]

"Mark Hammond" <MHammond at skippinet.com.au> writes:

> >    1.  It seems to ignore my PYTHONSTARTUP environment variable.  Any
> >        particular reason why?
> 
> Pythonwin does too - it is far from clear that this would be a good idea.
> People have often noticed this, but very few have asked for it to be
> changed.  IMO, an IDLESTARTUP would be a better solution.

Actually, the CVS version of IDLE looks for IDLESTARTUP, and if that
isn't set, it looks for PYTHONSTARTUP.  Probably too few people have
used the CVS version though to know if the latter is a good idea.

> >    2.  I point the above variable at ~/.pythonrc.  When I open that file,
> >        it doesn't colorize it, I suppose since it doesn't end in ".py".
> Is
> >        there a way to force it to treat a file as Python source when it
> >        normally wouldn't (like, perhaps recognizing "-*- python -*-" like
> >        Emacs does)?
> 
> Maybe, but really, is it worth the effort?  How many times do you need to
> edit Python source that does not live in a .py/.pyw file?

The design of features like this is all open to suggestion.  I don't
particularly like the -*- python -*- convention (it's visual pollution 
in my eyes), but the mechanism that decides could be made
configurable, and there could be a manual override.

Of course, the simpler solution is for you to rename .pythonrc to
.pythonrc.py!

> >    3.  The class browser presents all classes and functions defined at the
> >        top level of a module.  Should it perhaps be called a module browser
> >        and be expanded to present all objects defined at the module's outer
> >        scope?

> I agree that "module browser" would be a better name.  Note that this uses
> pyclbr, and this uses the Python parser module to build its information,
> rather than importing the module.

I called it a class browser because it browse classes.  Most people
familiar with this kind of things (e.g. smalltalk) seem to call them
that.

The CVS version also shows global functions.  Perhaps it *could* be
expanded to show all globally defined names (that it can detect by
looking at the source only), but that's iffy -- and there are
questions like what should it do about an 'if' or 'for' statement at
the top level, imports, etc.

An alternative would be to have a "folding editor" for regular Python
source code.  That works a bit like an outline processor, so you
can collapse certain deeper levels of the source.  That would be
very nice, but is beyond the capabilities of Tk, so would be a major
endeavour (especially if you want it to be as fast).  Dave Winder
(Mr. Frontier) has suggested that the Frontier editor is suitable for
Python; I don't know if this has been tried out in practice, but it
would be interesting to research seriously this for CP4E.

> IMO IDLE should grow an "object browser" as well as the existing one.  The
> object browser could be used to look at any object, including a module.  By
> using an instantiated object and using standard Python introspection you get
> all this for free.  This is the approach Pythonwin takes.

I have one in the works (also based on IDLE's tree widget) but there
were a few rough edges, and I was distracted before I could check it
in.  One of these days, it'll be there...

> >When I asked for the class browser on my .pythonrc file it generated a
> >traceback
> 
> Well, dont do it then :-)  You must have a wicked .pythonrc file if you need
> the browser to manage it :-)
> 
> I agree it should not present a traceback, but dont believe it worth the
> effort to make these files browsable - it is simply not a Python module!

Actually, the class browser doesn't care which language your file
thinks it is in.  I'd like to see your .pythonrc so I can reproduce
why pyclbr.py crashes on it.

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