Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Greg Ewing]

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.

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

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Guido van Rossum]

I hereby withdraw the idea.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Steven D'Aprano]

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.


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Jacco van Dorp]

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.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Paul Moore]

On 15 May 2018 at 11:07, Antoine Pitrou  wrote:
> On Tue, 15 May 2018 21:51:20 +1200
> Greg Ewing  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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Antoine Pitrou]

On Tue, 15 May 2018 21:51:20 +1200
Greg Ewing  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.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Greg Ewing]

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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Terry Reedy]

On 5/14/2018 6:58 PM, Greg Ewing wrote:

Terry Reedy wrote:
the first two 'and's in "a and b.and # and error" are tagged. To not 
tag the second would require full parsing,


That particular case could be handled by just not colouring
any word following a dot.


OK, more parsing, even if not complete.  Other cases require looking at 
several other things before or after, depending on the exact proposal.

Okay, more parsing, depending on the exact rules.  Some of the variations (


Some other situations might result in false positives, but
there are cases like that already. Many Python colourisers
colour any occurrence of a builtin function name, even if
it has been shadowed, and people seem to live with that.


For IDLE:
>>> def int(): return 0 # int colored as defined name

>>> int()  # int colored as builtin.
0

Perhaps I should add a check whether defined names are builtins, and if 
so, color them as builtins even after 'def' and 'class'.



It might even be useful, if it alerts people that a name
they're using is reserved in some contexts, and so might
be best avoided.
Since IDLE is especially aimed at beginners, I could think the same 
about shadowing keywords, and leave them always marked as such.



Terry Jan Reedy

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Greg Ewing]

Terry Reedy wrote:
the first two 'and's in "a and b.and # and error" are tagged. 
To not tag the second would require full parsing,


That particular case could be handled by just not colouring
any word following a dot.

Some other situations might result in false positives, but
there are cases like that already. Many Python colourisers
colour any occurrence of a builtin function name, even if
it has been shadowed, and people seem to live with that.

It might even be useful, if it alerts people that a name
they're using is reserved in some contexts, and so might
be best avoided.

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

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Ethan Furman]

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~

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Tim Peters]

[Terry Reedy ]
> ...
> The impact on real-time syntax coloring should be considered.  An re-based
> colorizer, like IDLE's, tags every appearance of keywords outside of strings
> and comments, syntactically correct or not. For instance, the first two
> 'and's in "a and b.and # and error" are tagged. To not tag the second would
> require full parsing, presumably by compiling to AST, and more support code.
> I suspect this would would make coloring slower.  Whether too slow for
> existing machines, I don't know.

I can pretty much guarantee it would be slower - way slower.

But regexps could still do the bulk of it, provided the contexts
remain as simple-minded as the specific ones Guido suggested:

For example, we could allow keywords after 'def' and after a period,

So when the IDLE colorizer regexp finds a match with the "KEYWORD"
group name, don't color it at once.  Instead look back from the start
of the _possible_ keyword match, to see whether it's preceded by

 period maybe_whitespace
or
 "def"-starting-at-a-word-boundary  at_least_one_whitespace

and if so skip coloring.

There are many ways to code that, but - ya - they're annoying.  Alas,
the re module's negative lookbehind assertion isn't powerful enough
for it, else those checks could be added directly to the keyword part
of the colorizing regexp.  I expect (but don't know) that lookbehinds
in MRAB's "regex" module are strong enough for it.

Of course that's just IDLE.  It was remarkably easy to teach my
primary editor (Source Insight) all sorts of stuff about .py files,
but its "keywords" subsystem is restricted to specifying literal
strings to look for.  The kinds of tricks above probably require that
the tool have access to a real programming language (like IDLE and
Emacs enjoy).
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Terry Reedy]

On 5/13/2018 2:19 PM, Guido van Rossum wrote:

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.


