
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