9 ms·

Serious question: Why would anyone still be doing anything with Python 2.7 except porting the last remnants of their code base to 3.X?

gizmo385 10y ago
Because sometimes the amount of work required to port a 2.7 project to 3.x isn't worth it.
- dbcurtis 10y ago
  So, then it is a small project that is near end-of-life, and easily replaced?
  - richardwhiuk 10y ago
    No, a large project, which isn't easily replaced, whether or not it's near the end of it's life, or anything using a Py2 only dependency
- compuguy 10y ago
  Ansible currently only supports Python 2.7....
run4yourlives2 10y ago
Serious Answer: Because some of us have some rather large perfectly working systems written in 2.7 and using lots of different libraries that moving to 3 is a major project requiring a good amount of time and effort. Not all of us have hobby-sized projects on the go.
- kzrdude 10y ago
  Even hobby sized projects can be a major chore. Especially if it's wrapped up in a Gtk transition too.
- dbcurtis 10y ago
  OK, but this has been a very long transition. There has been lots of time to evolve to 3.x. Has the primary barrier been the slow transition of library dependancies? I'd really like to understand this from a technology transition management standpoint. If you'll allow a strained analogy, the 2.7 to 3.x transition appears in retrospect like an exercise in herding cats, because the transition was done using cat-herding style incentives. What should have been done differently to make the transition into greyhounds chasing a rabbit? What should the rabbit have been? Any technology that lives long enough eventually has to transition its customer base. I'm trying to learn to identify rabbits.
  - chc 10y ago
    Asking this question without disqualifying the answer "No breaking changes whatsoever" usually just generates a bunch of different ways of phrasing that.
    - dbcurtis 10y ago
      No, I don't buy that. IBM successfully transitioned a huge customer base from 709/7090 36-bit words to System 360 32 bit words. The transition from 32 to 64 bit addresses was rocky for a lot of architectures. DEC Alpha, Intel Itanium. But are you still running a 32 bit OS? K&R C no longer compiles. Not that the C to C++14 transition is what I would call an example of greatness, but it is somewhere along the success spectrum. Seriously, you will someday need to transition your customer base. How do you plan to do it?
      - chc 10y ago
        Yes, I agree with you. That's why I said you should disqualify that answer. It's by far the most common answer, but it's also obviously not the right answer.
      - xrange 10y ago
        >K&R C no longer compiles. foo@virt-ubuntu:~/c$ gcc --version gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. foo@virt-ubuntu:~/c$ cat 'k&r.c' #include<stdio.h> int main(argc, argv) int argc; char *argv[]; { puts("hello, world!"); return 0; } foo@virt-ubuntu:~/c$ gcc 'k&r.c' foo@virt-ubuntu:~/c$ ./a.out hello, world!
Marat_Dukhan 10y ago
Because Python 2.7 is, IMO, a better language than Python 3+, e.g.: - I like lambda a, b: a + b syntax better than lambda a_b: a_b[0] + a_b[1] - I prefer map/reduce/filter to return lists rather than iterable - I prefer dict.keys/values/items to return sets/lists rather than iterables, unless I call dict.iter[keys/values/items]
- rhaps0dy 10y ago
  Iterables are so much better on memory though. I wonder why isn't "lambda (a, b): a+b" allowed?
  - omaranto 10y ago
    It was removed for reasons outlined in this PEP: http://legacy.python.org/dev/peps/pep-3113/ http://legacy.python.org/dev/peps/pep-3113/
  - deleted 10y ago
    [deleted]
