Make all keywords legal as an identifier

Hello, guys. I did post this idea a few months ago. Now the revised version. Goal: Let _all_ alphanumeric keywords be legal as names for variables, functions and classes, even the ones that are reserved words now. Rationale: 1. Python took most good English words as reserved tokens. Situation goes worse from version to version. I often have hard time searching for acceptable synonyms. 2. Because of that, old Python programs cease to work, even if they do not use any abandoned features. Their only sin is using certain words that further versions of Python have stolen away. 3. Sometimes one needs to import keywords from some other language, XML be an example, or "translate" another programming language into Python in one way or another. Keyword reservation is a big problem then; it does not allow to use the natural Python syntax. Solution: Let the parser treat all keywords that come after a dot (".") as regular identifiers. For attributes, nothing changes:
boo.for = 7
For names that are not attributes, only one syntax change is needed: let a dot precede any identifier.
.with = 3
Of course, if a keyword is not preceded by a dot, it would be treated as a reserved word, just like now.
with = 3 # syntax error
There is only one case where a dot is used as a prefix of an identifier and that is a relative module import.
from .boo import foo My change is consistent with this case.
One benefit would be that converting current programs to work with future versions would be a matter of simple grep. Python is a great language. In my opinion, this change is the one last step to make it every geeky teenager's wet dream: the language where one can redefine almost anything. When I work with some problem, I always try to translate it to Python, solve and translate back. Prohibited identifier names are the main obstacle. So, let's set the identifiers free and swallow all the world, making Python the least common denominator of every computer problem on this planet. Regards, Bartosz Tarnowski ------------------------------------------------- Jedz te potrawy, aby uchronic sie przed rakiem! Sprawdz >> http://linkint.pl/f2946

@ Mike Graham
But the trailing underscore is treated as a part of an identifier, while the preceding dot is not. This is important if I want to have an identifier named exactly "with", with no other characters (no pun itended). As I said, I want sometimes to import some non-Python namespace, i.e. a Pascal program. If all identifiers are allowed, there would never be a clash of reserved words. @ Terry Reedy
This very fact makes us *very* reluctant to add new keywords, which I think is a pretty good thing.
So my change hits two birds with one stone: programmers could use any word as an identifier, developers could use any word as a token. Perfect solution.
as = 4 # syntax error
Read my proposal carefully. The module could access this name with a preceding dot:
.as = 4 # access to global and local variables
@ Sergio Surkamp
Why don't you use underscore instead of a dot?
As I said, the underscore is a part of a name, while the dot isn't. @ Brain Curtin
First of all, many nouns are reserved, i.e. "object" or "class". Second: variable names are usually nouns indeed, but functions and methods are often verbs, while named parameters can be prepositions and adverbs. For example:
turtles.fight(with=honour)
Python kidnapped many verbs and prepositions and made them reserved. However, no matter what we say, it's the programmer's choice which word to use. If he has a reason to use prepositions as variable names, it's none of our business. Regards, Bartosz Tarnowski --------------------------------------------- Ksiegowa radzi: Jak zaÅozyc firme w 15 minut? http://linkint.pl/f2968

On Mon, Apr 25, 2011 at 11:26 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
Many? Aren't we still at less than 50 words total? Pretty infinitesimal when compared with the 100,000+ words in the English language.
Here are all of them for Python 3: and elif import raise as else in return assert except is try break finally lambda while class for nonlocal with continue from not yield def global or del if pass 30 total. I say, append a _ and you're fine.

Looks like a bug in help("keywords") under Python 3.2.
Filed it: http://bugs.python.org/issue11926

