Tim Peters wrote:
[MAL]
... Seems that we're a bit too healthy (see MarkH's post) sometimes, i.e. there isn't all that much room for experiments.
The odds of a change making it into Python radically decreased when 1.0 hit the net, and have continued to decline (although slowly) since then. In recent years, Guido appears to me to have gotten ever more reluctant to entertain even 100% compatible changes to the internals, if they affect a delicate area of the implementation (ceval.c is the most obvious one there).
But that's "normal & healthy" <wink> too. Languages & implementations get brittle with age, and it's eventually better to start over -- if Guido didn't have Python2 plans in mind, he'd be the first language designer ever to stop where he started!
Just think of cool developments like Chris' stackless python. Experience shows that these kind of things will never make it into the distribution.
Unfortunately, circumstances piled up and Chris got distracted from that, while nobody else made time to push it in his absence. Large changes have gone in, and even more may make it into the Python1 line, but it generally takes a large or "strategic" user base, and much persistence. GregS mentioned his massive work on threads (still not all in), and I'll add the NumPy extensions (which I wouldn't be surprised to see "mainstreamed"), BarryW's string methods, and DavidA's rich comparisons.
Plus the coercion stuff that's still sleeping in one of my project subdirs (I'll have to get this done *before* 1.6 hits the shelves).
Unfortunately, maintaing patches to the dist across releases a real pain and much work, so these ideas will just sit there unused and untested. Much the same happened to gcc ... in the end corporate strength made egcs possible. Perhaps we need such a branch too ?
Don't tell, but I've always been surprised at how few people have tried to release a variant Python! The Alice version (case-insensitive names, and 1/2==0.5) is the only one that comes to mind, and the primary effect that had on today's Python is that raw expressions no longer print their value in non-interactive mode (before Alice,
1 + 2
on a line by itself caused "3" to get printed even in batch scripts; this interfered with the Alice team's favored
object.method1().method2().method3()
coding style, and Guido endured much pain to change "the real" Python to avoid a code split at that early stage of Python's life; ultimately futile, but then Alice Python didn't catch on anyway).
So there's very little Python-related history to go on here. I don't mind seeing variants, but have to predict they won't get very far. Just picture what Python 1.6V would look like if its feature set were drawn from a consensus among you, me, Christian, Greg Ewing, John Skaller and Tom Christiansen <wink>.
Actually, what I was thinking about here was a Python 2.0 branch starting now rather than in a year or so and thus leaving much room for experiments etc. The intention was the same as with egcs and gcc: to fold the enhancements back into the main branch in a few years. E.g. if Guido points us in the right direction, we could start hacking on that piece of revolutionary work now. BTW, I'd suggest using C++ with namespaces but without templates as target language. By the time Python 2.0 will hit the shelves this setup should have reached the same portability as C has now. Perhaps we could even use RTTI (run time type information) to implement optional type safety... ok, just dreaming a little ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 102 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/