Nick Coghlan added the comment:
<Closing with rationale, as Martin requested>
The struct module documentation takes precedence over PEP 3118 when it comes to
pre-existing format codes, as changing struct is not feasible due to backwards
compatibility concerns, and we don't want two conflicting notations for binary
format descriptions. PEP 3118 was intended only to define *additional* format
characters, which may or may not yet be understood by the struct module.
As 'c' is defined by the struct module as returning a bytes object of length
one, this is the same interpretation used by memoryview.
Thus the current behaviour of both memoryview and struct are considered
correct, while it is PEP 3118 that is incorrect in this case: the 'c' entry
should not have been in the table, as 'c' was already defined at least as long
ago as 1.5.2 (returning an 8-bit string, which then became a bytes object in
3.x).
The PEP was also written in a 2.x context (note the mention of "2.5" above the
table of new format codes), where the idea of providing a separate code that
implicitly performed x.decode("latin-1") to produce a unicode object instead of
an 8-bit string object wouldn't necessarily come up.
----------
dependencies: -implement PEP 3118 struct changes
resolution: -> invalid
stage: -> committed/rejected
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15622>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