On Tue, Apr 26, 2011 at 11:50 AM, Carl M. Johnson <cmjohnson.mailinglist@gmail.com> wrote:
You're missing True, False, and None.
Looks like a bug in help("keywords") under Python 3.2.
The bug is actually a little deeper than that - True/False/None were historically either not keywords at all, or pseudo keywords that were permitted as attributes, but not as local variables. They haven't yet been promoted properly to full keyword status in the language grammar (even though the compiler already ensures that they can't be assigned to or used as anything other than themselves). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 25Apr2011 14:26, Ethan Furman <ethan@stoneleaf.us> wrote: | haael wrote: | >First of all, many nouns are reserved, i.e. "object" or "class". | | Many? Aren't we still at less than 50 words total? Pretty | infinitesimal when compared with the 100,000+ words in the English | language. | | >Second: variable names are usually nouns indeed, but functions and | >methods are often verbs, while named parameters can be | >prepositions and adverbs. [...] | >Python kidnapped many verbs and prepositions and made them reserved. | | See above. This is a ridiculous exaggeration. Though to be fair, Python's using a fair number of the very heavily used ones. Personally I'm -1 on the proposal, especially the leading dot part. One downside that springs to mind is a weakness in C: the syntax is so... lexically complete... that quite often a syntactic programming error can get warnings about well below the actual error, and several easy mistakes are syntacticly valid and only show as logic errors later. The standard example is = instead of ==. My point here is that the more valid but mistaken forms the language allows, the easier it is for simple errors to become logic errors. Contrived examples: # getting the "as" name from "foo" from foo import as # but did I mean "from foo import this as that" ? # is this now a syntax error, since "as" is a name? with open("foo") as fp: Cheers, -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ The worst tyrannies were the ones where a governance required its own logic on every embedded node. - Vernor Vinge

On 2011-04-26, at 09:15 , Cameron Simpson wrote:
If you did, you'll realize it quite soon as you'll be missing `that` in your local namespace? In any case, the statement is not ambiguous. Not for the machine, but not for humans either.
# is this now a syntax error, since "as" is a name? with open("foo") as fp:
`as` could be used as a name, but would still be a keyword. This statement would be parsed as `with [expr] as [name]`, which is perfectly valid, why would there be a syntax error anywhere? `with open ("foo") as as` would also be valid, though one could argue less readable.

haael wrote:
How do you import non-Python code? I don't understand this argument. [...]
On the contrary -- this would actually be a bad thing, in my opinion significantly worse than the current situation. I accept that name clashes can be a problem, but I dispute that it is a big problem. It's a tiny, minuscule problem, and I argue that your solution is much worse. You are only considering the *cost* of having reserved words and not the *benefit*. Your proposal increases the cognitive load on the programmer, rather than decreases it. We write code once, but we read it many times, and it is much more important to minimize the burden of reading code than writing it. The rule now is simple: there are a small number of reserved words. You may not use them, end of story. Therefore you can identify a reserved word *immediately* you see it, without caring about content beyond "is it inside a string or a comment?". The cognitive burden on the reader is very low. You would make that rule more complex. Reserved words would no longer be reserved. That alone is a bad thing -- you want to solve the problem that you can't name your variables "return", "for", "if", but I don't call that a problem, I call that a GOOD thing. I don't want to read code that sometimes uses return as a statement and sometimes as a variable. But worse, things which were a clear mistake before become ambiguous: len(.spam) is clearly an unambiguous mistake now, but with your proposal it becomes valid syntax. Now I have to stop and think: did the author mean .spam or did he mean obj.spam and just forget the obj part? If I don't use the dotted form, then Python might "steal" or "kidnap" (your words, not mine) my identifier, so if I care about forward compatibility, I will use dots everywhere: class .tree(.parent): def .func(self, .argument, .exception=None): if not .exception: return self.method(.argument, .param) raise .exception The cognitive load on reading my code is increased. The dots don't actually do anything, they're just there to protect my code from distant, *hypothetical* changes. If you think "nobody will bother to dot everything!" then you are inadvertently arguing that the problem you are trying to solve is a tiny problem that most people don't care about. -- Steven

