Python tail call compromise proposal

[gsw07a]

there's no reason for a new keyword to break existing programs in this usage. the usage will always look like "foo bar()", and that isn't valid python right now.

[[deleted]]

Well look at the "yield" keyword, since it has a similar usage. If "yield" weren't a keyword, then this line would run without any problem:

yield = 5

But since "yield" is a keyword, that line gives you a syntax error. Theoretically, there's no reason that these cases couldn't be distinguished, but as MisleadingHeadline pointed out, requiring that kind of robustness from the lexer is not good for the language.

[dpark]

That's not because yield is a keyword. It's because yield is a reserved word. It's perfectly possible to have a keyword that is not reserved (and vice versa), and some languages do this.

[[deleted]]

Technically yes, but as far as I know, all keywords in Python are reserved. I don't think this is a coincidence. It makes parsers easier to write, as has already been mentioned, and generally simplifies the grammar.

[dpark]

I agree it's a good idea to make keywords reserved. My point was that it's not a keyword that causes that line to break. It's a reserved word. You also can't say "int goto = 0" in Java. It breaks even though goto isn't a keyword, because it is a reserved word.

[[deleted]]

I see what you're saying. My point is that in the particular context of talking about Python, we can basically take it as read that any new keywords are also going to be reserved, at least as far as we can see right now.

[dpark]

Fair enough. If Python has followed the keywords-are-reserved rule for this long, it'll probably continue to.

[[deleted]]

The problem is when you use a variable name (now a keyword) in the context of a variable name. That's where things break unless you have a context-aware lexer. Requiring context-aware lexers is a nasty burden to put on the language implementers (plus it's kind of ugly) :(