- filmor 10y ago
  Your first point is incorrect, lambda works with the first syntax for both python 2 and 3. What /has/ changed, however, is the implicit destructuring: l = lambda (a, b): a + b l((1, 2)) I suspect there are very good reasons not to allow something like this. With regard to the second point, I also would have liked a more "gradual" step there, I find myself (especially in REPL environments) often doing `list(map(sth, sth))`. A `mapi`, `filteri` or something like this would probably not be zenny enough. Both don't pose very strong points for python 2 > 3.
  - rhaps0dy 10y ago
    PEP 3113 -- Removal of Tuple Parameter Unpacking http://legacy.python.org/dev/peps/pep-3113/ http://legacy.python.org/dev/peps/pep-3113/ These seem like OK reasons, but I find myself continuously needing the destructuring idiom in lambdas, while these introspection and documentation concerns are just not there for me. However tuple-parameters being an exception to rules (such as args and kwargs not being usable with them) is more compelling. And allowing destructuring only in lambdas would be weird, because they wouldn't be normal function objects any more. Unless the destructuring was only syntactic sugar for the translation in the PEP? But that's again inconsistent.
mrweasel 10y ago
As others pointed out, the cost of moving from 2.7 to 3 may simply be to high. Remember that while much can be done automatically, you still need to test that all your code still behaves as expected afterwards. I was one a project that did migrate a rather large web application and it was pretty painless, but I can easily imagine more complex code bases having issues. I don't really see the benefit of a Python 3.6 to 2.7 transpiler/compiler though. More realistically I would require that all new code be both 2 and 3 compatible, for when the eventual migration will happen. This isn't necessarily and easy task either, but then you're only depended on the Python project, not some random transpiler that might not see further development.
Grue3 10y ago
"Why don't you just rewrite it in X?" Because Python 3.X is not backwards compatible and we have millions of lines of production code in Python 2.X.
- jerryszczerry 10y ago
  > Because Python 3.X is not backwards compatible and we have millions of lines of production code in Python 2.X. I believe the common subset of Python 2 and 3 was created to ease that transition.
  - kec 10y ago
    That common subset doesn't include string handling.
    - pekk 10y ago
      You can absolutely do string handling in a common subset of Python 2 and Python 3. It won't work for legacy string handling code if you relied on implicit coercion, but then the same apps are unlikely to support unicode either.
      - masklinn 10y ago
        > It won't work for legacy string handling code if you relied on implicit coercion That's far from the only pitfall. For instance some of the P2 stdlib relies on implicit coercion to bytestrings whereas the Python 3 version has been properly converted to unicode (I discovered that when I tried to disable implicit coercion in one of the codebases I work with for cleanup/migration purposes). So cross-platform string handling is not just a matter of properly splitting bytestrings and textstrings, but also finding out where "native strings" need to remain.
xrange 10y ago
Thank you for signing up to help in the porting effort for FreeCAD and Pyspread to Python 3. Free software projects depend on volunteer contributors like you.
- dbcurtis 10y ago
  So I've been following FreeCAD since it started. Even tried to get my head around the code base at one point, but the hacking guide was mostly nonexistent in those days, so I moved on to projects that did not skip that very important step. Just to put a stake in the ground, when did FreeCAD start? When did 3.0 come out, along with the announced end-of-life date for 2.7?
  - xrange 10y ago
    Wikipedia says that the first release of FreeCAD was in 2002: https://en.wikipedia.org/wiki/FreeCAD https://en.wikipedia.org/wiki/FreeCAD ...Python 3.0 was released in 2008: https://www.python.org/download/releases/3.0/ https://www.python.org/download/releases/3.0/ ...It looks like the port of FreeCAD to Python 3 stared in 2015: https://forum.freecadweb.org/viewtopic.php?f=10&t=12534 https://forum.freecadweb.org/viewtopic.php?f=10&t=12534