Chris Rebert, 26.04.2011 04:45:
Those won't be helped much by this proposal, though, given that other languages are free to allow or deny as identifiers (and types, objects, closures, references, pointers, ...) whatever they like. Wrapping tools will always have to be aware of both sides of the wrapper, and deal with differences and ambiguities in one way or another. The simple feature that "with" could then be used unmangled in Python code does not even touch the surface of this. Stefan

On 26 Apr, 2011, at 9:15, Stefan Behnel wrote:
They would be helped because the other language might have method/function/class names that are reserved works in Python, an example of this is the 'class' method of NSObject in Objective-C. PyObjC using the convention of adding a double underscore to the end of method names to make them valid Python identifiers ( anObject.class__()). I'm -1 on the proposal though, the readability cost is too high for the very small benifit of using keywords as attribute names. Ronald

On 25Apr2011 22:33, haael <haael@interia.pl> wrote: | @ Mike Graham | >>Of course, if a keyword is not preceded by a dot, it would be treated as a | >>reserved word, just like now. | >>>with = 3 # syntax error | >I don't see how this is a real improvement over the current | >convention, to add a trailing underscore, so that programs really | >needing to use the name "with" would use "with_". [...] | But the trailing underscore is treated as a part of an identifier, | while the preceding dot is not. This is important if I want to have | an identifier named exactly "with", with no other characters (no pun | itended). | | As I said, I want sometimes to import some non-Python namespace, | i.e. a Pascal program. If all identifiers are allowed, there would | never be a clash of reserved words. Does your proposal help with non-Python namespaces with different identifier rules? I know this is a little snarky, but I've certainly seen real world stuff with "$" as a valid identifier character. Cheers, -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ But then, I'm only 50. Things may well get a bit much for me when I reach the gasping heights of senile decrepitude of which old Andy Woodward speaks with such feeling. - Chris Malcolm, cam@uk.ac.ed.aifh, DoD #205

On Mon, Apr 25, 2011 at 14:36, haael <haael@interia.pl> wrote:
Names tend to be nouns, so first I can't imagine why you'd want "with" as a name, but you could exchange almost all keywords in the example and it's not a great case. Making this change rather than working around poor name choice gets a -1 from me.

On 2011-04-25, at 22:13 , Brian Curtin wrote:
With is actually a very nice name for some things, it creates very readable, english-looking code. And what about `class`? Or `for` (that one clashes hard against the HTML object model, label elements have a for attribute). `in`, `except` or `is` may also be interesting in some cases. Do all Python keywords have this issue? No, I doubt anybody's ever tried to called an attribute `elif`, but I definitely ran into the issue a few times.

On Mon, Apr 25, 2011 at 4:13 PM, Brian Curtin <brian.curtin@gmail.com> wrote:
I get what you're saying, but it's not categorically the case for Python keywords. For example: - To use your list, the throw method of generators should be raise. - The assertTrue method of TestCase should be assert. - The first argument of a classmethod should be class. - sqlalbemy.and_ and or_ should be and and or. - In an example snippet, "for a, b, c in zip(as, bs, cs)" would be nice. Similarly for is. Other examples, some more contrived than others, could be provided--some of these would be good names if not for their keyword status. However, I don't think I've seen a suggestion better than the current solution (or lack thereof). Mike

On Mon, 25 Apr 2011 16:26:47 -0400 Mike Graham <mikegraham@gmail.com> wrote:
I think the *first* part of this proposal - allowing attribute names to be keywords - provides almost all the benefits and few of the problems that were brought up. For instance, the "with .with.as as .as" goes away - the worst you can do is "with with_.as as as_", which is only slightly worse than the already legal "with with_.as_ as as_". I don't think it changes the cognitive load of someone reading or writing code noticeably - limiting it to attributes means you're limiting it to a namespace that's already visually and logically distinct from the namespace that keywords can appear in. In fact, that separation also means there are no backwards compatibility issues. On the other hand, the problem of wanting to bind external names (say from a CORBA ORB) should go away, because the names tend to be attributes of the external objects you are using. The objects themselves you get to name. Likewise, most of the examples from the standard library where the obvious name for something was a keyword were attribute names. This would fix those, but not let the first parameter to classmethods be class. The nasty problem - possibly nasty enough to kill this - are the cases where context allows bare names to be used to refer to things that are used as attributes outside the context: a modules global namespace and class variables off the top of my head. Using the bare name as a keyword would be a syntax error, but using it as an attribute elsewhere would work fine. Class variables can probably be worked around since they only use for bare names is to initialize them at class definition time, but module global are another issue. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

