pyjamas 0.8alpha1 release

Terry Reedy tjreedy at udel.edu
Wed May 18 21:13:51 EDT 2011


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




More information about the Python-list mailing list