On Sun, Oct 7, 2012 at 7:33 PM, Alexander Belopolsky email@example.com wrote:
On Sun, Oct 7, 2012 at 9:51 PM, Guido van Rossum firstname.lastname@example.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.