On 26 Apr 2011, at 07:42, Mike Meyer wrote:
Note that attribute names can already be keywords (same for globals). It's just that the compiler will complain when it sees them, so you have to make sure it doesn't sees them.
-- Arnaud

Why don't you use underscore instead of a dot? _with = 3 Regards, -- .:''''':. .:' ` Sérgio Surkamp | Gerente de Rede :: ........ sergio@gruposinternet.com.br `:. .:' `:, ,.:' *Grupos Internet S.A.* `: :' R. Lauro Linhares, 2123 Torre B - Sala 201 : : Trindade - Florianópolis - SC :.' :: +55 48 3234-4109 : ' http://www.gruposinternet.com.br

On 4/25/2011 3:36 PM, haael wrote:
This very fact makes us *very* reluctant to add new keywords, which I think is a pretty good thing.
I have no idea what the technical difficulties would be. However, one possible practical difficulty is that whether or not a name is dotted depends on the context. a.py: x = 3 # ok as = 4 # syntax error b.py import a a.x = 3 # ok a.as = 4 # ok with your proposal, but code within a could not access it. Same for code in the body of a class statement versus code without. -- Terry Jan Reedy

with .with.as as .as: .assert(.as.if(.not) for .not in .for.not.in if .import(.not.None, .as, .None)) I don't think that this improves program readability or clarity. Eli

haael writes:
-1 Do you have any idea how many TB of hate mail you will get from maintainers of Python modes for editors if this goes through?<wink> Philosophically, Lewis Carroll put "paid" to this proposal more than 100 years ago. All the king's horses and all the king's men won't be able to put it together again. To be specific, having reserved tokens in the syntax, including keywords, enhances readability. Python's #1 feature is readability. Let's keep it that way!

On Fri, Apr 29, 2011 at 8:33 AM, Westley Martínez <anikom15@gmail.com> wrote:
I don't know about you guys but I've never needed a reserved word for a variable name, and if I did, I'd just append an _ to it.
"class" is the only one I have ever wanted to use, and "cls" is a perfectly acceptable substitute in that case (other variants I have seen are "klass" and "class_"). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

@ Mike Graham
But the trailing underscore is treated as a part of an identifier, while the preceding dot is not. This is important if I want to have an identifier named exactly "with", with no other characters (no pun itended). As I said, I want sometimes to import some non-Python namespace, i.e. a Pascal program. If all identifiers are allowed, there would never be a clash of reserved words. @ Terry Reedy
This very fact makes us *very* reluctant to add new keywords, which I think is a pretty good thing.
So my change hits two birds with one stone: programmers could use any word as an identifier, developers could use any word as a token. Perfect solution.
as = 4 # syntax error
Read my proposal carefully. The module could access this name with a preceding dot:
.as = 4 # access to global and local variables
@ Sergio Surkamp
Why don't you use underscore instead of a dot?
As I said, the underscore is a part of a name, while the dot isn't. @ Brain Curtin
First of all, many nouns are reserved, i.e. "object" or "class". Second: variable names are usually nouns indeed, but functions and methods are often verbs, while named parameters can be prepositions and adverbs. For example:
turtles.fight(with=honour)
Python kidnapped many verbs and prepositions and made them reserved. However, no matter what we say, it's the programmer's choice which word to use. If he has a reason to use prepositions as variable names, it's none of our business. Regards, Bartosz Tarnowski --------------------------------------------- Ksiegowa radzi: Jak zaÅozyc firme w 15 minut? http://linkint.pl/f2968

On Mon, Apr 25, 2011 at 11:26 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
Many? Aren't we still at less than 50 words total? Pretty infinitesimal when compared with the 100,000+ words in the English language.
Here are all of them for Python 3: and elif import raise as else in return assert except is try break finally lambda while class for nonlocal with continue from not yield def global or del if pass 30 total. I say, append a _ and you're fine.

Looks like a bug in help("keywords") under Python 3.2.
Filed it: http://bugs.python.org/issue11926

On Tue, Apr 26, 2011 at 11:50 AM, Carl M. Johnson <cmjohnson.mailinglist@gmail.com> wrote:
You're missing True, False, and None.
Looks like a bug in help("keywords") under Python 3.2.
The bug is actually a little deeper than that - True/False/None were historically either not keywords at all, or pseudo keywords that were permitted as attributes, but not as local variables. They haven't yet been promoted properly to full keyword status in the language grammar (even though the compiler already ensures that they can't be assigned to or used as anything other than themselves). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 25Apr2011 14:26, Ethan Furman <ethan@stoneleaf.us> wrote: | haael wrote: | >First of all, many nouns are reserved, i.e. "object" or "class". | | Many? Aren't we still at less than 50 words total? Pretty | infinitesimal when compared with the 100,000+ words in the English | language. | | >Second: variable names are usually nouns indeed, but functions and | >methods are often verbs, while named parameters can be | >prepositions and adverbs. [...] | >Python kidnapped many verbs and prepositions and made them reserved. | | See above. This is a ridiculous exaggeration. Though to be fair, Python's using a fair number of the very heavily used ones. Personally I'm -1 on the proposal, especially the leading dot part. One downside that springs to mind is a weakness in C: the syntax is so... lexically complete... that quite often a syntactic programming error can get warnings about well below the actual error, and several easy mistakes are syntacticly valid and only show as logic errors later. The standard example is = instead of ==. My point here is that the more valid but mistaken forms the language allows, the easier it is for simple errors to become logic errors. Contrived examples: # getting the "as" name from "foo" from foo import as # but did I mean "from foo import this as that" ? # is this now a syntax error, since "as" is a name? with open("foo") as fp: Cheers, -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ The worst tyrannies were the ones where a governance required its own logic on every embedded node. - Vernor Vinge

On 2011-04-26, at 09:15 , Cameron Simpson wrote:
If you did, you'll realize it quite soon as you'll be missing `that` in your local namespace? In any case, the statement is not ambiguous. Not for the machine, but not for humans either.
# is this now a syntax error, since "as" is a name? with open("foo") as fp:
`as` could be used as a name, but would still be a keyword. This statement would be parsed as `with [expr] as [name]`, which is perfectly valid, why would there be a syntax error anywhere? `with open ("foo") as as` would also be valid, though one could argue less readable.

haael wrote:
How do you import non-Python code? I don't understand this argument. [...]
On the contrary -- this would actually be a bad thing, in my opinion significantly worse than the current situation. I accept that name clashes can be a problem, but I dispute that it is a big problem. It's a tiny, minuscule problem, and I argue that your solution is much worse. You are only considering the *cost* of having reserved words and not the *benefit*. Your proposal increases the cognitive load on the programmer, rather than decreases it. We write code once, but we read it many times, and it is much more important to minimize the burden of reading code than writing it. The rule now is simple: there are a small number of reserved words. You may not use them, end of story. Therefore you can identify a reserved word *immediately* you see it, without caring about content beyond "is it inside a string or a comment?". The cognitive burden on the reader is very low. You would make that rule more complex. Reserved words would no longer be reserved. That alone is a bad thing -- you want to solve the problem that you can't name your variables "return", "for", "if", but I don't call that a problem, I call that a GOOD thing. I don't want to read code that sometimes uses return as a statement and sometimes as a variable. But worse, things which were a clear mistake before become ambiguous: len(.spam) is clearly an unambiguous mistake now, but with your proposal it becomes valid syntax. Now I have to stop and think: did the author mean .spam or did he mean obj.spam and just forget the obj part? If I don't use the dotted form, then Python might "steal" or "kidnap" (your words, not mine) my identifier, so if I care about forward compatibility, I will use dots everywhere: class .tree(.parent): def .func(self, .argument, .exception=None): if not .exception: return self.method(.argument, .param) raise .exception The cognitive load on reading my code is increased. The dots don't actually do anything, they're just there to protect my code from distant, *hypothetical* changes. If you think "nobody will bother to dot everything!" then you are inadvertently arguing that the problem you are trying to solve is a tiny problem that most people don't care about. -- Steven

Chris Rebert, 26.04.2011 04:45:
Those won't be helped much by this proposal, though, given that other languages are free to allow or deny as identifiers (and types, objects, closures, references, pointers, ...) whatever they like. Wrapping tools will always have to be aware of both sides of the wrapper, and deal with differences and ambiguities in one way or another. The simple feature that "with" could then be used unmangled in Python code does not even touch the surface of this. Stefan

On 26 Apr, 2011, at 9:15, Stefan Behnel wrote:
They would be helped because the other language might have method/function/class names that are reserved works in Python, an example of this is the 'class' method of NSObject in Objective-C. PyObjC using the convention of adding a double underscore to the end of method names to make them valid Python identifiers ( anObject.class__()). I'm -1 on the proposal though, the readability cost is too high for the very small benifit of using keywords as attribute names. Ronald

On 25Apr2011 22:33, haael <haael@interia.pl> wrote: | @ Mike Graham | >>Of course, if a keyword is not preceded by a dot, it would be treated as a | >>reserved word, just like now. | >>>with = 3 # syntax error | >I don't see how this is a real improvement over the current | >convention, to add a trailing underscore, so that programs really | >needing to use the name "with" would use "with_". [...] | But the trailing underscore is treated as a part of an identifier, | while the preceding dot is not. This is important if I want to have | an identifier named exactly "with", with no other characters (no pun | itended). | | As I said, I want sometimes to import some non-Python namespace, | i.e. a Pascal program. If all identifiers are allowed, there would | never be a clash of reserved words. Does your proposal help with non-Python namespaces with different identifier rules? I know this is a little snarky, but I've certainly seen real world stuff with "$" as a valid identifier character. Cheers, -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ But then, I'm only 50. Things may well get a bit much for me when I reach the gasping heights of senile decrepitude of which old Andy Woodward speaks with such feeling. - Chris Malcolm, cam@uk.ac.ed.aifh, DoD #205

On Mon, Apr 25, 2011 at 14:36, haael <haael@interia.pl> wrote:
Names tend to be nouns, so first I can't imagine why you'd want "with" as a name, but you could exchange almost all keywords in the example and it's not a great case. Making this change rather than working around poor name choice gets a -1 from me.

On 2011-04-25, at 22:13 , Brian Curtin wrote:
With is actually a very nice name for some things, it creates very readable, english-looking code. And what about `class`? Or `for` (that one clashes hard against the HTML object model, label elements have a for attribute). `in`, `except` or `is` may also be interesting in some cases. Do all Python keywords have this issue? No, I doubt anybody's ever tried to called an attribute `elif`, but I definitely ran into the issue a few times.

On Mon, Apr 25, 2011 at 4:13 PM, Brian Curtin <brian.curtin@gmail.com> wrote:
I get what you're saying, but it's not categorically the case for Python keywords. For example: - To use your list, the throw method of generators should be raise. - The assertTrue method of TestCase should be assert. - The first argument of a classmethod should be class. - sqlalbemy.and_ and or_ should be and and or. - In an example snippet, "for a, b, c in zip(as, bs, cs)" would be nice. Similarly for is. Other examples, some more contrived than others, could be provided--some of these would be good names if not for their keyword status. However, I don't think I've seen a suggestion better than the current solution (or lack thereof). Mike

On Mon, 25 Apr 2011 16:26:47 -0400 Mike Graham <mikegraham@gmail.com> wrote:
I think the *first* part of this proposal - allowing attribute names to be keywords - provides almost all the benefits and few of the problems that were brought up. For instance, the "with .with.as as .as" goes away - the worst you can do is "with with_.as as as_", which is only slightly worse than the already legal "with with_.as_ as as_". I don't think it changes the cognitive load of someone reading or writing code noticeably - limiting it to attributes means you're limiting it to a namespace that's already visually and logically distinct from the namespace that keywords can appear in. In fact, that separation also means there are no backwards compatibility issues. On the other hand, the problem of wanting to bind external names (say from a CORBA ORB) should go away, because the names tend to be attributes of the external objects you are using. The objects themselves you get to name. Likewise, most of the examples from the standard library where the obvious name for something was a keyword were attribute names. This would fix those, but not let the first parameter to classmethods be class. The nasty problem - possibly nasty enough to kill this - are the cases where context allows bare names to be used to refer to things that are used as attributes outside the context: a modules global namespace and class variables off the top of my head. Using the bare name as a keyword would be a syntax error, but using it as an attribute elsewhere would work fine. Class variables can probably be worked around since they only use for bare names is to initialize them at class definition time, but module global are another issue. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

On 26 Apr 2011, at 07:42, Mike Meyer wrote:
Note that attribute names can already be keywords (same for globals). It's just that the compiler will complain when it sees them, so you have to make sure it doesn't sees them.
-- Arnaud

Why don't you use underscore instead of a dot? _with = 3 Regards, -- .:''''':. .:' ` Sérgio Surkamp | Gerente de Rede :: ........ sergio@gruposinternet.com.br `:. .:' `:, ,.:' *Grupos Internet S.A.* `: :' R. Lauro Linhares, 2123 Torre B - Sala 201 : : Trindade - Florianópolis - SC :.' :: +55 48 3234-4109 : ' http://www.gruposinternet.com.br

