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

[Guido van Rossum]

On Jan 17, 2008 9:30 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> "Guido van Rossum" <guido at python.org> wrote in message
> news:ca471dc20801172043l3356e04et9b8e807177230c6f at mail.gmail.com...
> | Is it reading text or binary data from stream blah? We can't tell.  If
> | it's meant to be reading text, 2to3 should leave it alone. But if it's
> | meant to be reading binary data, 2to3 should change the string
> | literals to bytes literals (b"" in this case). (If it's used for both,
> | there's no hope.) As it stands, 2to3 hasn't a chance to decide what to
> | do, so it will leave it alone -- but the "translated" code will be
> | wrong if it was meant to be reading bytes.
>
> It seems that the main purpose of adding bytes (as more or less a
> synonym for str when used as bytes) is to aid 2to3 translation.
> So I think I would favor it being part of a future import.
>
> | Note that I believe that the -3 flag should not change semantics -- it
> | should only add warnings. Semantic changes must either be backwards
> | compatible or be requested explicitly with a __forward__ import (which
> | 2to3 can remove).
>
> Were you planning to make bytes a __future__ (or __forward__?) import?
> I think making it so should satisfy Raymond's concerns.  Even if whatever
> you eventually do is technically backwards compatible, he is suggesting
> that conceptually, it is not.  I see some validity to that view.

While it *could* be made conditional on a __future__ import, the cost
of those (both in terms of implementing them and using them) is rather
high so I'd prefer it to be always available. Given Raymond's later
response, I'm not sure it's worth the effort.

On Jan 17, 2008 9:44 PM, Raymond Hettinger <python at rcn.com> wrote:
> > having b"" and bytes as aliases for "" and
> > str in 2.6 would mean that we could write 2.6 code that correctly
> > expresses the use of binary data -- and we could use u"" and unicode
> > for code using text, and 2to3 would translate those to "" and str and
> > the code would be correct 3.0 text processing code.
>
> I see. There's a healthy benefit for 2to3 translation that cannot be
> accomplished in any other way.   This may potentially more than offset the
> negative impact to the 2.x world where it complexifies the language
> without any immediate payoff.
>
> FWIW, I'm sold on the rationale.  Hopefully, this can be confined
> to just annotation and aliasing but not porting back any C API
> changes or code that depends on the bytes/text distinction.

I'm fine with only making this a superficial veneer: b"" and bytes as
aliases for "" and str. However Thomas Heller's response requires more
thought.

> I worry
> that as soon as the annotation is made available, it will ripple
> throughout the code and pervade the language so that it cannot
> be ignored by Py2.6 coders.  It's a bit of a Pandora's Box.

Well, that's one opinion against another. And I presume by now you
have read Glyph's enthusiastic response. Getting Twisted on 3.0 is a
big enabler for getting other 3rd party packages an apps on board!

> > Just being able to (voluntarily! on a
> > per-module basis!) use a different type name and literal style for
> > data could help forward-looking programmers get started on making the
> > distinction clear, thus getting ready for 3.0 without making the jump
> > just yet (or maintaining a 2.6 and a 3.0 version of the same package
> > easily, using 2to3 to automatically generate the 3.0 version from the
> > 2.6 code base).
>
> Are we going to be "forward-looking" and change all of the
> standard library modules?  Is this going to pop-up everywhere
> and become something you have to know about whether or
> not you're a volunteering forward-looking programmer?  I hope not.

I have no desire to fix up the standard library cosmetically, and I
don't see the need -- the standard library has already been forward
ported to 3.0, so the rationale just doesn't apply.

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