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 RK-5wWm9h
Recipients RK-5wWm9h, docs@python
Date 2017-01-19.14:40:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1484836831.64.0.870722472975.issue29323@psf.upfronthosting.co.za>
In-reply-to
Content
PROBLEM (IN BRIEF):
In the currently published 2.7.13 The Python Standard Library (Library Reference manual) section 5.6 "Sequence Types" (https://docs.python.org/2/library/stdtypes.html#sequence-types-str-unicode-list-tuple-bytearray-buffer-xrange):

    "to compare equal, ... the two sequences must be of the same type"

This an *incorrect (and misleading) statement*, for the unicode and str case.


PROPOSED FIX:

Current full paragraph:

    "Sequence types also support comparisons. In particular, tuples and lists are compared lexicographically by comparing corresponding elements. This means that to compare equal, every element must compare equal and the two sequences must be of the same type and have the same length. (For full details see Comparisons in the language reference.)"

Proposed replacement text:

    "Sequence types also support comparisons. In particular, tuples and lists are compared lexicographically by comparing corresponding elements. This means that to compare equal, every element must compare equal and the two sequences 
must be of the same type and have the same length. (Unicode and str are treated as the same type here; for full details see Comparisons in the language reference.)"


DETAILS, JUSTIFICATION, CORRECTNESS, ETC:

The current incorrect text is really misleading.

The behaviour that a str and a unicode object -- despite being objects of different types -- may compare equal, is explicitly stated in the 2.7.13 The Python Language Reference manual, section 5.9 "Comparisons" (https://docs.python.org/2/reference/expressions.html#comparisons):

    "* Strings are compared lexicographically using the numeric equivalents (the result of the built-in function ord()) of their characters. Unicode and 8-bit strings are fully interoperable in this behavior. [4]"

(Aside: Incidentally an earlier paragraph in the Language Ref fails to cover the unicode and str case; see separately filed bug Issue 29321.)
History
Date User Action Args
2017-01-19 14:40:31RK-5wWm9hsetrecipients: + RK-5wWm9h, docs@python
2017-01-19 14:40:31RK-5wWm9hsetmessageid: <1484836831.64.0.870722472975.issue29323@psf.upfronthosting.co.za>
2017-01-19 14:40:31RK-5wWm9hlinkissue29323 messages
2017-01-19 14:40:31RK-5wWm9hcreate