I was asked earlier to summarise the the proposal I've been advocating for, but have already gone over the central points a few times. I'll try and find time to write a clear explanation soon.
-- Carl Smith carl.in...@gmail.com On 18 May 2018 at 19:54, Neil Girdhar <mistersh...@gmail.com> wrote: > > > 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/ > >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
