[Python-Dev] Changing string constants to byte arrays in Py3k

Nick Coghlan 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 mailing list