[Python-ideas] checking for identity before comparing built-in objects

[Guido van Rossum]

On Sun, Oct 7, 2012 at 7:33 PM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> On Sun, Oct 7, 2012 at 9:51 PM, Guido van Rossum <guido at python.org> wrote:
>> Referencing Java here is absurd and I still consider this suggestion
>> as a troll. Python is not in any way based on Java.
>
> I did not suggest that.  Sorry if it came out this way.  I am well
> aware that Python and Java were invented independently and have
> different roots.  (IIRC, Java was born from Oak and Python from ABC
> and Oak and ABC were both developed in the 1980s.)  IEEE 784 precedes
> both languages and one team decided that equality reflexivity for
> hashable objects was more important than IEEE 784 compliance while the
> other decided otherwise.
>
> Many Python features (mostly library) are motivated by C.  In the 90s,
> "because C does it this way" was a good explanation for a language
> feature.  Doing things differently from the "C way", on the other hand
> would deserve an explanation.  These days, C is rarely first language
> that a student learns.  Hopefully Python will take this place in not
> so distant future, but many students graduated in late 90s - early
> 2000s knowing nothing but Java.   As a result, these days it is a
> valid question to ask about a language feature: "Why does Python do X
> differently from Java?"  Hopefully in most cases the answer is
> "because Python does it better."

Explaining the differences between Python and Java is a job for
educators, not for the language reference.

I agree that documenting APIs as "this behaves just like C" does not
have the same appeal -- but that turn of phrase was mostly used for
system calls anyway, and for those I think that a slightly modified
redirection (to the OS man pages) is still completely appropriate.

> In case of nan != nan, I would really like to know a modern reason why
> Python's way is better.  Better compliance with a 20-year old standard
> does not really qualify.

I am not aware of an update to the standard. Being 20 years old does
not make it outdated.

Again, there are plenty of reasons (you have to ask the numpy folks),
but I don't think it is the job of the Python reference manual to give
its motivations. It just needs to explain how things work, and if that
can be done best by deferring to an existing standard that's fine.

Of course a tutorial should probably mention this behavior, but a
tutorial does not have the task of giving you the reason for every
language feature either -- most readers of the tutorial don't have the
context yet to understand those reasons, many don't care, and whether
they like it or not, it's not going to change.

You keep getting very close to suggesting to make changes, despite
your insistence that you just want to know the reason. But assuming
you really just are asking in an obnoxious way for the reason, I
recommand that you ask the people who wrote the IEEE 754 standard. I'm
sure their explanation (which I recall having read once but can't
reproduce here) makes sense for Python too.

-- 
--Guido van Rossum (python.org/~guido)