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