On 1/15/2014 7:07 AM, Robin Becker wrote:
On 13/01/2014 15:28, Chris Angelico wrote:
..........
It's even worse than that, because adding 'nonlocal' is not a bugfix.
So to be committed to the repo, it has to be approved for either 2.7
branch (which is in bugfix-only maintenance mode) or 2.8 branch (which
does not exist). Good luck. :)
.......
fixing badly named variables is not a bug fix either, but that has
happened in python 2.7. A micro change release changed
compiler.consts.SC_GLOBAL_EXPLICT
to
compiler.consts.SC_GLOBAL_EXPLICIT
this is a change of api for the consts module (if you regard exported
variables as part of its api),
A bug is generally a discrepancy between the doc the defines a version
of the language and the code that implements that version. Yes, code
fixes break code that depends on the bug, which is why tests should be
run with bug-fix releases, and why some bug fixes are treated as
enhancements and not back-ported. They also fix current and future code
written to the specification.
Since the compiler.consts submodule is not documented, I believe it was
regarded as an internal module for use only by the pycodegen and symbols
modules. The misspelling was introduced in the patch for
http://bugs.python.org/issue999042
which also introduced SC_GLOBAL_IMPLICIT, correctly spelled. EXPLICT was
fixed in all three modules by Antoine Pitrou in
http://bugs.python.org/issue15212
In any case, I estimate the impact of backporting a major new feature
like a new keyword to be at least 100000 times that of this spelling fix.
> but that didn't count for the developers.
If you are suggesting that developers casually violate out policy of
only bug fixes in microreleases, that is unfair and false. It is mostly
users who push at us to backport their favorite new feature. Antoine
strongly supports and enforces the policy, as do I.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
