Having "", u"", and r"" be immutable, while b"" was mutable would seem rather inconsistent.
Yes. However, this inconsistency might be desirable. It would, of course, mean that the literal cannot be a singleton. Instead, it has
to be a display (?), similar to list or dict displays: each execution
of the byte string literal creates a new object.
An alternative would be to have "bytestr" be the immutable type corresponding to the current str (with b"" literals producing bytestr's), while reserving the "bytes" name for a mutable byte sequence.
Indeed. This maze of options has caused the process to get stuck. People also argue that with such an approach, we could as well tell users to use array.array for the mutable type. But then, people complain that it doesn't have all the library support that strings have.
The main point being, the replacement for 'str' needs to be immutable or the upgrade process is going to be a serious PITA.
Somebody really needs to take this in his hands, completing the PEP, writing a patch, checking applications to find out what breaks.
Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