On 4/25/2011 3:36 PM, haael wrote:
This very fact makes us *very* reluctant to add new keywords, which I think is a pretty good thing.
I have no idea what the technical difficulties would be. However, one possible practical difficulty is that whether or not a name is dotted depends on the context. a.py: x = 3 # ok as = 4 # syntax error b.py import a a.x = 3 # ok a.as = 4 # ok with your proposal, but code within a could not access it. Same for code in the body of a class statement versus code without. -- Terry Jan Reedy

with .with.as as .as: .assert(.as.if(.not) for .not in .for.not.in if .import(.not.None, .as, .None)) I don't think that this improves program readability or clarity. Eli

haael writes:
-1 Do you have any idea how many TB of hate mail you will get from maintainers of Python modes for editors if this goes through?<wink> Philosophically, Lewis Carroll put "paid" to this proposal more than 100 years ago. All the king's horses and all the king's men won't be able to put it together again. To be specific, having reserved tokens in the syntax, including keywords, enhances readability. Python's #1 feature is readability. Let's keep it that way!

On Fri, Apr 29, 2011 at 8:33 AM, Westley Martínez <anikom15@gmail.com> wrote:
I don't know about you guys but I've never needed a reserved word for a variable name, and if I did, I'd just append an _ to it.
"class" is the only one I have ever wanted to use, and "cls" is a perfectly acceptable substitute in that case (other variants I have seen are "klass" and "class_"). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (20)
-
Arnaud Delobelle
-
Brian Curtin
-
Cameron Simpson
-
Carl M. Johnson
-
Chris Rebert
-
Eli Stevens (Gmail)
-
Ethan Furman
-
haael
-
Masklinn
-
Mike Graham
-
Mike Meyer
-
Nick Coghlan
-
Rob Cliffe
-
Ronald Oussoren
-
Stefan Behnel
-
Stephen J. Turnbull
-
Steven D'Aprano
-
Sérgio Surkamp
-
Terry Reedy
-
Westley Martínez