2.6, 3.0, and truly independent intepreters

[Terry Reedy]

Glenn Linderman wrote:
> On approximately 10/24/2008 8:39 PM, came the following characters from 
> the keyboard of Terry Reedy:
>> Glenn Linderman wrote:
>>
>>> For example, Python presently has a rather stupid algorithm for 
>>> string concatenation.

Yes, CPython2.x, x<=5 did.

>> Python the language has syntax and semantics.  Python implementations 
>> have algorithms that fulfill the defined semantics.
> 
> I can buy that, but when Python is not qualified, CPython should be 
> assumed, as it predominates.

People do that, and it sometimes leads to unnecessary confusion.  As to 
the present discussion, is it about
* changing Python, the language
* changing all Python implementations
* changing CPython, the leading implementation
* branching CPython with a compiler switch, much as there was one for 
including Unicode or not.
* forking CPython
* modifying an existing module
* adding a new module
* making better use of the existing facilities
* some combination of the above

 > Of course, the latest official release
> should probably also be assumed, but that is so recent,

People do that, and it sometimes leads to unnecessary confusion.  People 
routine posted version specific problems and questions without 
specifying the version (or platform when relevant).  In a month or so, 
there will be *2* latest official releases.  There will be more 
confusion without qualification.

> few have likely 
> upgraded as yet... I should have qualified the statement.

* Is the target of this discussion 2.7 or 3.1 (some changes would be 3.1 
only).

[diversion to the side topic]

>> If there is more than one reference to a guaranteed immutable object, 
>> such as a string, the 'stupid' algorithm seem necessary to me.  
>> In-place modification of a shared immutable would violate semantics.
> 
> Absolutely.  But after the first iteration, there is only one reference 
> to string.

Which is to say, 'string' is the only reference to its object it refers 
too.  You are right, so I presume that the optimization described would 
then kick in.  But I have not read the code, and CPython optimizations 
are not part of the *language* reference.

[back to the main topic]

There is some discussion/debate/confusion about how much of the stdlib 
is 'standard Python library' versus 'standard CPython library'.  [And 
there is some feeling that standard Python modules should have a default 
Python implementation that any implementation can use until it 
optionally replaces it with a faster compiled version.]  Hence my 
question about the target of this discussion and the first three options 
listed above.

Terry Jan Reedy