On Tue, Aug 31, 2021, 17:24 Nick Parlante <n...@cs.stanford.edu> wrote:
> Hi Chris - well maybe we're looking at different questions. Your examples > show it is possible to construct a data type where == None does not work. > Clearly that is possible. > > 1. One conclusion is that the possibility of such == means that in general > the == None form is unreliable. This is the proper mindset of the Python > implementation, where the classes that need to work are practically > unlimited, so relying on == would be unreliable as shown. > > 2. However, I am interested in the mass of ordinary looking programs that > use strings, lists, ints, dicts, tuples, functions etc. to solve some > problem. It's extremely likely that all of the classes in such a program > have a reasonable definitions of ==. So if the programmer knows that, they > can use the "== None" form in complete confidence. It works perfectly. > > It's possible to treat (1) as kind definitive, like that possibility ends > the argument. I agree (1) is true, but do not find it convincing about the > (2) case. I think (2) is more useful for thinking about Python programs in > the world. > > Best, > > Nick > We have two approaches: 1. An approach that is guaranteed to always work no matter what. 2. An approach that will randomly break depending on potentially undocumented implementation details of the data you are using, including for some of th most common uses-cases for python. Both approaches use the same number of characters, the same complexity as far as users are concerned, and rely on concepts that anyone with a basic understanding of the language needs to know. So why would anyone choose to you approach 2? You insist that both approaches should be treated as equally valid. But they simply aren't. In the real world, where people are trying to do almost anything useful with python, approach 2 is too dangerous to rely on. There are just not that many real-world uses-cases that use nothing but the core python types. As you said, there are things that are subconsciously hard for people to avoid. One is leaving warnings in the IDE unfixed. Another, however, is forming habits. We want to encourage people to make good habits that will serve them well generally, not bad habits that wil usually work okay in a narrow context but will break everything as soon as they are applied in common, real-world situations. What you are advocating is a bad habit. Yes, it can work okay in some situations, but why should we be encouraging bad habits when there is no downside whatsoever to the good alternative? If you want to encourage bad habits you should be using perl or MATLAB.
_______________________________________________ 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/WUXRDJ4A4DG2CJRGJE3S7QUVQWER6DR6/ Code of Conduct: http://python.org/psf/codeofconduct/
