4 ms·

Sure, but the community could continue to reject Python3 instead as it had been doing for years. It seems like it is catching on a bit now, but I hadn't really

by Figs 9y ago

Sure, but the community could continue to reject Python3 instead as it had been doing for years. It seems like it is catching on a bit now, but I hadn't really seen any good reason for it other than the upcoming EOL.

crusso 9y ago
Look at the statement from the numpy group: 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.
- sprash 9y ago
  That is like the biggest fake argument ever. There is plenty of resources and Python 2 support is neither a burden nor this burden in any way increasing. The are plenty of people ready to step up to continue Py2 support (Even I would be glad to help). This is a pure political decision based on ideology.
  - gtaylor 9y ago
    You can fork numpy and maintain Python 2 support.
  - code_sloth 9y ago
    As the codebase grows, you need to maintain 2 growing codebases, how is that not increasing the burden? 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.
    - Chris2048 9y ago
      Can you be more precise with what you mean by "the community". It wasn't the community that said it was dropping support. I've plan to migrate away from py2 by 2020 too, just not to py3.
  - achompas 9y ago
    > There is plenty of resources and Python 2 support is neither a burden nor this burden in any way increasing. 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! https://www.numfocus.org https://www.numfocus.org (Not a NumFOCUS person although I occasionally volunteer with them and definitely donate on a recurring basis.)
  - gautamdivgi 9y ago
    The resources aren't "code" but people and time. You have a limited set of folks who consistently contribute and become reviewers/committers. This is all based on volunteer time - no one is paying these folks to do it. So, asking these folks to divide their limited volunteered time between multiple versions of python is unfair. I think this is the right decision to take. If you feel you have "plenty of resources" you can fork the python2 version of numpy and maintain it.
pvg 9y ago
Python would have lost popularity and would have eventually died without Python 3. Being a scripting language with a relatively low barrier to entry has always been among its selling points. Text processing is a very common use-case for such languages. In a Unicode world, you can't really have a language that is supposed to be easy to use yet requires contortions and has major pitfalls in simply handling text.
- wiz21c 9y ago
  Yep, I'm always surprised by the number of people of people here who dismiss the usefulness of unicode. Not "dismissing" the hard way, but simply saying it's not a problem. I understand that we may have a lot of western/english people here but, unicode for me is a life saver. For example, I work on stuff for french speaking people, and I need the euro sign. In that very simple case, unicode already solve many issues : I don't have to convert between ISO-8859-1, ISO-8859-15, CP-1252 anymore, whatever my database uses, I just enforce unicode. Moreover, I can have french comment in source code (that's very important because sometimes we're talking about laws and some of our technical terms in those laws are not translated in english). (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...
  - Radim 9y ago
    You do realize unicode has been "built into Python" pretty much since the beginning (Python 2.0, 17 years ago), right? 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.
    - viraptor 9y ago
      I don't think anyone claimed it didn't support Unicode. Only that it allowed mixing bytes / strings and the default type most people used from the beginning was str. That's a trap that they'll regret the moment they actually need to handle something outside of Latin-1. 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.

by Figs 9y ago

crusso 9y ago

Look at the statement from the numpy group: 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.

sprash 9y ago
That is like the biggest fake argument ever. There is plenty of resources and Python 2 support is neither a burden nor this burden in any way increasing. The are plenty of people ready to step up to continue Py2 support (Even I would be glad to help). This is a pure political decision based on ideology.
- gtaylor 9y ago
  You can fork numpy and maintain Python 2 support.
- code_sloth 9y ago
  As the codebase grows, you need to maintain 2 growing codebases, how is that not increasing the burden? 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.
  - Chris2048 9y ago
    Can you be more precise with what you mean by "the community". It wasn't the community that said it was dropping support. I've plan to migrate away from py2 by 2020 too, just not to py3.
- achompas 9y ago
  > There is plenty of resources and Python 2 support is neither a burden nor this burden in any way increasing. 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! https://www.numfocus.org https://www.numfocus.org (Not a NumFOCUS person although I occasionally volunteer with them and definitely donate on a recurring basis.)
- gautamdivgi 9y ago
  The resources aren't "code" but people and time. You have a limited set of folks who consistently contribute and become reviewers/committers. This is all based on volunteer time - no one is paying these folks to do it. So, asking these folks to divide their limited volunteered time between multiple versions of python is unfair. I think this is the right decision to take. If you feel you have "plenty of resources" you can fork the python2 version of numpy and maintain it.

pvg 9y ago

Python would have lost popularity and would have eventually died without Python 3. Being a scripting language with a relatively low barrier to entry has always been among its selling points. Text processing is a very common use-case for such languages. In a Unicode world, you can't really have a language that is supposed to be easy to use yet requires contortions and has major pitfalls in simply handling text.

wiz21c 9y ago
Yep, I'm always surprised by the number of people of people here who dismiss the usefulness of unicode. Not "dismissing" the hard way, but simply saying it's not a problem. I understand that we may have a lot of western/english people here but, unicode for me is a life saver. For example, I work on stuff for french speaking people, and I need the euro sign. In that very simple case, unicode already solve many issues : I don't have to convert between ISO-8859-1, ISO-8859-15, CP-1252 anymore, whatever my database uses, I just enforce unicode. Moreover, I can have french comment in source code (that's very important because sometimes we're talking about laws and some of our technical terms in those laws are not translated in english). (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...
- Radim 9y ago
  You do realize unicode has been "built into Python" pretty much since the beginning (Python 2.0, 17 years ago), right? 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.
  - viraptor 9y ago
    I don't think anyone claimed it didn't support Unicode. Only that it allowed mixing bytes / strings and the default type most people used from the beginning was str. That's a trap that they'll regret the moment they actually need to handle something outside of Latin-1. 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.