CJefferson 10y ago
Mac still doesn't come with python 3 out of the box, so if i want to distribute a script to people without requiring them to install anything else, python 2 is my only option.
- lloeki 10y ago
  I don't get why Apple doesn't include python 3.x since they can easily slot it as they do for 2.6 and 2.7, and there was no licence change that I know of (in contrast with e.g bash 3.x vs 4.x) to justify that. Slightly tangential but system ruby is stuck at 2.0.0p648 (which is well into unsupported) and perl v5.18.2 (which I don't know the status support of but is old enough to wonder). They might as well rip them out and make them an optional package like CLI dev tools for possible backwards compatibility needs (easily installable either with something like xcode-select --install or the java/javac stubs).
  - a3n 10y ago
    Total guess, not a Mac guy, only know Apple by reputation: maybe they aren't interested in spending any resources for anyone to have modern tools that aren't Apple tools. "Y'all do what you want. If it doesn't come from us, you're on your own."
carapace 10y ago
Because it's going to be stable for the next N years. Python 2 is like FORTRAN. It might not be sexy anymore but it's not going anywhere.
- jerryszczerry 10y ago
  > Python 2 is like FORTRAN. It might not be sexy anymore but it's not going anywhere. Except Fortran is, and is going to be, further developed. (So, if a new useful programming concept appears, or a major design mistake is discovered, it always can be patched.) Python 2 is going to be abandoned in 2020. Python 3 will supersede it.
  - xrange 10y ago
    >Python 2 is going to be abandoned in 2020. But Python 2 is Free Software, so as long as people like it, they can keep improving it: https://github.com/naftaliharris/tauthon https://github.com/naftaliharris/tauthon
  - pekk 10y ago
    FORTRAN 77 is just as likely to be abandoned in 2020 as well. And?
    - jerryszczerry 10y ago
      How many uses can you find for Fortran 77 besides legacy systems?
      - carapace 10y ago
        Well now you're getting onto my personal reason why I don't adopt Python 3. Python 2 will remain just as useful as it's been. Python 3 will not significantly extend that usefulness. So I don't think there's much to be gained. The 3 syntax and new features are not massively better than the sweet spot hit by 2, they're not even incrementally better. They're just massively more complicated. So the cost/benefit ratio of Python 2 to 3 just isn't there. People are changing up because it's "the done thing" not because they really gain anything. I was surprised as hell when I realized I wouldn't use Python 3, but it is a rational and considered opinion.
Animats 10y ago
Most shared-hosting services don't support a reasonable version of Python 3 yet. HostGator still has Python 3.2, the "maximally incompatible" version.
- dbcurtis 10y ago
  Ouch
cthalupa 10y ago
Distributing a tool to OS distributions that do not have Python3.x (e.g. RedHat/CentOS 7) where the requirements include 'Not installing any additional packages' I hate it because Python2 is a flaming garbage heap, and 2.7 is what happens when you piss on a flaming garbage heap to put it out, whereas Python 3 is actually a nice language to work in, but until OS distributions get their act together on the Python front, some stuff is going to continue sucking.
- travisjungroth 10y ago
  2 and 3 have like a 90% overlap. How can you call one a flaming garbage heap and the other a nice language? I worked in Python 2 daily for about a year and a half (doing side stuff in 3), and switched over to Python 3 a few months ago. It's just not that big of a deal. Maybe it's because I'm pretty shielded from the madness of strings vs. bytes (or just import from future).
  - orf 10y ago
    > How can you call one a flaming garbage heap and the other a nice language? The lack of UnicodeDecodeErrors. Just because there is a 90% overlap doesn't mean one can't be a pile of trash (i think that's a bit harsh though). The improvements under the hood are huge (unicode, no 'new-style' classes, speed improvements etc) as well as syntactic sugar means that as time goes on Python 2 looks worse and worse.
  - cthalupa 10y ago
    >How can you call one a flaming garbage heap and the other a nice language? ---------- try: import queue as queue except ImportError: import Queue as queue ---------- They couldn't even consistently name portions of the standard library. Python 2 has a few random things where the first letter is capitalized while 99% of everything else isn't. There's all sorts of things like this, where poor design decisions cause you to sit there with question marks appearing over your head. That 10% takes Python from being a joy to work with to being incredibly frustrating. I would be happy if I could just work exclusively in 3, but making sure things are backwards compatible to 2.7 is a frequent source of driving me up the wall. >Maybe it's because I'm pretty shielded from the madness of strings vs. bytes (or just import from future). If you lose this shielding it will help you understand my vitriolic response as well.
tetraodonpuffer 10y ago
if you have a large py2 codebase in a shipping product, can you make an ROI argument that porting to py3 makes sense given the staff months required to do so?
BeetleB 10y ago
The standard answer to any question like this is: "Why should I switch to 3.x?" You haven't provided a reason to switch. I don't know if it was your intent, but your question assumes that Python 3.x is the "default", and that there is some sort of obligation to use it instead of 2.x. That's a premise that a lot of people do not share. As an example, they may not view 3.x as an "upgrade", but as a different language. So you might as well ask anyone doing work in one language "What reason is there for you to still use language X? Why not use language Y?" As long as some team is willing to support Python 2.7 (and possibly backport non-breaking features), 2.7 will live on, and there is no reason it should go away. The only strong reason for many to switch to 3.x is "I have a library I need to use that is supported only in 3.x". Or "I need to hire developers, and I can't find people who know 2.x, but I can find those who know 3.x" Languages are tools. As long as the tool is more than adequate for the task, the burden is on others to justify a change in tool.
- mikebenfield 10y ago
  The Python project itself is dropping support for Python 2 by 2020. Lots of major libraries have pledged to stop supporting Python 2 by 2020 or even before. Writing new code in Python 2 is completely nuts and just makes everyone's life harder (including your own).
  - BeetleB 10y ago
    >Writing new code in Python 2 is completely nuts and just makes everyone's life harder (including your own). And when it makes someone's life harder, they will change. If it's too late for them and affects them, they will have themselves to blame. This, really, is the only reason for people to change to Python3. Yet people keep evangelizing all its great features, etc as if the existence of a much better language suddenly obligates everyone to switch to it. It's fine to point out potential repercussions of not switching now. But moralizing it is counterproductive.
flohofwoe 10y ago
In my case: MacOS has python 2.7 pre-installed, and python3's lack of backward compatibility is mildly annoying while giving very little actual improvements in return.
a3n 10y ago
I'm working on something right now in 2.7, a personal project. One of the 3rd party tools has a note about 3 with just enough of a "mostly" that I just don't want to encounter the speed bump or road block or whatever it's going to be. And also, the code isn't really the major part of the project.

gizmo385 10y ago

Because sometimes the amount of work required to port a 2.7 project to 3.x isn't worth it.

dbcurtis 10y ago
So, then it is a small project that is near end-of-life, and easily replaced?
- richardwhiuk 10y ago
  No, a large project, which isn't easily replaced, whether or not it's near the end of it's life, or anything using a Py2 only dependency
compuguy 10y ago
Ansible currently only supports Python 2.7....

run4yourlives2 10y ago

Serious Answer: Because some of us have some rather large perfectly working systems written in 2.7 and using lots of different libraries that moving to 3 is a major project requiring a good amount of time and effort. Not all of us have hobby-sized projects on the go.

kzrdude 10y ago
Even hobby sized projects can be a major chore. Especially if it's wrapped up in a Gtk transition too.
dbcurtis 10y ago
OK, but this has been a very long transition. There has been lots of time to evolve to 3.x. Has the primary barrier been the slow transition of library dependancies? I'd really like to understand this from a technology transition management standpoint. If you'll allow a strained analogy, the 2.7 to 3.x transition appears in retrospect like an exercise in herding cats, because the transition was done using cat-herding style incentives. What should have been done differently to make the transition into greyhounds chasing a rabbit? What should the rabbit have been? Any technology that lives long enough eventually has to transition its customer base. I'm trying to learn to identify rabbits.
- chc 10y ago
  Asking this question without disqualifying the answer "No breaking changes whatsoever" usually just generates a bunch of different ways of phrasing that.
  - dbcurtis 10y ago
    No, I don't buy that. IBM successfully transitioned a huge customer base from 709/7090 36-bit words to System 360 32 bit words. The transition from 32 to 64 bit addresses was rocky for a lot of architectures. DEC Alpha, Intel Itanium. But are you still running a 32 bit OS? K&R C no longer compiles. Not that the C to C++14 transition is what I would call an example of greatness, but it is somewhere along the success spectrum. Seriously, you will someday need to transition your customer base. How do you plan to do it?
    - chc 10y ago
      Yes, I agree with you. That's why I said you should disqualify that answer. It's by far the most common answer, but it's also obviously not the right answer.
    - xrange 10y ago
      >K&R C no longer compiles. foo@virt-ubuntu:~/c$ gcc --version gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. foo@virt-ubuntu:~/c$ cat 'k&r.c' #include<stdio.h> int main(argc, argv) int argc; char *argv[]; { puts("hello, world!"); return 0; } foo@virt-ubuntu:~/c$ gcc 'k&r.c' foo@virt-ubuntu:~/c$ ./a.out hello, world!

Marat_Dukhan 10y ago

Because Python 2.7 is, IMO, a better language than Python 3+, e.g.: - I like lambda a, b: a + b syntax better than lambda a_b: a_b[0] + a_b[1] - I prefer map/reduce/filter to return lists rather than iterable - I prefer dict.keys/values/items to return sets/lists rather than iterables, unless I call dict.iter[keys/values/items]

rhaps0dy 10y ago
Iterables are so much better on memory though. I wonder why isn't "lambda (a, b): a+b" allowed?
- omaranto 10y ago
  It was removed for reasons outlined in this PEP: http://legacy.python.org/dev/peps/pep-3113/ http://legacy.python.org/dev/peps/pep-3113/
- deleted 10y ago
  [deleted]
filmor 10y ago
Your first point is incorrect, lambda works with the first syntax for both python 2 and 3. What /has/ changed, however, is the implicit destructuring: l = lambda (a, b): a + b l((1, 2)) I suspect there are very good reasons not to allow something like this. With regard to the second point, I also would have liked a more "gradual" step there, I find myself (especially in REPL environments) often doing `list(map(sth, sth))`. A `mapi`, `filteri` or something like this would probably not be zenny enough. Both don't pose very strong points for python 2 > 3.
- rhaps0dy 10y ago
  PEP 3113 -- Removal of Tuple Parameter Unpacking http://legacy.python.org/dev/peps/pep-3113/ http://legacy.python.org/dev/peps/pep-3113/ These seem like OK reasons, but I find myself continuously needing the destructuring idiom in lambdas, while these introspection and documentation concerns are just not there for me. However tuple-parameters being an exception to rules (such as args and kwargs not being usable with them) is more compelling. And allowing destructuring only in lambdas would be weird, because they wouldn't be normal function objects any more. Unless the destructuring was only syntactic sugar for the translation in the PEP? But that's again inconsistent.

mrweasel 10y ago

As others pointed out, the cost of moving from 2.7 to 3 may simply be to high. Remember that while much can be done automatically, you still need to test that all your code still behaves as expected afterwards. I was one a project that did migrate a rather large web application and it was pretty painless, but I can easily imagine more complex code bases having issues. I don't really see the benefit of a Python 3.6 to 2.7 transpiler/compiler though. More realistically I would require that all new code be both 2 and 3 compatible, for when the eventual migration will happen. This isn't necessarily and easy task either, but then you're only depended on the Python project, not some random transpiler that might not see further development.

Grue3 10y ago

"Why don't you just rewrite it in X?" Because Python 3.X is not backwards compatible and we have millions of lines of production code in Python 2.X.

jerryszczerry 10y ago
> Because Python 3.X is not backwards compatible and we have millions of lines of production code in Python 2.X. I believe the common subset of Python 2 and 3 was created to ease that transition.
- kec 10y ago
  That common subset doesn't include string handling.
  - pekk 10y ago
    You can absolutely do string handling in a common subset of Python 2 and Python 3. It won't work for legacy string handling code if you relied on implicit coercion, but then the same apps are unlikely to support unicode either.
    - masklinn 10y ago
      > It won't work for legacy string handling code if you relied on implicit coercion That's far from the only pitfall. For instance some of the P2 stdlib relies on implicit coercion to bytestrings whereas the Python 3 version has been properly converted to unicode (I discovered that when I tried to disable implicit coercion in one of the codebases I work with for cleanup/migration purposes). So cross-platform string handling is not just a matter of properly splitting bytestrings and textstrings, but also finding out where "native strings" need to remain.

xrange 10y ago

Thank you for signing up to help in the porting effort for FreeCAD and Pyspread to Python 3. Free software projects depend on volunteer contributors like you.

dbcurtis 10y ago
So I've been following FreeCAD since it started. Even tried to get my head around the code base at one point, but the hacking guide was mostly nonexistent in those days, so I moved on to projects that did not skip that very important step. Just to put a stake in the ground, when did FreeCAD start? When did 3.0 come out, along with the announced end-of-life date for 2.7?
- xrange 10y ago
  Wikipedia says that the first release of FreeCAD was in 2002: https://en.wikipedia.org/wiki/FreeCAD https://en.wikipedia.org/wiki/FreeCAD ...Python 3.0 was released in 2008: https://www.python.org/download/releases/3.0/ https://www.python.org/download/releases/3.0/ ...It looks like the port of FreeCAD to Python 3 stared in 2015: https://forum.freecadweb.org/viewtopic.php?f=10&t=12534 https://forum.freecadweb.org/viewtopic.php?f=10&t=12534

CJefferson 10y ago

Mac still doesn't come with python 3 out of the box, so if i want to distribute a script to people without requiring them to install anything else, python 2 is my only option.

lloeki 10y ago
I don't get why Apple doesn't include python 3.x since they can easily slot it as they do for 2.6 and 2.7, and there was no licence change that I know of (in contrast with e.g bash 3.x vs 4.x) to justify that. Slightly tangential but system ruby is stuck at 2.0.0p648 (which is well into unsupported) and perl v5.18.2 (which I don't know the status support of but is old enough to wonder). They might as well rip them out and make them an optional package like CLI dev tools for possible backwards compatibility needs (easily installable either with something like xcode-select --install or the java/javac stubs).
- a3n 10y ago
  Total guess, not a Mac guy, only know Apple by reputation: maybe they aren't interested in spending any resources for anyone to have modern tools that aren't Apple tools. "Y'all do what you want. If it doesn't come from us, you're on your own."

carapace 10y ago

Because it's going to be stable for the next N years. Python 2 is like FORTRAN. It might not be sexy anymore but it's not going anywhere.

jerryszczerry 10y ago
> Python 2 is like FORTRAN. It might not be sexy anymore but it's not going anywhere. Except Fortran is, and is going to be, further developed. (So, if a new useful programming concept appears, or a major design mistake is discovered, it always can be patched.) Python 2 is going to be abandoned in 2020. Python 3 will supersede it.
- xrange 10y ago
  >Python 2 is going to be abandoned in 2020. But Python 2 is Free Software, so as long as people like it, they can keep improving it: https://github.com/naftaliharris/tauthon https://github.com/naftaliharris/tauthon
- pekk 10y ago
  FORTRAN 77 is just as likely to be abandoned in 2020 as well. And?
  - jerryszczerry 10y ago
    How many uses can you find for Fortran 77 besides legacy systems?
    - carapace 10y ago
      Well now you're getting onto my personal reason why I don't adopt Python 3. Python 2 will remain just as useful as it's been. Python 3 will not significantly extend that usefulness. So I don't think there's much to be gained. The 3 syntax and new features are not massively better than the sweet spot hit by 2, they're not even incrementally better. They're just massively more complicated. So the cost/benefit ratio of Python 2 to 3 just isn't there. People are changing up because it's "the done thing" not because they really gain anything. I was surprised as hell when I realized I wouldn't use Python 3, but it is a rational and considered opinion.

Animats 10y ago

Most shared-hosting services don't support a reasonable version of Python 3 yet. HostGator still has Python 3.2, the "maximally incompatible" version.

dbcurtis 10y ago
Ouch

cthalupa 10y ago

Distributing a tool to OS distributions that do not have Python3.x (e.g. RedHat/CentOS 7) where the requirements include 'Not installing any additional packages' I hate it because Python2 is a flaming garbage heap, and 2.7 is what happens when you piss on a flaming garbage heap to put it out, whereas Python 3 is actually a nice language to work in, but until OS distributions get their act together on the Python front, some stuff is going to continue sucking.

travisjungroth 10y ago
2 and 3 have like a 90% overlap. How can you call one a flaming garbage heap and the other a nice language? I worked in Python 2 daily for about a year and a half (doing side stuff in 3), and switched over to Python 3 a few months ago. It's just not that big of a deal. Maybe it's because I'm pretty shielded from the madness of strings vs. bytes (or just import from future).
- orf 10y ago
  > How can you call one a flaming garbage heap and the other a nice language? The lack of UnicodeDecodeErrors. Just because there is a 90% overlap doesn't mean one can't be a pile of trash (i think that's a bit harsh though). The improvements under the hood are huge (unicode, no 'new-style' classes, speed improvements etc) as well as syntactic sugar means that as time goes on Python 2 looks worse and worse.
- cthalupa 10y ago
  >How can you call one a flaming garbage heap and the other a nice language? ---------- try: import queue as queue except ImportError: import Queue as queue ---------- They couldn't even consistently name portions of the standard library. Python 2 has a few random things where the first letter is capitalized while 99% of everything else isn't. There's all sorts of things like this, where poor design decisions cause you to sit there with question marks appearing over your head. That 10% takes Python from being a joy to work with to being incredibly frustrating. I would be happy if I could just work exclusively in 3, but making sure things are backwards compatible to 2.7 is a frequent source of driving me up the wall. >Maybe it's because I'm pretty shielded from the madness of strings vs. bytes (or just import from future). If you lose this shielding it will help you understand my vitriolic response as well.

tetraodonpuffer 10y ago

if you have a large py2 codebase in a shipping product, can you make an ROI argument that porting to py3 makes sense given the staff months required to do so?

BeetleB 10y ago

The standard answer to any question like this is: "Why should I switch to 3.x?" You haven't provided a reason to switch. I don't know if it was your intent, but your question assumes that Python 3.x is the "default", and that there is some sort of obligation to use it instead of 2.x. That's a premise that a lot of people do not share. As an example, they may not view 3.x as an "upgrade", but as a different language. So you might as well ask anyone doing work in one language "What reason is there for you to still use language X? Why not use language Y?" As long as some team is willing to support Python 2.7 (and possibly backport non-breaking features), 2.7 will live on, and there is no reason it should go away. The only strong reason for many to switch to 3.x is "I have a library I need to use that is supported only in 3.x". Or "I need to hire developers, and I can't find people who know 2.x, but I can find those who know 3.x" Languages are tools. As long as the tool is more than adequate for the task, the burden is on others to justify a change in tool.

mikebenfield 10y ago
The Python project itself is dropping support for Python 2 by 2020. Lots of major libraries have pledged to stop supporting Python 2 by 2020 or even before. Writing new code in Python 2 is completely nuts and just makes everyone's life harder (including your own).
- BeetleB 10y ago
  >Writing new code in Python 2 is completely nuts and just makes everyone's life harder (including your own). And when it makes someone's life harder, they will change. If it's too late for them and affects them, they will have themselves to blame. This, really, is the only reason for people to change to Python3. Yet people keep evangelizing all its great features, etc as if the existence of a much better language suddenly obligates everyone to switch to it. It's fine to point out potential repercussions of not switching now. But moralizing it is counterproductive.

flohofwoe 10y ago

In my case: MacOS has python 2.7 pre-installed, and python3's lack of backward compatibility is mildly annoying while giving very little actual improvements in return.

a3n 10y ago

I'm working on something right now in 2.7, a personal project. One of the 3rd party tools has a note about 3 with just enough of a "mostly" that I just don't want to encounter the speed bump or road block or whatever it's going to be. And also, the code isn't really the major part of the project.