Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #38913 > unrolled thread
| Started by | Robin Becker <robin@reportlab.com> |
|---|---|
| First post | 2013-02-15 10:53 +0000 |
| Last post | 2013-02-16 01:24 +1100 |
| Articles | 5 — 4 participants |
Back to article view | Back to comp.lang.python
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
| From | Robin Becker <robin@reportlab.com> |
|---|---|
| Date | 2013-02-15 10:53 +0000 |
| Subject | multiple 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]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2013-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]
| From | Robin Becker <robin@reportlab.com> |
|---|---|
| Date | 2013-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]
| From | Ned Deily <nad@acm.org> |
|---|---|
| Date | 2013-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]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-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