This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients Jim.Jewett, docs@python, ezio.melotti, r.david.murray, rhettinger, steven.daprano
Date 2014-10-11.08:02:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1413014520.88.0.755655422388.issue22001@psf.upfronthosting.co.za>
In-reply-to
Content
> Ah... "be the same object or compare equal" sounds much better.

Yes, the plain language is clear and reads nicely.

> We can't say "will normally", since we don't know about 
> the infinite  number of possible container types that people 
> might create. The most we can say is that *builtin* container 
> types will [assuming that this is  the intent] or that general 
> containers *may*.

"general containers may" is most accurate.  

> Several suggested changes:

Jim, can you propose a much more minimal edit?

As you pointed-out, the underlying logic is "containers are permitted to (and generally do) read "same as" as "is or __eq__".   I don't think we should say much more than that in the section on expressions.

Any notes on NaNs should probably be in a section talking about the float type.  The weirdness of NaNs is a feature of the NaNs, not a feature of the entire language.  We definitely don't want a NaN note added to the documentation of every container.
History
Date User Action Args
2014-10-11 08:02:00rhettingersetrecipients: + rhettinger, ezio.melotti, steven.daprano, r.david.murray, docs@python, Jim.Jewett
2014-10-11 08:02:00rhettingersetmessageid: <1413014520.88.0.755655422388.issue22001@psf.upfronthosting.co.za>
2014-10-11 08:02:00rhettingerlinkissue22001 messages
2014-10-11 08:02:00rhettingercreate