Tim Peters wrote:
[MAL]
... I think this will simply be a consequence of doing a complete rewrite of the interpreter for Py3K.
Not just to be my usual self <wink>, but I do see a from-scratch rewrite as being less likely as the years go by. There's nothing I know of in Guido's plans that can't be done incrementally instead -- and if he doesn't either, selling a total- rewrite project to an employer is probably impossible.
The most successful projects I've seen and been on *did* rewrite all the code routinely, but one subsystem at a time. This happens when you're tempted to add a hack, realize it wouldn't be needed if an entire area were reworked, and mgmt is bright enough to realize that hacks compound in fatal ways over time. The "ain't broke, don't fix" philosophy is a good guide here, provided you've got a very low threshold for insisting "it's broke" <0.4 wink>.
As I mentioned in the posting, the idea was from the "fluffy clouds" area. The rewrite would only involve the core type system and perhaps the core interpreter layout (parser, compiler, etc. all wrapped in classes) -- most of the existing code would be reusable. The idea behind this is somewhat like what you do when starting out a project based on a few simple functions and then reorganizing the code into a class-based approach. There's no need to rewrite all the type internals, just the type interfaces. Python has long reached a level of complexity that is counter- productive when it comes to adding new extension types. Just think of all the problems people have with coercion, the integration of user defined and internal types, the missing links between types and classes, etc. etc. BTW, why all the talk about "employers" ? Much of Python's code base was written without any employer knowing about it ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/