Paul Prescod wrote:
Python 3K. It is the repository for our hopes and dreams. We tend to invoke it in three different situations:
1. in delaying discussions of gee-whiz features (e.g. static type checking)
2. in delaying hairy implementation re-factoring that we don't want to undertake right now.
3. in delaying painful backwards-compatibility breakage
I think it is somewhat debatable whether we really need to or should do these three things all at once but that's a separate discussion for another day. (the other experiment may inform our decision)
Marc-Andre Lemburg replied:
I think will simply be a consequence of doing a complete rewrite of the interpreter for Py3K. AFAIR, the only truely feasable solution would be doing the rewrite in a widely portable subset of C++ and then managing classes at that level.
Moving to a common and very low-level strategy for classes will allows us to put even the most basic types (strings and numbers) into an inheritence tree.
Differences like the ones between Unicode and 8-bit strings would then flesh out as two different subclasses of a generic string type which again is based on a generic sequence type.
The same could be done for dictionaries: special ones for just string keys, case insensitive lookups, etc. could all be subclasses of a generic mapping class.
Dito for numbers (and division strategies).
By following this principle there won't be all that much breakage, since the old functionality will still be around, only the defaults will have changed.
Add to this pluggable compilers and ceval loops, plus a nice way of configuring the lot on a per-module basis and you're set. (Ok, it's a fluffy clouds image, but you get the picture ;-)
Good job in channeling me, Marc-Andre! I'm sure that's not exactly how it's going to be, but on the face of it, this sure sounds like a reasonable possible route. Do you want to be the author for PEP-3000? --Guido van Rossum (home page: http://www.python.org/~guido/)