Numpy: Plan for dropping Python 2.7 support

Re:Numpy: Plan for dropping Python 2.7 support by ablankst on Wednesday November 15, 2017 @06:10PM (#15708908)

The following example is pretty much the chief reason why I will not be porting much software to Python 3:

  $ python3 
  Python 3.6.3 (default, Oct  3 2017, 21:45:48)
  [GCC 7.2.0] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> 4/3
  1.3333333333333333

Python3 is basically a different language than Python 2. If I wanted to port software to a different language, I would use any number of available languages that make other kinds of improvements over Python as well. The only remaining use case for Python for me will be as a quick scripting language, and data analysis and graphing tool.

[ Parent | on HN ]

Re:Numpy: Plan for dropping Python 2.7 support by cpburns2009 on Wednesday November 15, 2017 @06:14PM (#15708924)

It is a change, but you can use the // operator for floor division:

  $ python3
  Python 3.6.3 (default, Oct  3 2017, 21:16:13) 
  [GCC 7.2.0] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> 4//3
  1

[ Parent | on HN ]

Re:Numpy: Plan for dropping Python 2.7 support by cpncrunch on Wednesday November 15, 2017 @08:11PM (#15709533)

I think you've just proved OP's point...you have to change the code.

[ Parent | on HN ]

Re:Numpy: Plan for dropping Python 2.7 support by nyrikki on Thursday November 16, 2017 @12:17AM (#15710420)

Alternatively, we need to quite ignoring when projects warn about changing behavior and provide tools to mitigate the change.

  __future__.division was optional in 2.0.0, which was released in 2001

  __future__.print_function was optional in 2.6.0a2, which was released in 2008

There is nothing a language team can do if users ignore changes for close to two decades.

Simply adding the following line to new project over the past 8 years would have made the move to python 3 less difficult.

  from __future__ import (division, print_function)

While I am annoyed that they didn't just alias xrange to range etc...us users do need to take ownership for our bad decisions.

[ Parent | on HN ]

Re:Numpy: Plan for dropping Python 2.7 support by rspeer on Wednesday November 15, 2017 @08:16PM (#15709557)

You have to change the code a lot more to port it to an entirely different language.

[ Parent | on HN ]

Re:Numpy: Plan for dropping Python 2.7 support by cpncrunch on Wednesday November 15, 2017 @11:56PM (#15710346)

Of course, but the point is that you shouldn't really need to spend weeks updating your code just to upgrade to a newer version of the compiler.

[ Parent | on HN ]

Re:Numpy: Plan for dropping Python 2.7 support by mrep on Wednesday November 15, 2017 @08:26PM (#15709601)

I know right, you usually have to change a lot of code just to change versions of a framework.

One of my teammates just upgraded our django framework from 1.4 to 1.8 and it took him almost an entire week to do.

[ Parent | on HN ]

Re:Numpy: Plan for dropping Python 2.7 support by craigds on Wednesday November 15, 2017 @10:43PM (#15710121)

A week! It took me six months to port our main app from django 1.5 to 1.8. Though our app is huge, and most of that was migrating from DRF 2.3 to 3.3.

[ Parent | on HN ]

Re:Numpy: Plan for dropping Python 2.7 support by hsjoberg on Thursday November 16, 2017 @02:51AM (#15710867)

You can use to 2to3 command. So far I had no problems while using it.

https://docs.python.org/3/library/2to3.html

[ Parent | on HN ]