This trades the simplicity of 'using a keyword as an identifier always 
fails immediately' for the flexibility of 'using a keyword as an 
identifier may work, or may fail later'.  The failure would be 
predictable in the sense of being being deterministic for any particular 
code string but unpredictable in the sense of not knowing what code 
would be written.  It would also be unpredictable when people use a 
keyword as variable without knowing that they had done so.


The proposal reminds me of the current tkinter situation when using 
tcl/tk compiled without thread support: calling a tkinter function 
(method) from worker threads may work, at least initially, but may 
eventually fail.  The main problem here is that this is not documented. 
But I suspect that if and when it is 
(https://bugs.python.org/issue33479), most will 'not do that' and only a 
few intrepid souls will do the necessary experiments.


The impact on real-time syntax coloring should be considered.  An 
re-based colorizer, like IDLE's, tags every appearance of keywords 
outside of strings and comments, syntactically correct or not. For 
instance, the first two 'and's in "a and b.and # and error" are tagged. 
To not tag the second would require full parsing, presumably by 
compiling to AST, and more support code.  I suspect this would would 
make coloring slower.  Whether too slow for existing machines, I don't know.


--
Terry Jan Reedy

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Ed Kellett]

On 2018-05-14 12:35, Rhodri James wrote:
> On 13/05/18 19:19, Guido van Rossum wrote:
>> 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.
> 
> I'm not familiar with the innards of the parser and it's wy too long
> since I sat through a parsing course, but can you turn that inside out?
> Are there times when the compiler knows it must be looking at a keyword,
> not a name?  I suspect not, given that arbitrary expressions can be
> statements, but someone else may have a more knowledgeable opinion.

Sure are. For example, just after `1 `, a name would be an error, while
a keyword would be fine. But, more to the point, there are times when
the parser knows (or could know) it can't be looking at a certain
keyword. Suppose you want to parse at the beginning of an expression
when you see "and". Currently, you're duty-bound to explode, because
"and" cannot begin an expression. You *could* equally well not explode
and, knowing that "and" cannot begin an expression, interpret it
completely unambiguously as a name.



signature.asc
Description: OpenPGP digital signature
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Rhodri James]

On 13/05/18 19:19, Guido van Rossum wrote:

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.


I'm not familiar with the innards of the parser and it's wy too long 
since I sat through a parsing course, but can you turn that inside out? 
Are there times when the compiler knows it must be looking at a keyword, 
not a name?  I suspect not, given that arbitrary expressions can be 
statements, but someone else may have a more knowledgeable opinion.


--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Greg Ewing]

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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Nick Coghlan]

On 13 May 2018 at 14: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
> ,
> and we can't use 'given' because it's used in Hypothesis
> .)
>
> 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.
>

While I think the "restricted use" idea would be confusing, I do like the
idea of separating out "postfix keywords", which can't start a statement or
expression, and hence can be used *unambiguously* as names everywhere that
names are allowed.

Adding such a capability is essential to proposing a keyword based approach
to inline assignments, and would technically also allow "and", "or", "is",
and "as" to be freed up for use as names.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Carl Smith]

As long as any new syntax allowed us to still reference the occassional
thing in the older libraries that used newly reserved names, it would
not come up that often, and would avoid the biggest cost of a whole
new version.

If `foo` was a reserved word, then this could be allowed...

import foo as bar

...but not these...

import foo
import bar as foo

The same could be done with params, so this would be illegal...

def f(foo): ...

...but this would be fine...

f(foo=1)

It would be illegal to define a property named `foo`, but you could
still do `bar.foo` to use a library, etc.

It could be done, but it's not especially relevant here, so I'll shut up
now.


-- Carl Smith
carl.in...@gmail.com

On 14 May 2018 at 03:47, Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:

>
>
> 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
> ,
> and we can't use 'given' because it's used in Hypothesis
> .)
>
> 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).
>
>
> Please, imagine how you would write the documentation to explain this.
> Then, please, put yourself in the position of someone who teaches Python
> trying to explain it.
> Regards
> Rob Cliffe
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Rob Cliffe via Python-ideas]

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.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Rob Cliffe via Python-ideas]

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 
, 
and we can't use 'given' because it's used in Hypothesis 
.)


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




