(copying to pypy-dev since this is an incentive) Paul Rubin wrote:

Christian Tismer <tismer@tismer.com> writes:

...

You know what my goals are. Smaller, more flexible, faster, easier to change, easier to maintain, easier to keep backwards compatible, more portable due to less C code, down-sizeable by features (which is most difficult), the full catastrophe...

Well ok, it wasn't clear before what the entire set of goals were.

...

We will try to implement Python as exact and clean as possible. The langage should be implemented completely.

Now Paul is nailing thing down :-)

Are you going to try to keep the C API backwards compatible?

I wish to, but I cant guarantee it. This is a matter of experimentation. Fore sure, we will try to build a version that adheres to the C API, at least in the early bootstrap phase, we really need to do so, in order to use "borrowed" internals and extensions. It then depends on experience to be gathered, how much conformance to the C API costs. If it turns out to be much more efficient to use a different API, and maybe a radical change of internal data structures as well, then TiPy (randomly picked name from all the proposals :) is the first chance to try such new ways at all. This can lead to a compatibility layer (maybe hard to implement), and these insights may become proposals to change core Python as well. It is also thinkable to have options in TiPy which make even this configurable at boot time, and people can decide whether they want it compatible or faster. Some of the "internal" API like compiler related functions and stuff from ceval.c will most probably be changed, anyway, but the common API will be as it is now. This is where we start with.

Are you going to include exact implementations of currently not-really-documented features such as metaclasses?

Absolutely. I'm using metaclasses very much, and I also will chime a compatible patch in, which allows to use slots in metaclasses. I need that, and Stackless has it.

Will stuff like frame objects still work as documented? Do you expect to be able to run the current version of pdb.py without changes?

Yes, for the first round, frames should be rather like they are now. They will get more interfaces to be manipulated by Python code. pdb.py should run as it is now. I know there is an issue with Psyco, which doesn't create frames all the time. This is an issue that need thorough discussion and design.

I don't think you should necessarily hold yourself to any of the above, but that's just me.

If the above can be achieved for a reasonable price, then we really should try. If it hurts too much, then it may be easier to change the rest of the world :-)

...

It will be a major amount of work to deduce the dependencies of features, and how to arrange them in a scalable shape. I do believe that the core group will help us with that.

I'm pretty excited by the project. I think you're going to push the limits of the Python language harder than they've ever been pushed against before. And you'll be in a unique position to actually remove the limits when you hit them, rather than having to work around them. I hope you'll trust yourself to use such opportunities when it's right to do so.

Thanks for the encouragement. I hope to to as well as possible. Not loosing chances to stay compatible, at the same time not loosing good new opportunities by sticking too much with old principles. This is not easy and a balancing act. Something that I could not do alone, and I'm happy that there are so many supporters and people going to help. I'd-love-to-have-*you*-in-that-group-too -- chris -- Christian Tismer :^) <mailto:tismer@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/