Is it intentional that "sys.__debug__ = 1" is illegal in Python 2.7?
In working on making Python 2.7 available in Debian and Ubuntu, we ran into two packages that fail to byte compile against Python 2.7, where they are fine in Python 2.6. The Debian bug tracker issues are: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590821 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590822 Specifically, what fails now is assignment to the __debug__ attribute of a module, e.g. sys -- *not* builtin __debug__. % python2.6 Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) [GCC 4.4.3] on linux2 Type "help", "copyright", "credits" or "license" for more information.
__debug__ = 1 File "<stdin>", line 1 SyntaxError: can not assign to __debug__ import sys sys.__debug__ = 1
% python2.7 Python 2.7.0+ (release27-maint:83294, Jul 30 2010, 15:49:51) [GCC 4.4.3] on linux2 Type "help", "copyright", "credits" or "license" for more information.
__debug__ = 1 File "<stdin>", line 1 SyntaxError: cannot assign to __debug__ import sys sys.__debug__ = 1 File "<stdin>", line 1 SyntaxError: cannot assign to __debug__
I think it's actually somewhat questionable that this is now illegal. It certainly breaks at least two packages. More disturbing though is that I cannot find mention of this change in Misc/NEWS or in the tracker, so I don't actually know if this was intentional or not. It looks like Benjamin's change in r67171 was the relevant diff. Thoughts? Either way I will file a bug. IOW, if this change should *not* have been made, I think it should be reverted for Python 2.7.1 and I can patch our version of Python in the meantime. If this change is intentional, I'll file a bug against (or just fix) Misc/NEWS and the What's New. Cheers, -Barry
On Fri, Jul 30, 2010 at 1:26 PM, Barry Warsaw <barry@python.org> wrote:
In working on making Python 2.7 available in Debian and Ubuntu, we ran into two packages that fail to byte compile against Python 2.7, where they are fine in Python 2.6. The Debian bug tracker issues are:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590821 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590822
Specifically, what fails now is assignment to the __debug__ attribute of a module, e.g. sys -- *not* builtin __debug__.
% python2.6 Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) [GCC 4.4.3] on linux2 Type "help", "copyright", "credits" or "license" for more information.
__debug__ = 1 File "<stdin>", line 1 SyntaxError: can not assign to __debug__ import sys sys.__debug__ = 1
% python2.7 Python 2.7.0+ (release27-maint:83294, Jul 30 2010, 15:49:51) [GCC 4.4.3] on linux2 Type "help", "copyright", "credits" or "license" for more information.
__debug__ = 1 File "<stdin>", line 1 SyntaxError: cannot assign to __debug__ import sys sys.__debug__ = 1 File "<stdin>", line 1 SyntaxError: cannot assign to __debug__
I think it's actually somewhat questionable that this is now illegal. It certainly breaks at least two packages. More disturbing though is that I cannot find mention of this change in Misc/NEWS or in the tracker, so I don't actually know if this was intentional or not.
Well it is a reserved name so those packages that were setting it should have known that they were using undefined behavior that could change at any time.
It looks like Benjamin's change in r67171 was the relevant diff.
Thoughts? Either way I will file a bug. IOW, if this change should *not* have been made, I think it should be reverted for Python 2.7.1 and I can patch our version of Python in the meantime. If this change is intentional, I'll file a bug against (or just fix) Misc/NEWS and the What's New.
-- --Guido van Rossum (python.org/~guido)
On Jul 30, 2010, at 01:42 PM, Guido van Rossum wrote:
Well it is a reserved name so those packages that were setting it should have known that they were using undefined behavior that could change at any time.
Shouldn't it be described here then? http://docs.python.org/reference/lexical_analysis.html#identifiers -Barry
On 30/07/2010 21:53, Barry Warsaw wrote:
On Jul 30, 2010, at 01:42 PM, Guido van Rossum wrote:
Well it is a reserved name so those packages that were setting it should have known that they were using undefined behavior that could change at any time.
Shouldn't it be described here then?
http://docs.python.org/reference/lexical_analysis.html#identifiers
And raise a DeprecationWarning one release before becoming invalid syntax? Michael
-Barry
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
2010/7/30 Barry Warsaw <barry@python.org>:
On Jul 30, 2010, at 01:42 PM, Guido van Rossum wrote:
Well it is a reserved name so those packages that were setting it should have known that they were using undefined behavior that could change at any time.
Shouldn't it be described here then?
http://docs.python.org/reference/lexical_analysis.html#identifiers
Doesn't the section http://docs.python.org/reference/lexical_analysis.html#reserved-classes-of-i... make this clear enough ?
-Barry
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ggpolo%40gmail.com
-- -- Guilherme H. Polo Goncalves
First appeared in docs for 2.6 (October 02, 2008). Not sure if that is when it first because constrained this way. http://docs.python.org/library/constants.html?highlight=__debug__#__debug__ -eric -----Original Message----- From: python-dev-bounces+esnow=verio.net@python.org [mailto:python-dev-bounces+esnow=verio.net@python.org] On Behalf Of Guilherme Polo Sent: Friday, July 30, 2010 3:06 PM To: Barry Warsaw Cc: Guido van Rossum; Python-Dev Dev Subject: Re: [Python-Dev] Is it intentional that "sys.__debug__ = 1" isillegal in Python 2.7? 2010/7/30 Barry Warsaw <barry@python.org>:
On Jul 30, 2010, at 01:42 PM, Guido van Rossum wrote:
Well it is a reserved name so those packages that were setting it should have known that they were using undefined behavior that could change at any time.
Shouldn't it be described here then?
http://docs.python.org/reference/lexical_analysis.html#identifiers
Doesn't the section http://docs.python.org/reference/lexical_analysis.html#reserved-classes-of-i... make this clear enough ?
-Barry
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ggpolo%40gmail.com
-- -- Guilherme H. Polo Goncalves _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/esnow%40verio.net This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you.
On Jul 30, 2010, at 05:23 PM, Eric Snow wrote:
First appeared in docs for 2.6 (October 02, 2008). Not sure if that is when it first because constrained this way.
http://docs.python.org/library/constants.html?highlight=__debug__#__debug__
Thanks Eric, this is probably the right section of the docs to reference on the issue. I want to add two clarifications to this section: * Be more explicit that assigments to None and __debug__ are illegal even when used as attributes. IOW it's not just assignment to the built-in names that are illegal. * Add a "Changed in 2.7" to __debug__ stating that assignments to __debug__ as an attribute became illegal. From this though, I think it's clear that Benjamin's change was intentional. I will also add this to the NEWS and What's New files for 2.7. -Barry
On Sat, 31 Jul 2010 07:44:42 am Guido van Rossum wrote:
http://docs.python.org/reference/lexical_analysis.html#reserved-classes-of-i...
On Jul 31, 2010, at 08:32 AM, Steven D'Aprano wrote:
I have a small concern about the wording of that, specifically this:
"System-defined names. These names are defined by the interpreter and its implementation (including the standard library); applications SHOULD NOT EXPECT TO DEFINE additional names using this convention. The set of names of this class defined by Python may be extended in future versions." [emphasis added]
This implies to me that at some time in the future, Python may make it illegal to assign to any __*__ name apart from those in a list of "approved" methods. Is that the intention? I have always understood that if you create your own __*__ names, you risk clashing with a special method, but otherwise it is allowed, if disapproved off. I would not like to see it become forbidden.
The key phrase is "system-defined names". Since this is in the section on lexical analysis, it does not limit the contexts in which such names are reserved for the system; they are potentially special *everywhere* (as variables, builtins, classes, function, methods, attributes, any other use of names in the language). The phrase "define additional names" should not be intended to imply that using __*__ names that already have a defined meaning (like __debug__) in new contexts is fair game -- to the contrary, I would think that since __debug__ is a system-defined name (and one with pretty deep implications) doing things not explicitly allowed, like setting sys.__debug__, is really like playing with fire. On Sat, Jul 31, 2010 at 9:36 AM, Barry Warsaw <barry@python.org> wrote:
I'm with Steven on this one. I've always understood the rules on double-underscore names to mean that Python reserves the use of those names for its own purposes, and is free to break your code if you define your own.
Or if you use the ones reserved by Python in undocumented ways.
That's very different than saying it's forbidden to use double-underscore names for your own purposes or assign to them, which is I think what's going on with the sys.__debug__ example.
A blanket prohibition of assigning to or defining any __*__ names in any context (besides the documented ones in documented contexts) would clearly break a lot of code, but I don't think implementations are required or expected to avoid occasional such breakages at all cost. The occasional introduction of new __*__ names with new special meanings is clearly allowed, and if the language were to introduce a bunch of new keywords of this form (keywords meaning that they become syntactically illegal everywhere except where the syntax explicitly allows them) that would be totally within the rules.
If that's the rule, I'd want to make this section of the documentation much stronger about the prohibitions. I've just never considered Python's rule here to be that strong.
I have. I have also occasionally ignored this rule, but I've always felt that I was taking a calculated risk and would not have a leg to stand on if my code would be broken. On Sat, Jul 31, 2010 at 9:41 AM, Barry Warsaw <barry@python.org> wrote:
On Jul 30, 2010, at 05:23 PM, Eric Snow wrote:
First appeared in docs for 2.6 (October 02, 2008). Not sure if that is when it first because constrained this way.
http://docs.python.org/library/constants.html?highlight=__debug__#__debug__
Thanks Eric, this is probably the right section of the docs to reference on the issue. I want to add two clarifications to this section:
* Be more explicit that assigments to None and __debug__ are illegal even when used as attributes. IOW it's not just assignment to the built-in names that are illegal.
Well None is a reserved word in Py3k (as are True and False). But yes, the docs should clarify that *any* use of __*__ names, in *any* context, that does not follow explicitly documented use, is subject to breakage without warning.
* Add a "Changed in 2.7" to __debug__ stating that assignments to __debug__ as an attribute became illegal.
From this though, I think it's clear that Benjamin's change was intentional. I will also add this to the NEWS and What's New files for 2.7.
Thanks! -- --Guido van Rossum (python.org/~guido)
On 7/31/2010 5:02 PM, Guido van Rossum wrote:
But yes, the docs should clarify that *any* use of __*__ names, in *any* context, that does not follow explicitly documented use, is subject to breakage without warning.
http://bugs.python.org/issue9451 Strengthen __*__ system name warning My suggested new version, incorporating Guido's sentence: System-defined names. These names are defined by the interpreter and its implementation (including the standard library). Current system names are discussed in the Special method names section and elsewhere. More will likely be defined in future versions of Python. *Any* use of __*__ names, in any* context, that does not follow explicitly documented use, is subject to breakage without warning. -- Terry Jan Reedy
On Fri, Jul 30, 2010 at 1:53 PM, Barry Warsaw <barry@python.org> wrote:
On Jul 30, 2010, at 01:42 PM, Guido van Rossum wrote:
Well it is a reserved name so those packages that were setting it should have known that they were using undefined behavior that could change at any time.
Shouldn't it be described here then?
http://docs.python.org/reference/lexical_analysis.html#identifiers
No, since it is covered here: http://docs.python.org/reference/lexical_analysis.html#reserved-classes-of-i... -- --Guido van Rossum (python.org/~guido)
On Sat, 31 Jul 2010 07:44:42 am Guido van Rossum wrote:
On Fri, Jul 30, 2010 at 1:53 PM, Barry Warsaw <barry@python.org> wrote:
On Jul 30, 2010, at 01:42 PM, Guido van Rossum wrote:
Well it is a reserved name so those packages that were setting it should have known that they were using undefined behavior that could change at any time.
Shouldn't it be described here then?
http://docs.python.org/reference/lexical_analysis.html#identifiers
No, since it is covered here:
http://docs.python.org/reference/lexical_analysis.html#reserved-class es-of-identifiers
I have a small concern about the wording of that, specifically this: "System-defined names. These names are defined by the interpreter and its implementation (including the standard library); applications SHOULD NOT EXPECT TO DEFINE additional names using this convention. The set of names of this class defined by Python may be extended in future versions." [emphasis added] This implies to me that at some time in the future, Python may make it illegal to assign to any __*__ name apart from those in a list of "approved" methods. Is that the intention? I have always understood that if you create your own __*__ names, you risk clashing with a special method, but otherwise it is allowed, if disapproved off. I would not like to see it become forbidden. -- Steven D'Aprano
On Jul 31, 2010, at 08:32 AM, Steven D'Aprano wrote:
On Sat, 31 Jul 2010 07:44:42 am Guido van Rossum wrote:
On Fri, Jul 30, 2010 at 1:53 PM, Barry Warsaw <barry@python.org> wrote:
On Jul 30, 2010, at 01:42 PM, Guido van Rossum wrote:
Well it is a reserved name so those packages that were setting it should have known that they were using undefined behavior that could change at any time.
Shouldn't it be described here then?
http://docs.python.org/reference/lexical_analysis.html#identifiers
No, since it is covered here:
http://docs.python.org/reference/lexical_analysis.html#reserved-class es-of-identifiers
I have a small concern about the wording of that, specifically this:
"System-defined names. These names are defined by the interpreter and its implementation (including the standard library); applications SHOULD NOT EXPECT TO DEFINE additional names using this convention. The set of names of this class defined by Python may be extended in future versions." [emphasis added]
This implies to me that at some time in the future, Python may make it illegal to assign to any __*__ name apart from those in a list of "approved" methods. Is that the intention? I have always understood that if you create your own __*__ names, you risk clashing with a special method, but otherwise it is allowed, if disapproved off. I would not like to see it become forbidden.
I'm with Steven on this one. I've always understood the rules on double-underscore names to mean that Python reserves the use of those names for its own purposes, and is free to break your code if you define your own. That's very different than saying it's forbidden to use double-underscore names for your own purposes or assign to them, which is I think what's going on with the sys.__debug__ example. If that's the rule, I'd want to make this section of the documentation much stronger about the prohibitions. I've just never considered Python's rule here to be that strong. -Barry
Barry Warsaw wrote:
I've always understood the rules on double-underscore names to mean that Python reserves the use of those names for its own purposes, and is free to break your code if you define your own. That's very different than saying it's forbidden to use double-underscore names for your own purposes or assign to them, which is I think what's going on with the sys.__debug__ example.
I don't see that there's any difference. Once upon a time, __debug__ wasn't special, and someone decided to use it for their own purposes. Then Guido decided to make it special, and broke their code, which is within the rules as you just stated them. The rule doesn't say anything about what *kinds* of breakage are allowed, so anything goes, including making it impossible to assign to the name any more. -- Greg
2010/7/30 Barry Warsaw <barry@python.org>:
It looks like Benjamin's change in r67171 was the relevant diff.
The reason behind this was to make __debug__ assignment consistent with that of other reserved names. For example, x.None = 3 raised and thus, so should x.__debug__ = 3. -- Regards, Benjamin
On Aug 01, 2010, at 09:56 PM, Benjamin Peterson wrote:
2010/7/30 Barry Warsaw <barry@python.org>:
It looks like Benjamin's change in r67171 was the relevant diff.
The reason behind this was to make __debug__ assignment consistent with that of other reserved names. For example, x.None = 3 raised and thus, so should x.__debug__ = 3.
BTW, thanks to Georg for closing the documentation issue. -Barry
participants (9)
-
Barry Warsaw -
Benjamin Peterson -
Eric Snow -
Greg Ewing -
Guido van Rossum -
Guilherme Polo -
Michael Foord -
Steven D'Aprano -
Terry Reedy