Please, imagine how you would write the documentation to explain this.
Then, please, put yourself in the position of someone who teaches Python 
trying to explain it.

Regards
Rob Cliffe
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Nathaniel Smith]

On Sun, May 13, 2018 at 9:00 PM, Greg Ewing  wrote:
> Guido van Rossum wrote:
>>
>> Of course this would still not help for names of functions that might be
>> imported directly (do people write 'from numpy import where'?).
>
>
> Maybe things could be rigged so that if you use a reserved word
> as a name in an import statement, it's treated as a name everywhere
> else in that module. Then "from numpy import where" would Just Work.

'from numpy import *' is also common.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Carl Smith]

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.in...@gmail.com

On 14 May 2018 at 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.
>
>
> --
> 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/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Greg Ewing]

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/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Greg Ewing]

Elias Tarhini wrote:
The thought of writing "operator.not" is appealing, but 
being forced to use *that* (with *from operator import not* being 
non-allowable) may not be.


Under the proposal I made in my last post, "from operator import not"
would be fine -- you just wouldn't be able to use the "not" operator
anywhere in the module then. :-)

A more nuanced version would have the effect restricted to the
scope the import appears in, so that you could write

   def f():
  from operator import not
  # 'not' is now an ordinary name inside this
  # function, but it's business as usual elsewhere

Someone else can figure out how to make the parser handle
this, though. :-)

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

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Greg Ewing]

Guido van Rossum wrote:
Of course this would still not help for names of functions that might be 
imported directly (do people write 'from numpy import where'?).


Maybe things could be rigged so that if you use a reserved word
as a name in an import statement, it's treated as a name everywhere
else in that module. Then "from numpy import where" would Just Work.

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

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Rob Cliffe via Python-ideas]

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 
, 
and we can't use 'given' because it's used in Hypothesis 
.)


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



This would not prevent code breakage when a new keyword was added. It 
would only reduce the amount of code broken.  Although in my 
unsubstantiated opinion not by very much; I suspect that most of the 
time an identifier is used in a module, it is used at least once in 
contexts where it would still be a SyntaxError if it were a keyword.

Rob Cliffe
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Tim Peters]

[Guido]
> ...
> 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).

The Fortran standards continued evolving, and still are, but despite
that in many ways it's become a much more "modern" language, while it
continues to add ever more keywords it _still_ has no reserved words.
They have a strong reason for that:  there are numeric libraries coded
decades ago in Fortran still in use, which nobody understands anymore,
so anything that breaks old code is fiercely opposed.  If you think
people whine today about an incompatible Python change, wait another
30+ years to get a sense of what it's like in the Fortran community
;-)

I'm not sure people realize that Algol had no reserved words either.
But that was "a trick" :-)  Algol was originally designed as a formal
notation for publishing algorithms, not really for executing them.
Published Algol "code" always showed the language's keywords in
boldface..

Similarly, the nearly incomprehensible (to me) Algol 68's 60 "reserved
words" are essentially defined to be in boldface in the
"representation" (for publication) language, but can also be used as
identifiers etc.  The intimately related but distinct "reference
language" needs to be used for computer input.  In that the reserved
words are decorated in some way, to distinguish them from user-defined
names of the same spelling. There's more than one way to do that, and
- indeed - it's required that Algol 68 compilers support several
specific ways.  Anyone looking for more pain can get it here:

https://en.wikipedia.org/wiki/ALGOL_68#Program_representation


Note that Perl largely (but not entirely) managed to dodge the problem
by requiring a punctuation character (like $ for scalar and @ for
array) before variable names.


In addition to REXX (already mentioned), Prolog and PL/I had no reserved words.

End of brain dump ;-)

