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