Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #38913 > unrolled thread

multiple 2.7.3 versions?

Started byRobin Becker <robin@reportlab.com>
First post2013-02-15 10:53 +0000
Last post2013-02-16 01:24 +1100
Articles 5 — 4 participants

Back to article view | Back to comp.lang.python


Contents

  multiple 2.7.3 versions? Robin Becker <robin@reportlab.com> - 2013-02-15 10:53 +0000
    Re: multiple 2.7.3 versions? Roy Smith <roy@panix.com> - 2013-02-15 09:00 -0500
      Re: multiple 2.7.3 versions? Robin Becker <robin@reportlab.com> - 2013-02-15 14:33 +0000
      Re: multiple 2.7.3 versions? Ned Deily <nad@acm.org> - 2013-02-15 14:17 -0800
    Re: multiple 2.7.3 versions? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-16 01:24 +1100

#38913 — multiple 2.7.3 versions?

FromRobin Becker <robin@reportlab.com>
Date2013-02-15 10:53 +0000
Subjectmultiple 2.7.3 versions?
Message-ID<mailman.1801.1360925614.2939.python-list@python.org>
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


>>>> 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_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__']
>>>>
-- 
Robin Becker

[toc] | [next] | [standalone]


#38919

FromRoy Smith <roy@panix.com>
Date2013-02-15 09:00 -0500
Message-ID<roy-78F8C4.09000115022013@news.panix.com>
In reply to#38913
In article <mailman.1801.1360925614.2939.python-list@python.org>,
 Robin Becker <robin@reportlab.com> wrote:

> 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.

[toc] | [prev] | [next] | [standalone]


#38923

FromRobin Becker <robin@reportlab.com>
Date2013-02-15 14:33 +0000
Message-ID<mailman.1809.1360938811.2939.python-list@python.org>
In reply to#38919
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.
-- 
Robin Becker

[toc] | [prev] | [next] | [standalone]


#38963

FromNed Deily <nad@acm.org>
Date2013-02-15 14:17 -0800
Message-ID<mailman.1850.1360966674.2939.python-list@python.org>
In reply to#38919
In article <511E4734.9010409@chamonix.reportlab.co.uk>,
 Robin Becker <robin@reportlab.com> wrote:

> 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.

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.

-- 
 Ned Deily,
 nad@acm.org

[toc] | [prev] | [next] | [standalone]


#38922

FromSteven D'Aprano <steve+comp.lang.python@pearwood.info>
Date2013-02-16 01:24 +1100
Message-ID<511e4534$0$29971$c3e8da3$5496439d@news.astraweb.com>
In reply to#38913
Robin Becker wrote:

> 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.


-- 
Steven

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web