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

[Guido van Rossum]

On Jan 17, 2008 6:00 PM, Raymond Hettinger <python at rcn.com> wrote:
> [GvR]
> > I believe the issue of whether and how to backport bytes
> > (and bytearray?) from 3.0 to 2.6 has come up before, but
> > I don't think we've come to any kind of conclusion.
>
> My recommendation is to leave it out of 2.6.
>
> Not every 3.0 concept has to be backported.  This particular one doesn't have a straight-forward integration.  It duplicates some existing functionality and in general doesn't make life better for the 2.6 coder.  The only benefit I can see is that it lets you write code that is a step closer to 3.0; however, it has not been our goal to write one piece of code that runs under both major releases.

Indeed. However, it *is* one of our stated goals that 2.6 will provide
a variety of features that will make source-to-source conversion more
likely to succeed. I'm currently expecting that the str/unicode/bytes
issue is by far the biggest issue where automated conversion is
unlikely to be effective. *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.

I realize that this is a lofty goal and that I haven't thought through
how to get there -- maybe it won't be possible anyway, but I think
it's worth a try. (I'll think about it more later.)

> I think both 2.x and 3.0 are better served if 2.x cleanly stays with the str/uncode model and 3.0 sticks with the bytes/text model.  Commingling the two muddies the waters and conflates the distinctions.  I think it best to make that jump all at once.
>
> Multiple-ways-to-do-it should not be the motto for 2.6.  Instead, let's provide the best transition tools possible and keep both 2.6 and 3.0 as clean as possible (no duplicative or half-intergrated functionality).

Well, 2.6 *is* one of the transition tools. We should probably do a
case study on the back of an envelope on how to take existing code
that deals with encoded text, decoded text, and binary data, and how
to restructure it for automatic translation to correct 3.0 code.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)