Not good enough means I had to prefix every single string with "u" to make sure it's unicode. It was especially painful with code like this :
logger.debug("Name of the person I'm debugging {}".format(name))
forgetting the "u" simply lead to various crashes if the name had characters that could not be encoded in whatever the debug was piped to. Always thinking about the "u" was nothing I had the time to.Just an example.
It's actually good practice to be explicit about the type, and write b"" and u"" always (easier on the person reading the code). The u'' literal prefix was re-introduced in 3.3 for this reason.
It doesn't because strings and text are a lot more common than bytes. Yours is a really weird line of argument - that the 3.x changes and what's in 2.7 are fundamentally equivalent and thus the changes are outright unnecessary and that the people who made them just got it wrong and did it for no apparent reason or benefit. I get that someone might not like what they did or how they did it but your take should give you pause just by its general improbability.
As I said, u'' literals were re-introduced by the Python developers themselves, in Python 3.3.
1. BOTH Python 2 and Python 3 come with built-in support for BOTH bytestring and unicode (contrary to OP's claims I responded to)
2. That mixing bytestrings and unicode will fail with an explicit error since 3.0+ (a good idea IMO)
3. Unicode has a more efficient internal storage since Python 3.3+ (a neat technical detail)
4. It's good practice to be explicit about the type of literals, and write b"" and u"" always
5. That Python 2.7 doesn't support unicode is simply FUD.
Can you articulate which point you're actually contesting? I'll be happy to clarify, but I'm honestly unsure what you're responding to.
The person you replied to didn't claim Python 2 doesn't support unicode. 'Bytestrings' has what is wrong with Python 2 neatly summarized in a single word (and this, incidentally, is a term the Python documentation avoids these days because it's bad). 3 is true but not really related to the topic at hand. 4 is, I think, outright wrong. As to 5, I'm not sure why you would even want to defend that. It's not what the poster said and even if they had said it, they'd be just wrong - it's not 'FUD'. That is just you being grumpy and rude.
that was my point, by moving to python 3, I removed all my "u", the thing other developers not wanted (see PEP-414 again); I loved the "purity".
but removing u was tedious (at best).
In my use case, strings are "string" and binary are "bytes". Which I think is much safer.
Lots of python 2 code out there fails because the default option was simple but bad. I know, because my name broke the CI pipelines in a few different projects.
The main difference is that unicode has a more efficient internal storage since Python 3.3+ (a neat technical detail), and that mixing bytestrings and unicode will fail with an explicit error since 3.0+ (a good idea IMO).
But that Python 2.7 didn't support unicode is simply FUD.