On Thursday, May 17, 2018 at 5:40:05 PM UTC-4, Carl Smith wrote:

...

My preference is to do nothing. If you end up making "where" a keyword in Python 3.8, numpy will probably: * rename their where function to "where_" in 3.8 * add a where_ alias in Python < 3.8.

This assumes that every library that defines something named `where` (and every library that references it) are maintained​. If the parser just starts treating `where` as a keyword, working code will not parse. That may be acceptable (I don't know what the policy is), but it makes introducing keywords more costly than an approach that allows old code to continue working.

Fair enough. If that solution is taken, I want the linters to complain about verbatim uses as a stopgap measure that ultimately should be removed. I don't think interfaces should be naming functions and arguments: "if", "while", etc. I think PEP 08 should discourage its use as well except when it's necessary to continue to use an unmaintained interface.

-- Carl Smith carl....@gmail.com javascript:

On 17 May 2018 at 19:41, Neil Girdhar javascript:> wrote:

...

My preference is to do nothing. If you end up making "where" a keyword in Python 3.8, numpy will probably: * rename their where function to "where_" in 3.8 * add a where_ alias in Python < 3.8.

And then people will have to fix their code in 3.8 anyway. Only instead of learning a new verbatim syntax, they will just add the familiar underscore.

One thing that should ideally be done is to improve the SyntaxError processing to special case use of keywords in places that identifiers are used. Instead of:

In [1]: for if in range(10): File "<ipython-input-1-a51677fa6668>", line 1 for if in range(10): ^ SyntaxError: invalid syntax

How about

In [1]: for if in range(10): File "<ipython-input-1-a51677fa6668>", line 1 for if in range(10): ^ SyntaxError: "if" was used where a variable belongs, but "if" is a keyword. Consider using "if_" instead.

Similarly,

In [2]: int.if File "<ipython-input-2-72291900e846>", line 1 int.if ^ SyntaxError: "if" was used where an attribute name belongs. Did you mean "if_"?

SyntaxError doesn't need to quickly generate its error strings. So there is only an upside to having clear error messages.

On Thursday, May 17, 2018 at 1:54:42 PM UTC-4, Stephan Houben wrote:

...

Fortunately we have Unicode bold characters nowadays

𝐢𝐟 if 𝐢𝐧 in: 𝐫𝐞𝐭𝐮𝐫𝐧 return

Look ma! No syntactic ambiguity!

That's hilarious :)

...

Stephan

2018-05-17 19:10 GMT+02:00 Chris Barker via Python-ideas < python...@python.org>:

...

On Wed, May 16, 2018 at 2:09 PM, Carl Smith wrote:

...

If your position is that Guido shouldn't introduce keywords that are currently used as names at all,

Exactly -- which is why I'm wondering my no one (that I've seen -- long thread) is presenting the backwards option:

Any new keywords introduced will be non-legal as regular names.

\new_key_word

for instance.

Makes me think that it may have been good to have ALL keywords somehow non-legal as user-defined names -- maybe ugly syntax, but it would make a clear distinction.

how ugly would this be?

\for i in range(n): \while \True: ...

pretty ugly :-(

But maybe not so much if only a handful of new ones....

Or is there another currently illegal character that could be used that would be less ugly?

I'm actually confused as to what the point is to the \ prefix idea for names:

* It would still require people to change their code when a new keyword was introduced

* It would be no easier / harder than adding a conventional legal character -- trailing underscore, or ???

* but now the changed code would no longer run on older versions of python.

I guess it comes down to why you'd want to call out:

"this is a name that is almost like a keyword"

Seems like a meh, meh, lose proposal to me.

OK, I see one advantage -- one could have code that already has BOTH word and word_ names in it. So when word becomes a keyword, a tool that automatically added an underscore would break the code. whereas if it automatically added an currently illegal character, it wouldn't shadow anything.

But a sufficiently smart tool could get around that, too.

-CHB

--

Christopher Barker, Ph.D. Oceanographer

Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception

Chris....@noaa.gov

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

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