Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions
On 13/05/2018 19:19, Guido van Rossum wrote: positions where an identifier is allowed, not legal in others. With respect, that seems like a terrible idea; neither those who want to use such identifiers, nor those who don't, would be happy. Especially if it encourages work-arounds such as def and(x, y): return ... # and(1,2) # Oops, SyntaxError. Oh, I know: globals()['and'](1,2) # Works! and a zillion others.
[snip] And it would probably cause certain typos be harder to diagnose.
No doubt.
Thanks. :-)
-- --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
Best wishes Rob Cliffe
Rob Cliffe via Python-ideas wrote:
If the rule I proposed for "import" were extended to "def" then and(1,2) would work. The usual way of using "and" would no longer work in that module, but this just goes to show that redefining "and" is a silly thing to do in the first place. Redefining the existing keywords could perhaps be forbidden if you really want to protect people from shooting themselves in the kidneys this particular way. -- Greg
New Python versions already use backwards incompatible syntax, but it has to be a strict superset so the new parser still parses old code. If a new Python version introduced syntax that would break old code, it would still work, so long as the parser knew which syntax the file contained, and was able to parse both versions. I personally think Python 3 should have always had a new file extension (mainly to help editors disambiguate), but some kind of directive at the top of the file would work as well, a bit like JavaScript's Strict Mode. The killer objection is that you have to maintain two parsers or some kind of mashup, but still, the old syntax would be frozen, there could be a lot of reuse in the front end, and there would still only be one VM. I'm not hoping this happens any time soon, but if was a choice between devs maintaining two parsers or users migrating to Python 4, as a user... -- Carl Smith carl.input@gmail.com On 14 May 2018 at 02:28, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
On 14/05/2018 02:28, Greg Ewing wrote:
If you forbid redefining keywords, you remove the whole point of this proposal: to allow keywords to be sometimes used as bona fide keywords, sometimes as identifiers. I really do not intend to give offence (I know that that's counter-productive). But I have formed a very strong opinion - which of course may be wrong, and certainly won't be universally shared - and I am honestly expressing that opinion: Nothing I have seen in this thread so far has persuaded me that this proposal has any merit.
Rob Cliffe via Python-ideas wrote:
If you forbid redefining keywords, you remove the whole point of this proposal:
I mean the keywords that are in the language as of now. There will never be a need to redefine those, since no current code uses them as names. -- Greg
Ethan Furman wrote:
Part of the point of the proposal is to be able to use existing keywords (at least, I thought it was).
Mainly it's so that *new* keywords can be added to the language without breaking old code. Nobody is going to want to turn one of the currently existing keywords into a name. However, it might be desirable for calling APIs of another language which has a different set of keywords. Personally I don't really care if "from foreignlib import and" works and clobbers the "and" operator for the rest of the module. I was just suggesting a milder version of the feature that some people might be more comfortable with. -- Greg
On Tue, 15 May 2018 21:51:20 +1200 Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
I'm a worried that we're speaking about making it *easier* to add new keywords. The language doesn't need a C++-like destiny, IMHO, where the language definition becomes increasingly bloated by piling up syntactical features. Regards Antoine.
On 15 May 2018 at 11:07, Antoine Pitrou <solipsis@pitrou.net> wrote:
Agreed - but there also seems to be a trend at the moment to propose punctuation-based syntax, with keyword-based alternatives being rejected on the basis that keywords break backward compatibility (because of existing use as variables). I'm not sure a Perl-like destiny (where we pile up extra punctuation) is that much better. I'm not in favour of this idea (it seems likely there will be too many odd corner cases and exceptions) but I can understand the motivation behind it. As you say, the real solution is of course to exercise restraint in what new syntax gets added. But looking at the recent "what's new in Python" docs, the reality is actually a lot more restrained than reading python-ideas might imply - so I'm not sure things are as bad as they initially seem. Paul
While I understand the attraction, I think the clarity cost might be to high. If it's a pain to explain it to an IDE, it's an even bigger pain to explain it to people new to the language.
On Mon, May 14, 2018 at 01:28:51PM +1200, Greg Ewing wrote:
So instead of having two classes of identifiers - those that can be used anywhere; - those that can only be used as dotted names; you would have two classes of keywords: - those that cannot be shadowed; - those that can be shadowed. -- Steve
I hereby withdraw the idea. -- --Guido van Rossum (python.org/~guido)
Steven D'Aprano wrote:
Yes. But we would always recommend that people not shadow any keywords, just as we recommend that tney not shadow builtins. All of this is purely to allow old code to keep working and old APIs to be used. -- Greg
Rob Cliffe via Python-ideas wrote:
If the rule I proposed for "import" were extended to "def" then and(1,2) would work. The usual way of using "and" would no longer work in that module, but this just goes to show that redefining "and" is a silly thing to do in the first place. Redefining the existing keywords could perhaps be forbidden if you really want to protect people from shooting themselves in the kidneys this particular way. -- Greg
New Python versions already use backwards incompatible syntax, but it has to be a strict superset so the new parser still parses old code. If a new Python version introduced syntax that would break old code, it would still work, so long as the parser knew which syntax the file contained, and was able to parse both versions. I personally think Python 3 should have always had a new file extension (mainly to help editors disambiguate), but some kind of directive at the top of the file would work as well, a bit like JavaScript's Strict Mode. The killer objection is that you have to maintain two parsers or some kind of mashup, but still, the old syntax would be frozen, there could be a lot of reuse in the front end, and there would still only be one VM. I'm not hoping this happens any time soon, but if was a choice between devs maintaining two parsers or users migrating to Python 4, as a user... -- Carl Smith carl.input@gmail.com On 14 May 2018 at 02:28, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
On 14/05/2018 02:28, Greg Ewing wrote:
If you forbid redefining keywords, you remove the whole point of this proposal: to allow keywords to be sometimes used as bona fide keywords, sometimes as identifiers. I really do not intend to give offence (I know that that's counter-productive). But I have formed a very strong opinion - which of course may be wrong, and certainly won't be universally shared - and I am honestly expressing that opinion: Nothing I have seen in this thread so far has persuaded me that this proposal has any merit.
Rob Cliffe via Python-ideas wrote:
If you forbid redefining keywords, you remove the whole point of this proposal:
I mean the keywords that are in the language as of now. There will never be a need to redefine those, since no current code uses them as names. -- Greg
Ethan Furman wrote:
Part of the point of the proposal is to be able to use existing keywords (at least, I thought it was).
Mainly it's so that *new* keywords can be added to the language without breaking old code. Nobody is going to want to turn one of the currently existing keywords into a name. However, it might be desirable for calling APIs of another language which has a different set of keywords. Personally I don't really care if "from foreignlib import and" works and clobbers the "and" operator for the rest of the module. I was just suggesting a milder version of the feature that some people might be more comfortable with. -- Greg
On Tue, 15 May 2018 21:51:20 +1200 Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
I'm a worried that we're speaking about making it *easier* to add new keywords. The language doesn't need a C++-like destiny, IMHO, where the language definition becomes increasingly bloated by piling up syntactical features. Regards Antoine.
On 15 May 2018 at 11:07, Antoine Pitrou <solipsis@pitrou.net> wrote:
Agreed - but there also seems to be a trend at the moment to propose punctuation-based syntax, with keyword-based alternatives being rejected on the basis that keywords break backward compatibility (because of existing use as variables). I'm not sure a Perl-like destiny (where we pile up extra punctuation) is that much better. I'm not in favour of this idea (it seems likely there will be too many odd corner cases and exceptions) but I can understand the motivation behind it. As you say, the real solution is of course to exercise restraint in what new syntax gets added. But looking at the recent "what's new in Python" docs, the reality is actually a lot more restrained than reading python-ideas might imply - so I'm not sure things are as bad as they initially seem. Paul
While I understand the attraction, I think the clarity cost might be to high. If it's a pain to explain it to an IDE, it's an even bigger pain to explain it to people new to the language.
On Mon, May 14, 2018 at 01:28:51PM +1200, Greg Ewing wrote:
So instead of having two classes of identifiers - those that can be used anywhere; - those that can only be used as dotted names; you would have two classes of keywords: - those that cannot be shadowed; - those that can be shadowed. -- Steve
I hereby withdraw the idea. -- --Guido van Rossum (python.org/~guido)
Steven D'Aprano wrote:
Yes. But we would always recommend that people not shadow any keywords, just as we recommend that tney not shadow builtins. All of this is purely to allow old code to keep working and old APIs to be used. -- Greg
participants (9)
-
Antoine Pitrou -
Carl Smith -
Ethan Furman -
Greg Ewing -
Guido van Rossum -
Jacco van Dorp -
Paul Moore -
Rob Cliffe -
Steven D'Aprano