"M.-A. Lemburg" wrote:
...
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.
I disagree for a variety of reasons: * implementation language and Python inheritance semantics are almost completely distinct. After all, we have Python implementations in a variety of languages with minor incompatibilities. Python could have a proper type/class merging even if it were written in assembly language. So let's leave implementation language aside. * there is a hell of a lot we can do to make the type/class split less visible without a major rewrite. For instance, lists could have a __getitem__ method so that they "act like" instances. Instances could return their methods in a dir() so that they "act like" built-in objects. So there is no reason to wait for a complete rewrite to start on this path. * It may even be the case that we can get from here to complete merged type/class semantics WITHOUT a rewrite. If a mad genious had not written stackless Python I would have sworn up and down that stackless Python would require a Python rewrite. It didn't. If another slightly less mad genious had not integrated ints and longs I would never have believed it possible without another rewrite. Someone needs to do an analysis of what it takes to merge types and classes and *demonstrate* that it requires a rewrite rather than *asserting* that it requires a rewrite. In other words, let's stop sprinkling the "major rewrite" pixie dust on hard problems and instead decide where we want to go and how we want to get there!
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.
I don't know what you mean by a "low-level strategy" for classes. It's not like we can somehow use C++ vtables without giving up Python's dynamicity. Python's class handling is about as low-level as it can get in my humble opinion.
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.
Of course that's where we want to go but it doesn't avoid the backwards compatibility problems. We can do this today using proxying.
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.
We can easily do this today.
Dito for numbers (and division strategies).
There's no way I'm going to let you get away with that little sleight of hand. How is inheritance holy water going to allow us to change the semantics of: 5/2 without breaking code?? The same goes for a.b = 5 versus a.B = 5 C++ does not help. Inheritance does not help. Pluggable compilers do not help. We *will* break code. We just need to decide whether to do it in a thoughtful way that gives people a chance to migrate or put off decisions until the last possible moment and then spring it on them with no between-version upgrade path.
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.
When you change defaults you break code. Keeping the old functionality around is barely helpful. Nobody has EVER proposed a change to Python where something that was previously possible is now made impossible. So whatever our strategy, the PROBLEM is changing defaults. The solution is telling people what defaults are changing in what timeline and discouraging them from depending on the old defaults.
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 ;-)
Sounds mythical. I'm trying to take it out of the realm of fluffy clouds and bring it into the world that people can plan their businesses and coding strategies around. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html