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