[Python-Dev] Changing string constants to byte arrays in Py3k
ncoghlan at gmail.com
Mon May 7 18:00:02 CEST 2007
skip at pobox.com wrote:
> >> So is having mutable bytes just a matter of calling them "byte
> >> displays" instead of "byte literals" or does that also require
> >> changing something in the back end?
> Martin> It's certainly also an issue of language semantics (i.e. changes
> Martin> to interpreter code). There are a number of options:
> Martin> 1. don't support creation of byte values through syntax. Instead,
> Martin> create bytes through a constructor function.
> I don't read the py3k mailing list. I presume the distinction between
> "display" and "literal" is old hat to those folks. I've never seen the
> term. Can someone explain it?
A literal refers to an immutable constant (i.e. 'assert 1 is 1' is
allowed to be true)
A display always creates a new mutable object (i.e. 'assert  is ' is
*required* to be false)
The question is whether we have byte literals or displays in Py3k, and
if we make them literals, whether it is still permissible for them to be
mutable. Mutable objects pose all sorts of caching and aliasing problems
that just don't come up with immutable objects like strings or numbers.
For the work I do with low level hardware control, I suspect not having
an immutable bytes variant to throw in a dictionary would be something
of an inconvenience (that said, work only switched to Python 2.4
relatively recently, so I doubt Py3k will pose me any significant
practical concerns on that front for quite some time :).
I would personally like an interoperable bytes/frozenbytes pair (along
the lines of set/frozenset) with a literal syntax to produce instances
of the latter. However, I don't have a great deal of development time to
devote to helping to make that happen.
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev