5 ms·

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, 2

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.

cpburns2009 9y ago
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
- cpncrunch 9y ago
  I think you've just proved OP's point...you have to change the code.
  - rspeer 9y ago
    You have to change the code a lot more to port it to an entirely different language.
    - mrep 9y ago
      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.
      - craigds 9y ago
        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.
    - cpncrunch 9y ago
      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.
  - nyrikki 9y ago
    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.
  - hsjoberg 9y ago
    You can use to 2to3 command. So far I had no problems while using it. https://docs.python.org/3/library/2to3.html https://docs.python.org/3/library/2to3.html

cpburns2009 9y ago

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

cpncrunch 9y ago
I think you've just proved OP's point...you have to change the code.
- rspeer 9y ago
  You have to change the code a lot more to port it to an entirely different language.
  - mrep 9y ago
    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.
    - craigds 9y ago
      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.
  - cpncrunch 9y ago
    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.
- nyrikki 9y ago
  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.
- hsjoberg 9y ago
  You can use to 2to3 command. So far I had no problems while using it. https://docs.python.org/3/library/2to3.html https://docs.python.org/3/library/2to3.html