[Python-ideas] Verbatim names (allowing keywords as names)

[Carl Smith]

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.input at gmail.com

On 18 May 2018 at 19:54, Neil Girdhar <mistersheik at gmail.com> wrote:

>
>
> On Fri, May 18, 2018 at 10:49 AM Steven D'Aprano <steve at 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 at 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+unsubscribe at googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180519/72aad8c2/attachment.html>