Mark Dickinson wrote:
> On the other hand, there's at least some sense in which bytes already
> acts as a sort of poor-man's string: witness bytes.lower and friends.
> Maybe practicality beats purity here?
From PEP 358 (describing what is now bytearray):
"""Note the conspicuous absence of .isupper(), .upper(), and friends.
(But see "Open Issues" below.) There is no .__hash__() because
the object is mutable."""
And the open issue:
"""A case could even be made for supporting .islower(), .isupper(),
.isspace(), .isalpha(), .isalnum(), .isdigit() and the
corresponding conversions (.lower() etc.), using the ASCII
definitions for letters, digits and whitespace. If this is
accepted, the cases for .ljust(), .rjust(), .center() and
.split() become much stronger, and they should have default
arguments as well, using an ASCII space or all ASCII whitespace
(for .split())."""
PEP 3157 resolved that open issue as follows:
"""This is exactly the set of methods present on the str type in Python
2.x, with the exclusion of .encode(). The signatures and semantics are
the same too. However, whenever character classes like letter,
whitespace, lower case are used, the ASCII definitions of these classes
are used."""
That seems fairly explicit to me in saying that a bytes or bytearray
object should be considered to be ASCII encoded when treated as a string.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
