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