>From my point of view as someone who sometimes help Scientist write
Python, this is a no go, there are too many cases where == and is are
different.
$ ipython
Python 3.8.5 | packaged by conda-forge | (default, Sep 16 2020, 17:43:11)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.25.0 -- An enhanced Interactive Python. Type '?' for help.
In [1]: import numpy as np
In [2]: a = np.array([True, False, None])
In [3]: a == True, a == False, a == None
Out[3]:
(array([ True, False, False]),
array([False, True, False]),
array([False, False, True]))
In [4]: a is True, a is False, a is None
Out[4]: (False, False, False)
if `a == True` can even raise errors when in ifs:
In [5]: if a == True:
...: pass
...:
---------------------------------------------------------------------------
ValueError Traceback (most recent call last)
<ipython-input-5-59a850ef5f8d> in <module>
----> 1 if a == True:
2 pass
3
ValueError: The truth value of an array with more than one element is
ambiguous. Use a.any() or a.all()
Basic types are just too simple to expose the real need between `==`
and `is`, but that's not a reason not to give the right advice from
the start.
IMHO It would be like teaching English and saying that it's ok not to
put s after nouns when there is a number in front as it's obvious
there are many.
I do understand your concern, but I believe that would be just pushing
the problem to later, when it would be much more difficult to explain
and have students get a wrong mental model from the start, which is
really hard to overcome.
--
Matthias
On Mon, 30 Aug 2021 at 11:45, Nick Parlante <n...@cs.stanford.edu> wrote:
>
> Hi there python-ideas - I've been teaching Python as a first
> programming language for a few years, and from that experience I want
> to propose a change to PEP8. I'm sure the default position for PEP8 is
> to avoid changing it. However, for this one rule I think a good case
> can be made to make it optional, so let me know what you think.
>
> Let me start with what I've learned from teaching students in Java and
> now in Python. In Java, you use == for ints, but you need to use
> equals() for strings. Of course students screw this up constantly,
> using == in a context that calls for equals() and their code does not
> work right. Then for Java arrays a different comparison function is
> required, and so it goes. To teach comparisons in Python, I simply say
> "just use ==" - it works for ints, for strings, even for lists.
> Students are blown away by how nice and simple this is. This is how
> things should work. Python really gets this right.
>
> So what is the problem?
>
> 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.
>
> 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.
>
> My guess is that this rule is in PEP8 because, within a Python
> implementation, it is within the programmer's mental model that, say,
> False is a singleton. The mandatory-is rule is in PEP8 to reinforce
> that mental model by requiring the is operator. Plus it probably runs
> a tiny bit faster.
>
> 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. That's not much of a benefit, and it's kind of circular. Like
> if programmers were permitted to use ==, they wouldn't need to know
> the details of how Python allocates those values. Being shielded from
> implementation details is a Python strength - think of the Java vs.
> Python story above. Is Java better because it builds an awareness in
> the programmer of the different comparison functions for different
> types? Of course not! Python is better in that case because it lets
> the programmer simply use == and not think about those details.
> Understanding the singleton strategy is important in some corners of
> coding, but forcing the is operator on all Python code is way out of
> proportion to the benefit.
>
> 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.
>
> As a teacher, this is especially jarring since the "just use ==" rule
> is so effortless to use correctly. In contrast, the mandatory-is rule
> adds a little pause where the programmer should think about which
> comparison operator is the correct one to use. It's not hard, but it
> feels unnecessary.
>
> As a contrasting example, in the language C, programmers need to
> understand == vs. is right from the first day. You can't get anything
> done in C without understanding that distinction. However that is just
> not true for regular (not-Python-implementation) Python code, where ==
> works correctly for the great majority of cases.
>
> 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).
>
> 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.
>
> PEP8 was originally just for Python implementations, so why is this
> change needed? Because as a practical matter, the vast majority of
> code that is using PEP8 is not part of a Python implementation. This
> may not have been the original mission of PEP8, but it is how things
> have worked out.
>
> 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.
>
> Ultimately this comes down to the question - should PEP8 push regular,
> not-Python-implementation code to use is for singletons in cases where
> == works perfectly? Seeing how effortless it is for programmers to use
> == as their first choice, I think PEP8 should allow that practice.
>
> Best,
>
> Nick
> _______________________________________________
> 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/JWLKBT2YYDGFS76Z37FZJNZPEDVXOLCW/
> 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/SV26LBB722A5AFY2WS24UHYSLEWGKGR4/
Code of Conduct: http://python.org/psf/codeofconduct/
