On 5/18/2011 9:42 AM, lkcl wrote:
he's got a good point, terry. breaking backwards-compatibility was a
completely mad and incomprehensible decision.
I see that I should take everything you (or Harris) say with a big grain
of salt;-). You just gave me a lecture about the impossibility of doing
everything one might like with limited all or mostly volunteer
resources. So surely you can comprehend that the same applies to CPython
also.
Given that Python 1.0/1 had some design defects that became evident with
experience and simply lacked some things thought of later, I can think
of several options:
1. Never fix them.
2. Add fixes, but keep the old stuff. If the old and new ways are
somewhat compatible, keep both available at the same time*. If they
conflict, keep old as default and make new available on demand (future
import)#. This was 2.x strategy.
2A. Make new ways default and have past imports.
3. Gradually delete old. This was and is policy mostly for library.
4. Delete lots of old ways all at once. This was 3.x.
What would you have had us do instead?
* Example: old and new style classes. Problems: the differences are hard
to learn and hard to remember; they are sometimes irrelevant, but
sometimes not; if you import and instantiate a class, you may not know
which you have.
# Example: int division. Problems: having the deprecated meaning be
default is a damn nuisance; learning it is a stupid burden; if you see
'a/b' in a snippet extracted from a file, you do not know what it means.
2.7 is really the end of the road for strategy 2. Keeping obsolete
features around is a learning burden for most newbies and a maintenance
burden for developers.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
