The NumPy project has supported both Python 2 and Python 3 in parallel since 2010, and has found that supporting Python 2 is an increasing burden on our limited resources;
That's a real team saying that they just can't support 2 major versions of the language any longer.
This is a pure political decision based on ideology.
Official support will be dropped by 2020, by then you will be relying on the community (who ?) to provide bug and security fixes. I'm not aware of anybody stepping up and declaring they will take over maintenance.
At this point, insisting on python 2 is the ideological "side". There's no practical nor realisitic reasoning behind it. Major parts of the community are moving to python 3 and dropping python 2.
You can stay with python 2 and maintain the language / libraries, but don't begrudge those that move on.
I've plan to migrate away from py2 by 2020 too, just not to py3.
If you feel you have "plenty of resources" you can fork the python2 version of numpy and maintain it.
Aside from what others have said, NumFOCUS is woefully underfunded. If you're interested in seeing continued development of NumPy and other amazing scientific Python packages, you should think about contributing!
(Not a NumFOCUS person although I occasionally volunteer with them and definitely donate on a recurring basis.)
(I understand that in this particular case, I could have enforced ISO-8859-15 as well, but the crux of the matter is that with unicode built in python3, I don't have to think about it anymore)
And now my customer is copy/pasting additional information from documents coming from other countries as well...
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.
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))
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.
For these folks encountering anything other than ASCII is pretty uncommon.
Personally, I've worked on a Python 2.x project deployed in heavy industry across the globe including Japan and the number of times we had Python 2 unicode nightmare issues was too many to mention.