[Python-Dev] What to do for bytes in 2.6?

Raymond Hettinger python at rcn.com
Fri Jan 18 04:11:10 CET 2008


> *If* we provide some kind of "backport" of
> bytes (even if it's just an alias for or trivial
> subclass of str), it should be part of a strategy 
> that makes it easier to write code that
> runs under 2.6 and can be automatically translated 
> to run under 3.0 with the same semantics. 

If it's just an alias or trivial subclass, then we 
haven't added anything that can't be done trivially
by the 2-to-3 tool.

I'm thinking that this is a deeper change. 
It doesn't serve either 2.6 or 3.0 to conflate
str/unicode model with the bytes/text model.
Mixing the two in one place just creates a mess
in that one place.

I'm sure we're thinking that this is just an optional
transition tool, but the reality is that once people
write 2.6 tools that use the new model,
then 2.6 users are forced to deal with that model.
It stops being optional or something in the future,
it becomes a mental jump that needs to be made now
(while still retaining the previous model in mind
for all the rest of the code).

I don't think you need a case study to forsee that
it will be unpleasant to work with a code base
that commingles the two world views.

One other thought.  I'm guessing that apps that would
care about the distinction are already using unicode
and are already treating text as distinct from arrays
of bytes.  Instead, it's backwards thinking 20th-century
neanderthal ascii-bound folks like myself who are going
to have transition issues.  It would be nice for us
knuckle-draggers to not have to face the issue until 3.0.


Raymond


More information about the Python-Dev mailing list