Hacker News Reader

Comment by Kliment | Hacker News Reader

I don't mind the print statement/function thing but I am bothered by the pain when dealing with byte strings. I use Python to talk to hardware that doesn't speak unicode, the contortions I have to go through to get byte strings to behave correctly on py3 are frustrating. I have no problem with the default string being unicode, but why can't byte strings be implemented like the unicode strings were done on py2.x?

View on HN

What's the specific issue? I find it solves loads of issues before where you could mix bytes and unicode by accident. Not only are they more explicit, I find the fact that `b'\0'[0] == 0` - way better when working with actual bytes.

The inability to use string manipulation functions on bytestrings without converting them to unicode and back for each operation.

What do you mean by "string manipulation"? bytes are not text strings. If you actually mean text operations, then converting them is something you should also do in py2.

Edit: now that I thought about it - since you're able to decode the bytes you're using, it means you are operating on text - why not convert it then?

See http://bugs.python.org/issue3982 that's linked elsewhere in these comments for the kind of things that don't work on bytestrings

As many comments in that thread point out, byte arrays are not strings, and casually conflating or implicitly converting the two is terrible mental hygiene.

Explicit is better than implicit.

I read it all, and to be honest I think I agree the most with http://bugs.python.org/issue3982#msg180441 (.format may be making some things simpler, but it goes against the idea of well separated bytes -vs- text)

But really, I just don't like how http/ftp/similar protocols were designed in the first place. They're mixing binary and text in the same stream. That's ugly and when you have strict rules about text encoding in your language, the implementation also turns out ugly - what a surprise :)

Reply on news.ycombinator.com