multiple 2.7.3 versions?

[Robin Becker]

A colleague reports that this python from a recent Ubuntu x86_x64

Python 2.7.3 (default, Sep 26 2012, 21:51:14)

contains a fix of this bug

http://bugs.python.org/issue15212

however, all of my other Python 2.7.3s seem to lack this 'fix'.

I would have thought that for a fix to appear in python we should at least get a
micro version change, but the text here

http://docs.python.org/2/faq/general.html#how-stable-is-python

The developers issue “bugfix” releases of older versions, so the stability of existing releases gradually improves. Bugfix releases, indicated by a third component of the version number (e.g. 2.5.3, 2.6.2), are managed for stability; only fixes for known problems are included in a bugfix release, and it’s guaranteed that interfaces will remain the same throughout a series of bugfix releases.

would seem to indicate that changes to the spelling of a public variable would
not change even with a change to the micro level so my colleague's machine
should not produce this output

['CO_FUTURE_ABSIMPORT', 'CO_FUTURE_DIVISION', 'CO_FUTURE_PRINT_FUNCTION',
'CO_FUTURE_WITH_STATEMENT', 'CO_GENERATOR', 'CO_GENERATOR_ALLOWED',
'CO_NESTED', 'CO_NEWLOCALS', 'CO_OPTIMIZED', 'CO_VARARGS', 'CO_VARKEYWORDS',
'OP_APPLY', 'OP_ASSIGN', 'OP_DELETE', 'SC_CELL', 'SC_FREE',
'SC_GLOBAL_EXPLICIT', 'SC_GLOBAL_IMPLICIT', 'SC_LOCAL', 'SC_UNKNOWN',
'__builtins__', '__doc__', '__file__', '__name__', '__package__']

where the originally mis-spelled SC_GLOBAL_EXPLICT has changed to
SC_GLOBAL_EXPLICIT.

Can someone explain how this 'fix' is leaking out onto his machine? On all the
other machines I have access to I'm seeing something similar to this

C:\tmp>python
Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.

from compiler import consts
dir(consts) ['CO_FUTURE_ABSIMPORT', 'CO_FUTURE_DIVISION', 'CO_FUTURE_PRINT_FUNCTION', 'CO_FUTURE_WITH_STATEMENT', 'CO_GENERATOR', 'CO_GENERATOR_ALLOWED', 'CO_NESTED', 'CO_NEWLOCALS', 'CO_OPTIMIZED', 'CO_VARARGS', 'CO_VARKEYWORDS', 'OP_APPLY', 'OP_ASSIGN', 'OP_DELETE', 'SC_CELL', 'SC_FREE', 'SC_GLOBAL_EXPLICT', 'SC_GLOBAL_IMPLICIT', 'SC_LOCAL', 'SC_UNKNOWN', '__builtins__', '__doc__', '__file__', '__name__', '__package__']

 

[Roy Smith]

A colleague reports that this python from a recent Ubuntu x86_x64

Python 2.7.3 (default, Sep 26 2012, 21:51:14)

contains a fix of this bug

http://bugs.python.org/issue15212

however, all of my other Python 2.7.3s seem to lack this 'fix'.

I would have thought that for a fix to appear in python we should at least
get a
micro version change, but the text here

http://docs.python.org/2/faq/general.html#how-stable-is-python

I ran into a similar issue just recently (see this thread:
http://tinyurl.com/ccvwj3e). The Ubuntu folks seem to be cherry-picking
bugfixes and releasing them with the same version numbers.

 

[Steven D'Aprano]

A colleague reports that this python from a recent Ubuntu x86_x64

Python 2.7.3 (default, Sep 26 2012, 21:51:14)

contains a fix of this bug

http://bugs.python.org/issue15212

however, all of my other Python 2.7.3s seem to lack this 'fix'. [...]
Can someone explain how this 'fix' is leaking out onto his machine?

The major Linux distros, including Ubuntu, tend to release their own bug
fixes independently to official Python releases.

I guess that the fix your colleague is seeing is from Ubuntu.

 

[Robin Becker]

On 15/02/2013 14:00, Roy Smith wrote:
........

I ran into a similar issue just recently (see this thread:
http://tinyurl.com/ccvwj3e). The Ubuntu folks seem to be cherry-picking
bugfixes and releasing them with the same version numbers.

yes it seems that must be the case. Maybe someone at python.org should tell the
ubuntists not to do that.

However, even a proper 2.7.4 release shouldn't change the interface (ie rename
module variables). That must be down to someone at python.org. I guess because
2.7 is the last minor release of the 2.x series that the stability requirements
have been dumped.

Luckily, our code didn't launch any missiles because of this 'fix'. I always
recommend people to build their own python for exactly this reason.

 

[Ned Deily]

On 15/02/2013 14:00, Roy Smith wrote:
.......
yes it seems that must be the case. Maybe someone at python.org should tell
the
ubuntists not to do that.

However, even a proper 2.7.4 release shouldn't change the interface (ie
rename
module variables). That must be down to someone at python.org. I guess
because
2.7 is the last minor release of the 2.x series that the stability
requirements
have been dumped.

Luckily, our code didn't launch any missiles because of this 'fix'. I always
recommend people to build their own python for exactly this reason.

If you think this change will cause significant user compatibility
problems in the field, you should report it to the Python bug tracker
right away. There may still time to deal with it before the next 2.7
maintenance release, 2.7.4, which has been delayed somewhat.