@ 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_". This does not introduce any new syntax and maintains the same level of backwards comparability your suggestion does.

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

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.

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

On 26/04/2011 01:14, Chris Rebert wrote:

On Mon, Apr 25, 2011 at 4:53 PM, Carl M. Johnson wrote:

...

On Mon, Apr 25, 2011 at 11:26 AM, Ethan Furman 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. You're missing True, False, and None.

Ellipsis remains an interesting exception.

Cheers, Chris _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas If you don't like adding an underscore, why not capitalise the first Letter of your Identifiers, e.g. 'With'? This would be fine for importing from Pascal (where Identifiers are Case-insensitive) and would guarantee avoiding clashing with Keywords, present *and* future (even if it gave a slightly German Flavour to the Code). Rob Cliffe

Looks like a bug in help("keywords") under Python 3.2.

Filed it: http://bugs.python.org/issue11926

On 25Apr2011 14:26, Ethan Furman 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 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

haael wrote:

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.

How do you import non-Python code? I don't understand this argument. [...]

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.

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:

On Mon, Apr 25, 2011 at 7:35 PM, Steven D'Aprano wrote:

...

haael wrote:

...

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.

How do you import non-Python code? I don't understand this argument.

I believe Bartosz is referring to bridges to other languages (e.g. PyObjC), or automatically-generated bindings to non-Python libraries.

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 25Apr2011 22:33, haael 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 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 3:51 PM, Brian Curtin wrote:

On Mon, Apr 25, 2011 at 14:36, haael wrote:

...

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

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.

To nitpick, names don't tend to be nouns only. Names of functions and methods tend to be verbs and names of interfaces and abstract classes are sometimes adjectives. M

On 2011-04-25, at 22:13 , Brian Curtin wrote:

On Mon, Apr 25, 2011 at 15:05, Mike Graham wrote:

...

On Mon, Apr 25, 2011 at 3:51 PM, Brian Curtin wrote:

...

On Mon, Apr 25, 2011 at 14:36, haael wrote:

...

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

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.

To nitpick, names don't tend to be nouns only. Names of functions and methods tend to be verbs and names of interfaces and abstract classes are sometimes adjectives.

The point still stands regardless of my your nitpicking. "with" is a bad name for any of those. As is try, raise, pass, import, break, True, etc.

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

On Mon, Apr 25, 2011 at 15:05, Mike Graham wrote:

...

On Mon, Apr 25, 2011 at 3:51 PM, Brian Curtin wrote:

...

On Mon, Apr 25, 2011 at 14:36, haael wrote:

...

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

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.

To nitpick, names don't tend to be nouns only. Names of functions and methods tend to be verbs and names of interfaces and abstract classes are sometimes adjectives.

The point still stands regardless of my your nitpicking. "with" is a bad name for any of those. As is try, raise, pass, import, break, True, etc.

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

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

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

Brian Curtin wrote:

On Mon, Apr 25, 2011 at 15:05, Mike Graham wrote:

...

On Mon, Apr 25, 2011 at 3:51 PM, Brian Curtin 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.

...

To nitpick, names don't tend to be nouns only. Names of functions and methods tend to be verbs and names of interfaces and abstract classes are sometimes adjectives.

The point still stands regardless of my your nitpicking. "with" is a bad name for any of those. As is try, raise, pass, import, break, True, etc.

I can easily see several of those working fine for boolean names. Still -1 to the idea, though. ~Ethan~

On Fri, Apr 29, 2011 at 8:33 AM, Westley Martínez 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