On Fri, May 18, 2018 at 10:49 AM Steven D'Aprano <steve@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+unsubscribe@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/