A way to accommodate laguage changes

[kosh]

James Logajan wrote:

> Chris Barker wrote:
>> pain it is likely to cause by:
>>    A) Breaking old code
>>    B) Making it very difficult to write code that can run on old and new
>> version of the interpreter.
>> 
>> It seems that since (3) is the big stumbling block, perhaps we need to
>> focus our intentions on how to make not only this change, but other
>> potential changes less painful. It's too late now, but ideally, Python
>                                   ^^^^^^^^^^^^^^^^^
>  
> Not to be abrupt, but if it is too late now, why bother mentioning it?
> 
> I effectively stopped considering Python for new projects as of last
> night. I can't read Guido's mind, I don't know what other code-breaking
> changes he might be considering. I'm not sure he even knows. Where else is
> he going to be convinced that "evil" lies in the language and needs to be
> exorcised?

It is not too later until python 2.2 ships. Disregarding large parts of the 
python community is not a good idea since it very easily could lead to a 
language fork. While I do want it to be easier for people that don't 
understand division to be able to do it changing the meaning of an existing 
piece of syntax seems like a very bad idea. / should have remained the 
same. // should have had the new behavior. Once the language is out you 
really can't make those kind of breaking changes. At the very least it 
should be called python 3.0 for that reason since it does break backwards 
compatibility. On the whole with zope using 2.1 now I expect I will be 
using 2.1 for a good while.