<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, May 18, 2018 at 10:49 AM Steven D'Aprano <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, May 18, 2018 at 08:31:36AM -0400, Neil Girdhar wrote:<br>
[...]<br>
> > > I don't like multiple ways of doing the same thing.<br>
> ><br>
> > Ah, like when people want to use "class" as an identifier, and since<br>
> > they can't, they write:<br>
> ><br>
> >     klass cls Class<br>
[...]<br>
> > Remind me again what the "one (obvious) way to do it" is?<br>
> ><br>
> <br>
> In most cases: cls<br>
> <br>
> <a href="https://www.python.org/dev/peps/pep-0008/#function-and-method-arguments" rel="noreferrer" target="_blank">https://www.python.org/dev/peps/pep-0008/#function-and-method-arguments</a><br>
<br>
The immediate next sentence goes on to say:<br>
<br>
    If a function argument's name clashes with a reserved keyword,<br>
    it is generally better to append a single trailing underscore<br>
    rather than use an abbreviation or spelling corruption. Thus<br>
    class_ is better than clss. (Perhaps better is to avoid such<br>
    clashes by using a synonym.)<br>
<br>
So PEP 8 already torpedoes your preference for a single way to spell <br>
words that clash with keywords:<br>
<br>
- use a synonym;<br>
<br>
- or a trailing underscore<br>
<br>
- except for the first argument of class methods, where we<br>
  use the misspelling (or abbreviation) "cls".<br>
<br>
If you object to this proposed verbatim names on the basis of disliking <br>
multiple ways to spell identifies that clash with keywords, that ship <br>
sailed long ago. There has always been multiple ways.<br></blockquote><div><br></div><div>Right.  I think it's pretty clear that there is one way to avoid naming conflict and keep the same name: use a trailing underscore except when it's the first argument to a class method.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But I like to think that verbatim names could become the one OBVIOUS way <br>
to do it in the future.<br></blockquote><div><br></div><div>That's what I don't want. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
[...]<br>
> All of your arguments would have applied to a keyword escaping proposal had<br>
> it been proposed before "given" was even considered.<br>
<br>
Every new idea has to be thought of for the first time. Otherwise it <br>
would have been in the language from day zero and it wouldn't be a new <br>
idea. If it wasn't "given", it could have been for "async" and "await", <br>
if not for them it could have been for "with", if not for "with" it <br>
might have been "yield", and so on.<br>
<br>
There had to be a first time for any idea. I would have <br>
suggested this twenty years ago if I thought of it twenty years ago, but <br>
I didn't, so I didn't. Dismissing the idea because I didn't suggest it <br>
earlier when other keywords were suggested is illogical. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
> The only reason we're<br>
> even considered considering escaping is to keep code that uses "given" as<br>
> an identifier working.<br>
<br>
That might be the only reason YOU are considing it, but it definitely <br>
isn't the only reason for me. And probably not for others.<br>
<br>
In fact, since I strongly dislike the "given" syntax, and really want <br>
that idea to be rejected, anything that increases its chances are a <br>
negative to me.<br>
<br>
Nevertheless, identifiers clashing with keywords isn't something brand <br>
new that only occurs thanks to "given". It has been a pain point <br>
forever. A small one, true, but still a nuisance.<br>
<br>
Verbatim names has the possibility to cut that nuisance value even <br>
further. But not if we short-sightedly limit it to a single case.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
> That's why I prefer the most modest solution of<br>
> only being able to escape given.<br>
<br>
Limiting a general method of mitigating the keyword clashing problem to <br>
a single keyword is as sensible as limiting the pathlib library to only <br>
work with a single hard-coded pathname. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
-- <br>
Steve<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
<br>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Google Groups "python-ideas" group.<br>
To unsubscribe from this topic, visit <a href="https://groups.google.com/d/topic/python-ideas/r1kFC8mYEKk/unsubscribe" rel="noreferrer" target="_blank">https://groups.google.com/d/topic/python-ideas/r1kFC8mYEKk/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href="mailto:python-ideas%2Bunsubscribe@googlegroups.com" target="_blank">python-ideas+unsubscribe@googlegroups.com</a>.<br>
For more options, visit <a href="https://groups.google.com/d/optout" rel="noreferrer" target="_blank">https://groups.google.com/d/optout</a>.<br>
</blockquote></div></div>