[Python-Dev] What to do for bytes in 2.6? (original) (raw)

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