Indeed introducing bytes in a good way in 2.6 would take some work, but I disagree that the main points I’m bringing up here were not simple. Renaming unicode to str requires actually more work than just keeping unicode as-is. If the goal of the bytes type in 2.6 was simply to serve as a marker and there’s no one willing to pay the bill for porting bytes properly, then make it more obvious that this is a marker like I suggested above rather than introducing a built-in with the same name as the 3.0 type.

Michael,

“all strings are unicode in Python 3.0 so the string type is called str. bytes literals are allowed in Python 2.6 but are just an alias for bytestrings and useful for conversion of code by 2to3″

No, they’re not all unicode just like they were not all unicode in 2.6. “abc” wasn’t unicode in 2.6. b”abc” is not unicode in 3.0. The renaming from unicode to str is unjustified, the fact that we have a marker with the name of a new type in 3.0 is unjustified. If you want me to admit being wrong stop ignoring the facts and look for some reasonable argumentation for this mess.

“In Python 3 your facetious “Remove str. Add bytes. Go home.” is exactly what happened. Removing str from Python 2 is obviously not possible (do you honestly not see that?).”

No, that’s not what happened either. Read the post again if you seriously don’t know what happened.

“all strings are unicode in Python 3.0 so the string type is called str. bytes literals are allowed in Python 2.6 but are just an alias for bytestrings and useful for conversion of code by 2to3″

*Anything* can be made confusing if you deliberately belabour a point rather than admit you were wrond…

In Python 3 your facetious “Remove str. Add bytes. Go home.” is exactly what happened. Removing str from Python 2 is obviously not possible (do you honestly not see that?).

bytes is not a marker. It’s the name of a new type in 3.0. If you want a marker, do something like “from __future__ import strtobytes”, or “from 2to3 import bytesmarker” or whatever else.

I’m puzzled to see so many smart people saying that it’s totally fine that we’ll have to explain to people “Oh, yeah, unicode is actually str.. no, I mean, unicode is still unicode in 3.0, but it’s named str, and str in 2.6 is actually what used to be bytes, but bytes was really str, because there was that 2to3 migration thing.”

Sorry, but that mess really wasn’t necessary. Remove str. Add bytes. Go home.

As you have pointed out yourself there are important semantic differences between the bytes type in Python 3.0 and the bytestring in Python 2. Indexing, iterating and the in operator being amongst them.

If the bytes type were to be fully ported then every builtin function and the builtin types would need to be modified to support them. What is worse the standard library would also need to be modified and case-by-case decision made as to if / how to support bytes.

If it were not done fully and only the basic type backported then you wouldn’t be able to use the bytes type in Python 2.X code as you do in Python 3. This means that 2to3 could no longer reliably convert coded using bytes as you have to special case it in your Python 2 code.

As the *purpose* of the alias is to be a hint for 2to3 it would negate the purpose entirely and be a much worse change…

There are actually some important differences on the semantics of the “real” bytes when compared to str. Here is a hint:

>>> list(b"asd")
[97, 115, 100]


“This means that if you write code to support bytes in 2.6, you are actually not writing code which is compatible with Python 3.0.”

Huh? Explain this to me, because I’m not seeing it.

If you write code that uses bytes in 2.6, you’re clearly not intending to treat it as equivalent to str (i.e., character data), or you’d just use str. Instead, you’re intending to treat it as an 8-sit string, which is the same way it will behave in 3.0.

Now, if your code looks like:

b = bytes()
if isinstance(b, str): print “Let’s mess up our forward compatibility! It’ll be fun!”

then yes, you’ll have problems. But I cannot come up with a sane use case for this kind of check.

So the thing that you’re decrying as a major problem, I cannot see why it would be a problem. Yes, the type that bytes is an alias for will change, but it retains its semantics: 8-bit strings not intended to be used as character data. So why, exactly, is this change a problem?

P.S. Since tone of voice is hard to communicate, I should state that I’m not being ironic or sarcastic. I’m truly puzzled by why you think this is a problem.

While this is true, they’d already made this decision for other areas of the standard library. So doing it again for bytes/unicode doesn’t make things (much) worse.