Paul Rubin wrote:

Christian Tismer <tismer@tismer.com> writes:

Now I'm trying to do my second answer to this.

...

...

I think that local declarations and type hints are useful language improvements for more reasons than helping generate fast code...

[me, arguing against introduction of new features, introducing many fruitless discussions...]

Yes, if you want to implement an extension of this type it's better to just pick out a way to do it and code it up, than to spend weeks posting netnews about different possible methods. There's also a nice characteristic of experimental implementations, that if you don't like how a feature works out, you can change it, unlike if it gets into a real Python release and people start depending on it. However, I can understand your approach of wanting to leave it out completely at first and possibly add it later if it's needed.

I guess that something will be needed sooner or later, also that we will implement some extensions raher soon, but not publishing them as a valid langugage extension. It is great to keep the flexibility as you mentioned, and this project will need several iterations of many constructs. I think I should have mentioned Extreme Programming, earlier. One necessary is to do without lots of fixed design decisions. It is urgent to be flexible and open to new ideas. In the sprint, we will probably go many different ways at the same time, and drop most of them, soon. Our way of examinining new ways of programming will be as extreme as the principles of extreme programming. There is for sure no other way. [conservative about changing language]

I think you should feel willing to take some liberties with the language if it makes your implementation cleaner. A lot of the weird corners of Python seem to me to be implementation hacks based on CPython internals anyway. Plus, I've mentioned that coding in Python gives me something like the joy that I imagine that the 1960's Lisp hackers must have felt. The language itself is in similar shape to 1960's Lisp, with just two implementations (CPython and Jython), both of them interpreters. If the development of native-code Python compilers results in some language evolution like it did for Lisp, that's natural and not a bad thing. However, it all depends on what your goals are.

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...

I don't personally see a pure, faithful, exact reimplementation of a static target whose existing implementation is free and works perfectly well on a wide range of platforms as being something I'd want to devote precious volunteer energy to. It's much more interesting to be able to expand the boundaries of what's been done before (as Stackless expanded boundaries). However, YMMV.

We will try to implement Python as exact and clean as possible. The langage should be implemented completely. At the same time, as much as possible should become pluggable. It will be possible to have MiniPy without floats, without longs, without Unicode, without generators, without bool, without enums, it will be possible to have a Python that cannot generate any new types and classes, and so on. Modules which depend on these features will then not work. 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. positively yours -- 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/