Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Tuesday September 10 2019, @04:26AM   Printer-friendly

Arthur T Knackerbracket has found the following story:

We are volunteers who make and take care of the Python programming language. We have decided that January 1, 2020, will be the day that we sunset Python 2. That means that we will not improve it anymore after that day, even if someone finds a security problem in it. You should upgrade to Python 3 as soon as you can.

We need to sunset Python 2 so we can help Python users.

We released Python 2.0 in 2000. We realized a few years later that we needed to make big changes to improve Python. So in 2006, we started Python 3.0. Many people did not upgrade, and we did not want to hurt them. So, for many years, we have kept improving and publishing both Python 2 and Python 3.

But this makes it hard to improve Python. There are improvements Python 2 can't handle. And we have less time to work on making Python 3 better and faster.

And if many people keep using Python 2, then that makes it hard for the volunteers who use Python to make software. They can't use the good new things in Python 3 to improve the tools they make.

We did not want to hurt the people using Python 2. So, in 2008, we announced that we would sunset Python 2 in 2015, and asked people to upgrade before then. Some did, but many did not. So, in 2014, we extended that sunset till 2020.

If people find catastrophic security problems in Python 2, or in software written in Python 2, then volunteers will not help you. If you need help with Python 2 software, then volunteers will not help you. You will lose chances to use good tools because they will only run on Python 3, and you will slow down people who depend on you and work with you.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1, Informative) by Anonymous Coward on Wednesday September 11 2019, @05:57AM (2 children)

    by Anonymous Coward on Wednesday September 11 2019, @05:57AM (#892559)

    python 2: 5 / 2 == 2 # int / int returns int
    python 3: 5 / 2 == 2.5 # int / int returns float

    python 2: round(0.5) == 1.0 # round(float) returns float Half-away-from-zero
    python 3: round(0.5) == 0 # round(float) returns int Half-towards-even

    python 2: 010 + 1 == 9
    python 3: 010 + 1 raises SyntaxError

    And those are just the ones I could think of off-hand.

    Starting Score:    0  points
    Moderation   +1  
       Informative=1, Total=1
    Extra 'Informative' Modifier   0  

    Total Score:   1  
  • (Score: 2) by PiMuNu on Thursday September 12 2019, @08:35AM (1 child)

    by PiMuNu (3823) on Thursday September 12 2019, @08:35AM (#893090)

    > python 2: 5 / 2 == 2 # int / int returns int
    > python 3: 5 / 2 == 2.5 # int / int returns float

    Okay, I started on C programming so I am used to int/int returns int.

    > python 2: round(0.5) == 1.0 # round(float) returns float Half-away-from-zero
    > python 3: round(0.5) == 0 # round(float) returns int Half-towards-even

    Did you type that wrong? Or does 0.5 round down in python 3? This is surely wrong??

    > python 2: 010 + 1 == 9
    > python 3: 010 + 1 raises SyntaxError

    That is an improvement.

    • (Score: 0) by Anonymous Coward on Friday September 13 2019, @05:33AM

      by Anonymous Coward on Friday September 13 2019, @05:33AM (#893539)

      Nope the behavior in Python 3 is correct, and the bug tracker sees a report about it every few months and the mailing list every few weeks. Technically, the previous way was a bug back from when GvR and other core team members didn't know better.

      Regardless, they changed it in order to conform with IEEE 754, which defaults to half-to-even rounding (also known as banker's rounding) for floating point. The reason for the rule is that it reduces the propagation of rounding errors in one direction, which causes the math to be more accurate overall. It was done with a couple more changes they made to the way Python handles floating point numbers and the various operations on them (which are far more technical and less easily noticed than that one). This had the benefit of allowing them to use hardware implementations of IEEE 754 and related standards directly without having to code around where they contradict the software implementation of floating point in the language. This increased performance, accuracy, code maintainability, interoperation with other numerical standards (like the General Decimal Arithmetic Specification), aligned behavior with most other languages and implementations, and a few other benefits as well.

      For all of them, I agree they are all improvements, but I was responding to the implication of your statement that they didn't change anything regard how they handle math. Like I said, there are more beyond those, but they are probably the ones most people will run into.