On Mon, Apr 25, 2011 at 4:13 PM, Brian Curtin <brian.curtin@gmail.com> wrote:
On Mon, Apr 25, 2011 at 15:05, Mike Graham <mikegraham@gmail.com> wrote:
On Mon, Apr 25, 2011 at 3:51 PM, Brian Curtin <brian.curtin@gmail.com> wrote:
On Mon, Apr 25, 2011 at 14:36, haael <haael@interia.pl> 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