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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4