[pypy-dev] Stuff that already exists in Python
Christian Tismer
tismer at tismer.com
Mon Jan 13 04:00:37 CET 2003
Guido van Rossum wrote:
> Off the top of my head, there's quite a bit of Python that has been
> reimplemented in Python available already:
Yes, I know, and I appreciate it very much!
> - Nearly all the import machinery (less the new PEP 302 stuff) is
> implemented in ihooks.py.
Absolutely. The amount of Python-coded stuff
makes me so confident that this project is
doable at all.
> - Command line reading is in code.py and codeop.py
This is a pleasure, well known.
> - A bytecode compiler is in the compiler package
Very good, I know. Finally, it is calling back
into the C part, for some AST stuff and the
parsetok. Not too har to implement, despite
the fact that character-wise operation in Python
isn't very effective at all. But there's sre.
> - A re-based tokenizer is in tokenize.py
That's what I've overlooked. I thought we'd have
to implement all of the parsetok stuff, since
(as far as I analysed it) the compiler package
calls back into the parser module, which still
uses parsetok.
This also touches one of my weak points:
Is it good to replace C code by something
which is depending on another special module
like sre?
This makes sre into something crucial to this
re-implementation. But I'm not sure if this
is a good way to go.
I'm also not sure if it is good to re-implement
certain modules using the common Python tricks
and optimizations. To some extent, I have the
impression that doing it the simple way, basically
as done in C, would fit the optimizations of
Psyco better. But that is an open question
until we get some feedback from Armin Rigo.
> - I think that a Python implementation of marshal is (or was) part of
> Jython; I vaguely recall writing one when Jython was young
Thanks a lot, I will try to look that up.
> The parser (needed by the bytecode compiler) is missing, but it's not
> particularly difficult to write.
Yes, I've spent some hours figuring that out.
It is sitting in the parser extension, slightly
different from the builtin one.
For a first implementation, I think to re-code
anything necessary quite directly in Python.
But then, re-coding again gives us ways to
become more flexible concerning the parser, if
we don't have the restrictions of C any longer.
Well, this is a long way to Tipparary.
> Not sure if this helps, but it's all I can contribute right now.
This is very helpful, thanks a lot for supporting
this project. I'm happy that you are following it,
positively.
This is how it is meant to be:
We are trying a new approach, and we want to do
this as support for Python's evolution, trying to
find a way to simplify it and to make its development
easier and faster.
If we succeed, this may become a new way for Python.
If not, then we are probably closing a dead end.
Both possible results are able to help.
All the best -- chris
--
Christian Tismer :^) <mailto:tismer at tismer.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
More information about the Pypy-dev
mailing list