Hi Chris - thanks for the response,

so here you say:

I disagree; experienced programmers should be using "is" where it's
correct.

I'd like to unpack that a little - like what do you mean by "correct" there. My guess is "correct" means the code gets the right answer for all inputs.

Like for "if x == None:" works right

By that definition, == is correct there. I think PEP8 has forced people to use "is" so much, they've lost touch with the reality that in fact == would work perfectly in almost all cases. Situations where "is" is required for correctness are very rare.

The argument for mandatory-is is not based on correctness - PEP8 doesn't say to use is where it's needed. What's key here is that PEP8 is forcing "is" into situations where it is *not needed*. So the justification for mandatory-is needs to work more on esthetics - like "is" is not required there for correctness, but we want to require it because it reinforces in the code how certain values are allocated, plus as mentioned I think it runs a little faster.

Is this esthetic so great that we don't permit the simpler practice of using == where it works fine?

Best,

Nick






PEP8 mandatory-is is not using that standard - it's forcing "is" in a kind of decorative way, I suspect to reinforce that None is allocated once, but the number 2000



On Mon, Aug 30, 2021 at 12:09 PM Chris Angelico <rosuav@gmail.com> wrote:
On Tue, Aug 31, 2021 at 4:46 AM Nick Parlante <nick@cs.stanford.edu> wrote:
> The problem for Python is what I will call the "mandatory-is" rule in
> PEP8, which reads:
>
> Comparisons to singletons like None should always be done with is or
> is not, never the equality operators.

The question is whether you're testing whether some value IS something
else, or whether it IS EQUAL TO, and that's an important one. If x IS
None, then it cannot possibly be anything else; but it can be EQUAL TO
a number while being a different form of it. For instance:

>>> 5 == 5.0
True

But there will never be any other None. There cannot ever be another
True or False either, nor another Ellipsis. If you're asking about
those, you're not asking "is this equal to None?", you are asking "is
this thing the special value None?". Since those are different
questions, the distinction needs to remain.

However!

> For the students, this comes up in the first week of the course with
> lines like "if x == None:" which work perfectly with == but should use
> is/is-not for PEP8 conformance.

This isn't a major problem. When you're just teaching something for
the first time, you don't have to worry about that distinction. I
don't see any issue with teaching them "just use ==" initially, and
introducing the importance of object identity later (maybe alongside
something about mutable objects).

> However, for "regular" Python code, not implementing Python, forcing
> the use of is instead of the simpler == is unneeded and unhelpful (and
> analogously forcing "is not" when != works correctly). What is the
> benefit of forcing the is operator there? I would say it spreads an
> awareness of the details of how certain values are allocated within
> Python.

It's not about implementation (although you're right that identity
checks can be faster); the two operators ask different questions.

> As a practical matter, the way this comes up for my students is that
> IDEs by default will put warning marks around PEP8 violations in their
> code. Mostly this IDE-coaching is very helpful for students learning
> Python. For example, It's great that beginning Python programmers
> learn to put one space around operators right from the first day.
> Having taught thousands of introductory Python students, the one PEP8
> rule that causes problems is this mandatory-is rule.

That's a good reason to reconfigure your IDE. If it's set up in a way
that is bad for teaching, change your IDE configs. (Ideally, that's a
simple matter of providing a JSON or YAML file and saying "save this
into this location". The students don't need to understand what that
file is saying, but it will solve their issues.)

> Here is my proposal:
>
> Add the following parenthetical to the mandatory-is rule: (this rule
> is optional for code that is not part of an implementation of Python).

https://www.python.org/dev/peps/pep-0008/#introduction
"Many projects have their own coding style guidelines. In the event of
any conflicts, such project-specific guides take precedence for that
project."

EVERYTHING in that document is optional for code that isn't part of
the Python standard library.

> So in effect, programmers outside of a Python implementation can
> choose to use == or is for the "if x == None:" case. In this way, PEP8
> conforming code before the change is still conforming. Moving forward,
> I would expect that regular code will trend towards using == in such a
> case, reserving is for the rare cases where it is needed for
> correctness.

I disagree; experienced programmers should be using "is" where it's
correct. But students who are freshly learning the language are
welcome to do otherwise, just as they're very likely to violate other
style recommendations. It's not a problem. (For instance, I frequently
see people put spaces around equals signs in keyword args. That's a
violation of PEP 8, but if it's not part of the standard library, no
big deal.)

> Now we are in a situation where the rules in PEP8 are sent out to this
> ocean of Python programmers of many different ability levels writing
> regular code that is not a Python implementation. One could imagine a
> separate PEP800 style guide for regular code, but we don't need to do
> that, because in almost all cases PEP8 works great for regular code. I
> have taught thousands of new Python programmers, and the only place
> where PEP8 serves them poorly is this mandatory-is rule. Therefore
> instead of a separate style guide for regular code, I propose an
> exception for this one problem rule.

Make your own style guide. Enforce it to the exact extent that it
matters for you. You can even say "follow PEP 8 where it does not
conflict with this guide" to take advantage of the parts you like,
while still having all the freedom you need.

PEP 8 is not, and never has been, a set of mandatory rules for all
Python programmers. Nobody will arrest you for violating it, least of
all the Python Secret Underground, which emphatically does not exi[NO
CARRIER

ChrisA
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5QPN2V2VEMCNSMGJPJH5XRGUILZN3IXO/
Code of Conduct: http://python.org/psf/codeofconduct/