>>On Sat, 31 Jul 2010 07:44:42 am Guido van Rossum wrote: >>> http://docs.python.org/reference/lexical_analysis.html#reserved-classes-of-identifiers
> 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 <ba...@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 <ba...@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) _______________________________________________ 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/archive%40mail-archive.com