But I didn't suggest that for Python.  It's a bit too late for that
anyway ;-)  It was more in line with what you suggested here:  think
more about ways in which reserved words _could_ be allowed as
identifiers in specific contexts where implementing that doesn't
require heroic effort.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Nathan Schneider]

Care would have to be taken in the grammar to avoid syntactic ambiguity.
For example:

x = 1
def not(x):
...

if not - x: # Is this 'not' the keyword or the identifier? not (-x), or not
minus x?
...

Nathan

On Sun, May 13, 2018 at 2:20 PM 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
> ,
> and we can't use 'given' because it's used in Hypothesis
> .)
>
> 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).
>
> Of course this would still not help for names of functions that might be
> imported directly (do people write 'from numpy import where'?). And it
> would probably cause certain typos be harder to diagnose.
>
> 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!
>
> --
> --Guido van Rossum (python.org/~guido)
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Rob Cliffe via Python-ideas]

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 
, 
and we can't use 'given' because it's used in Hypothesis 
.)


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 )


Best wishes
Rob Cliffe
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Elias Tarhini]

Apologies for my initial response. Looks like I failed to expand the
initial email fully, which would have shown me the following :)

> Of course this would still not help for names of functions that might be
imported directly (do people write 'from numpy import where'?).

-- I do think the *import keyword as keyword_* concept has merit, however.

(This would also be a simple retroactive solution to the asyncio.async
problem, wouldn't it?)

On Sun, May 13, 2018, 11:45 AM Chris Angelico  wrote:

> On Mon, May 14, 2018 at 4:19 AM, Guido van Rossum 
> wrote:
> > 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.
> > ...
> > 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).
>
> I spent most of the 1990s coding in REXX, which has exactly zero
> reserved words. You can write code like this:
>
> if = 1
> then = "spam"
> else = "ham"
>
> if if then then
> else else
>
> do = 5
> do do
> print("Doobee doobee doo"
> end
>
> The problem is that you can go a long way down the road of using a
> particular name, only to find that suddenly you can't use it in some
> particular context. Common words like "if" and "do" are basically
> never going to get reused (so there's no benefit over having actual
> keywords), but with less common words (which would include the
> proposed "where" for binding expressions), it's entirely possible to
> get badly bitten.
>
> So the question is: Is it better to be able to use a keyword as an
> identifier for a while, and then run into trouble later, or would you
> prefer to be told straight away "no, sorry, pick a different name"?
>
> ChrisA
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Brendan Barnwell]

On 2018-05-13 11: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
,
and we can't use 'given' because it's used in Hypothesis
.)

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

Of course this would still not help for names of functions that might be
imported directly (do people write 'from numpy import where'?). And it
would probably cause certain typos be harder to diagnose.


Spooky!  :-)

	People definitely do write "from numpy import where".  You can see 
examples just by googling for that string.  And that's only finding the 
cases where "where" is the first thing in the from clause; there are 
probably many more where it's something like "from numpy import array, 
sin, cos, where".


	I think this kind of special casing would be really confusing though. 
It would mean that these two would work (and do the same thing):


import np
np.array(...)

from np import array
array(...)

And this would work:

import np
np.where(...)

But then this would fail:

from np import where
where(...)

	That would be really puzzling.  Plus, we'd still have the problem of 
backwards compatibility.  Before the new "where" keyword was introduced, 
the last example WOULD work, but then afterwards you'd have to change it 
to look like the third example.  This might induce wary programmers to 
hide all names behind a period (that is, find a way to do "foo.bar" 
instead of just "bar" whenever possible) in order to guard against 
future keywordization of those names.


	The other thing is that I suspect use of such a privilege would explode 
due to the attractiveness of the reserved words.  That is, many 
libraries would start defining things named "and", "or", "with", "is", 
"in", etc., because the names are so nice and short and are useful in so 
many situations.  So there'd be nowhere to hide from the deluge of names 
shadowing keywords.


--
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."

   --author unknown
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Stephan Houben]

