Partial Parsing of Python

holger krekel pyth at devel.trillke.net
Mon Jul 1 04:45:13 EDT 2002


Peter Eckersley wrote:
> [me]
> > Actually the REAL problem to solve first is to have Multi-Line editing. 
> > Then all sorts of partial parsers *and* partial evaluation.  Python is
> > just too damn dynamic to have that one easily.
> > 
> 
> Oh, which reminds me of something else.  I also have problems with
> side-effects ("heisenberg" effects)-- it will be necessary to get rid of
> these.  

But you certainly know that this isn't generally possible? Take

    somestrangefile.read().<tab>

for example.  The next best bet (read: hack) is to fork off a process
which does the evaluation of an Subexpression.  This way you'd catch
90% of in-place modifications.  Doesn't work for files.  But then how
often are you doing dynamic network/file communication on the commandline?   
This might change once we have multiline editing.  But one after three
others :-) 

> My feeling was that this could be done using purity analysis and
> return-type annotation.  Many of the important cases can be handled by
> just adding information about the builtin modules, but it might also
> be possible to do generalised python purity analysis.  Has anyone tried
> this?

Not me. I don't even now exactly what you are talking about :-)

> > So what to do? Our idea at EuroPython was to use PyGame (the wrapper
> > around SDL) to get rid of the uglyness and restrictiveness of 
> > readline and curses alltogether.  We want to have a REAL playground 
> > and concentrate on our ideas.
> 
> Hmmm, I agree that one needs to escape readline/curses - but SDL sounds
> like overkill, since I imagine you'll have to re-implement lots of basic
> widgets on top of it.  I picked GTK, and have found it generally
> suitable, despite a few quirks.

Reflecting our EuroPython discussion, GTK or QT seems to be heavyweight.  
We don't need widgets but the ability to put scalable fonts on a screen.  
Having sprites and game-level performance can't hurt either :-)
It's very worth a try. 

> A copy of my (pre-pre-alpha) code is available at
> http://www.cs.mu.oz.au/~pde/src/gush-0.003.tgz (it's currently called
> gush - the Grand Unified SHell - although I think somebody might have
> already used that name), so you can see how GTK works for this.  All
> completions except obj.attr<cursor> are currently turned off.
> 
> In order to run it, you'll need the latest version of pygtk (1.99.10 or
> later), from ftp://ftp.gtk.org/pub/gtk/python/v2.0/ .

I see.  I'll check that out after i caught up with my post-europython
task list.  

    holger





More information about the Python-list mailing list