On 13/05/2018 19:19, Guido van Rossum wrote:
As anyone still following the inline assignment discussion knows, a problem with designing new syntax is that it's hard to introduce new keywords into the language, since all the nice words seem to be used as method names in popular packages. (E.g. we can't use 'where' because there's numpy.where https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.where.html, and we can't use 'given' because it's used in Hypothesis http://hypothesis.readthedocs.io/en/latest/quickstart.html.)
The idea I had (not for the first time :-) is that in many syntactic positions we could just treat keywords as names, and that would free up these keywords.
For example, we could allow keywords after 'def' and after a period, and then the following would become legal:
class C: def and(self, other): return ...
a = C() b = C() print(a.and(b))
This does not create syntactic ambiguities because after 'def' and after a period the grammar *always* requires a NAME.
There are other positions where we could perhaps allow this, e.g. in a decorator, immediately after '@' (the only keyword that's *syntactically* legal here is 'not', though I'm not sure it would ever be useful).
So you would be allowing "second class" identifiers - legal in some 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.
I should also mention that this was inspired from some messages where Tim Peters berated the fashion of using "reserved words", waxing nostalgically about the old days of Fortran (sorry, FORTRAN), which doesn't (didn't?) have reserved words at all (nor significant whitespace, apart from the "start in column 7" rule).
Anyway, just throwing this out. Please tear it apart!
Thanks. :-)
-- --Guido van Rossum (python.org/~guido http://python.org/%7Eguido)
Best wishes Rob Cliffe
Rob Cliffe via Python-ideas wrote:
def and(x, y): return ...# and(1,2) # Oops, SyntaxError. Oh, I know: globals()['and'](1,2) # Works!
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.
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:
Rob Cliffe via Python-ideas wrote:
def and(x, y): return ...# and(1,2) # Oops, SyntaxError. Oh, I know: globals()['and'](1,2) # Works!
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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On 14/05/2018 02:28, Greg Ewing wrote:
Rob Cliffe via Python-ideas wrote:
def and(x, y): return ...
# and(1,2) # Oops, SyntaxError. Oh, I know: globals()['and'](1,2) # Works!
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.
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.
On 05/13/2018 10:57 PM, Greg Ewing wrote:
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.
Part of the point of the proposal is to be able to use existing keywords (at least, I thought it was).
-- ~Ethan~
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.
On Tue, 15 May 2018 21:51:20 +1200 Greg Ewing greg.ewing@canterbury.ac.nz wrote:
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.
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:
On Tue, 15 May 2018 21:51:20 +1200 Greg Ewing greg.ewing@canterbury.ac.nz wrote:
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.
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.
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:
Redefining the existing keywords could perhaps be forbidden if you really want to protect people from shooting themselves in the kidneys this particular way.
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.
I hereby withdraw the idea.
Steven D'Aprano 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.
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.
-
Antoine Pitrou -
Carl Smith -
Ethan Furman -
Greg Ewing -
Guido van Rossum -
Jacco van Dorp -
Paul Moore -
Rob Cliffe -
Steven D'Aprano