Note that Javascript does something similar,
in that reserved keywords are allowed in member access.

var x = {if : 42};
console.log(x.if);

Stephan


2018-05-13 20:42 GMT+02:00 Eric Fahlgren :

> On Sun, May 13, 2018 at 11:20 AM Guido van Rossum 
> wrote:
>
>> For example, we could allow keywords after 'def' and after a period, and
>> then the following would become legal:
>>
>
> ​Our modeling database overloads getattr/setattr (think SQLAlchemy) to
> allow us to access to database fields as if they were Python data members.
> Nothing new here, but we do have problems with keyword collisions on some
> of the objects, as we are wrapping an already-existing modeling language
> (MSC Adams Solver dataset) with our objects.  We were pleased with 'print'
> became a function, because it removed the restriction from that one, but
> one of the remaining ones is 'return', like this:
>
> class Sensor:
> def __init__(self):
> setattr(self, "print", 0)
> setattr(self, "return", 0)
>
> s = Sensor()
> s.print  # Works now, didn't in Python 2.
> s.return  # Bork.
>
> I have a decades old +1 on this.
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Chris Angelico]

On Mon, May 14, 2018 at 4:19 AM, Guido van Rossum  wrote:
> 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.
> ...
> 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).

I spent most of the 1990s coding in REXX, which has exactly zero
reserved words. You can write code like this:

if = 1
then = "spam"
else = "ham"

if if then then
else else

do = 5
do do
print("Doobee doobee doo"
end

The problem is that you can go a long way down the road of using a
particular name, only to find that suddenly you can't use it in some
particular context. Common words like "if" and "do" are basically
never going to get reused (so there's no benefit over having actual
keywords), but with less common words (which would include the
proposed "where" for binding expressions), it's entirely possible to
get badly bitten.

So the question is: Is it better to be able to use a keyword as an
identifier for a while, and then run into trouble later, or would you
prefer to be told straight away "no, sorry, pick a different name"?

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Eric Fahlgren]

On Sun, May 13, 2018 at 11:20 AM Guido van Rossum  wrote:

> For example, we could allow keywords after 'def' and after a period, and
> then the following would become legal:
>

​Our modeling database overloads getattr/setattr (think SQLAlchemy) to
allow us to access to database fields as if they were Python data members.
Nothing new here, but we do have problems with keyword collisions on some
of the objects, as we are wrapping an already-existing modeling language
(MSC Adams Solver dataset) with our objects.  We were pleased with 'print'
became a function, because it removed the restriction from that one, but
one of the remaining ones is 'return', like this:

class Sensor:
def __init__(self):
setattr(self, "print", 0)
setattr(self, "return", 0)

s = Sensor()
s.print  # Works now, didn't in Python 2.
s.return  # Bork.

I have a decades old +1 on this.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Crazy idea: allow keywords as names in certain positions

[Elias Tarhini]

I like it! The obvious question, though: How would "*from package import
keyword*" be handled, if not simply by SyntaxError? Would *from package
import keyword as keyword_* be allowed?

In a similar vein, what would happen with stdlib functions like
operator.not_? The thought of writing "operator.not" is appealing, but
being forced to use *that* (with *from operator import not* being
non-allowable) may not be.

On Sun, May 13, 2018, 11:20 AM 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
> ,
> and we can't use 'given' because it's used in Hypothesis
> .)
>
> 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).
>
> Of course this would still not help for names of functions that might be
> imported directly (do people write 'from numpy import where'?). And it
> would probably cause certain typos be harder to diagnose.
>
> 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!
>
> --
> --Guido van Rossum (python.org/~guido)
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Crazy idea: allow keywords as names in certain positions

[Guido van Rossum]

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
,
and we can't use 'given' because it's used in Hypothesis
.)

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

Of course this would still not help for names of functions that might be
imported directly (do people write 'from numpy import where'?). And it
would probably cause certain typos be harder to diagnose.

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!

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/