On Wed, May 16, 2018 at 10:26 AM, Carl Smith <carl.input@gmail.com> wrote:
Thanks for the reply Todd.

If `True` was redefined somewhere else, it would still be `True` for you. You could do `from oldlib import True as true` and have `true` equal `np.bool_(1)`. You could reference `oldlib.True` or do `oldlib.function(True=x)` to interact with the name in the old library.


Not if you need to make changes in the same tens of thousands of lines file. 
 
None of this would actually apply to `True`, as it's a reserved word in all versions. The proposal only applies to new keywords that are used as names in other libraries.

No it isn't.  It was added in Python 2.3 and only became a keyword in Python 3.  Prior to that lots of other packages defined their own "True" (or "true" or "TRUE", etc), which is why it wasn't made a keyword for such a long time. 

But this is just an example of the sort of problem that can come up with your approach.  The overall issue is that python has no way of knowing if the keyword is being used for legitimate backwards-compatibility purposes or someone intentionally overrode after it was made a keyword because they somehow thought it was a good idea.  That is why being explicit about overriding the keyword is so important.

 
Again, thanks for taking the time.


On 16 May 2018 at 14:46, Todd <toddrjen@gmail.com> wrote:
On Tue, May 15, 2018, 23:03 Carl Smith <carl.input@gmail.com> wrote:
 
On Tue, May 15, 2018 at 8:41 PM, Steven D'Aprano <steve@pearwood.info> wrote:
Inspired by Alex Brault's  post:

https://mail.python.org/pipermail/python-ideas/2018-May/050750.html

I'd like to suggest we copy C#'s idea of verbatim identifiers, but using
a backslash rather than @ sign:

    \name

would allow "name" to be used as an identifier, even if it clashes with
a keyword.

I strongly disagree, but can't seem to get anyone
​ to bite.

We want to be able to introduce a keyword that was formally a name, still
allow 
it to be used as a name, still allow code that uses it as a keyword to
interoperate
​ ​
with code that uses it as a name
, without changing the language
or implementation 
too much.

​Ideally, Python would still not allow the keyword to be used as a name and a
keyword in the same file??

The lexer could class the tokens as keynames, and the parser could use the
context of the first instance of each keyname to determine if it's a name or
keyword for the rest of that file. Projects that used the word as a name would
only be prevented from also using it as a keyword in the same file.

It's really then a question of whether users could elegantly and naturally
reference a name in another module without introducing the name to the
current module's namespace.

We only reference external names (as syntactic names) in import statements,
as properties after the dot operator, and as keyword arguments.

If code that used the word as a keyword was still allowed to use the word as
a name after the dot operator and as a keyword argument *in an invocation*,
it would only change the language in a subtle way.

If we could reference keynames in import statements, but not import the name,
so basically allow `from keyname import keyname as name`, but not allow
`import keyname`, we could still easily import things that used the keyname
as a name. This wouldn't change the language too dramatically either. 

Maybe I'm just being dumb, but it seems like three subtle changes to the
language would allow for everything we want to have, with only minor limitations
on the rare occasion that you want to use the new keyword with a library that is
also using the same keyword as a name.

I promise not to push this idea again, but would really appreciate someone taking
a couple of minutes to explain why it's not worth responding to. I'm not offended,
but would like to know what I'm doing wrong.

Thanks.


I think your idea would work okay if everyone followed good programming practices.  But when you have files that are tens of thousands of ugly code written by dozens of non-programmers over a dozen years it sounds like a recipe for a nightmare. 

For example someone you never met that left your group ten years ago could have made "True" be "np.bool_(1)" on a whim that makes your code break later in very hard-to-debug ways.

To put it simply, I think it encourages people to take convenient shortcuts with implications they don't understand.

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