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 <ros...@gmail.com> wrote: > On Tue, Aug 31, 2021 at 4:46 AM Nick Parlante <n...@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-le...@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/ >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/PDMCADHUO3EIYT2BVM72FH6Y6EN5TPRJ/ Code of Conduct: http://python.org/psf/codeofconduct/
