5 ms·

> The main reason for Python 2 users to not switch to Python 3 is the lack of motivation/killer features. We need to therefore be more proactive in encouraging

• tormeh 11y ago
  Directing people to the newest version is unsolved. If you type "apt-get install python [or pypy]" you get 2.7. This is obviously a problem. Basically, everything here suggests that 2.7 is the official version and 3 is some kind of risky beta.
  • broodbucket 11y ago
    It's anecdotal, but Arch has had Python 3 as default for over a year. I think Fedora is coming close to this too.
    • keenerd 11y ago
      Almost five years[1] in fact. To correct some other common misunderstandings elsewhere, it is not correct to say that python3's "changes are extremely breaking." It is easy to write code that runs under both 2 and 3, and 2to3 can convert 99% of code I've thrown at it[2]. The last one percent is straight up bad code that does crazy things like override the list() function with a variable. The other pain point is hybrid python-C libraries that monkey around with Python internals - but those often have trouble keeping up with mere point releases. Given everything done to make the transition easy, if a library doesn't work under python3 by now it is a code smell. Either the library does weird things under the hood or it is practically unsupported. Regarding "lack of killer features", there are some pretty compelling ones[3]. I've been writing all my code in py3 (or at least making it support both 2 and 3) for years now. [1] https://www.archlinux.org/news/python-is-now-python-3/ https://www.archlinux.org/news/python-is-now-python-3/ [2] About two dozen packages I maintain and a bunch of personal projects. [3] http://asmeurer.github.io/python3-presentation/python3-presentation.pdf http://asmeurer.github.io/python3-presentation/python3-prese...
    • eeZi 11y ago
      So is Ubuntu.
• sebastianavina 11y ago
  just include it for default in ubuntu repositories and distributions
• ubernostrum 11y ago
  In my experience the main reason is actually people who just looked at 3.0, decided it didn't have anything new and required work to port over, and then never looked at 3.1, 3.2, 3.3, 3.4 or the in-progress 3.5. Which means those people don't know about/don't get to use, among other things: * Vastly improved unittest module, including mock objects * Dictionary-based logging config * The sysconfig module * The pathlib module * Built-in enums * Single-dispatch generic functions * The statistics module * The asyncio module * The "yield from" syntax to delegate to generators * The lzma module * The ipaddress module And that's without getting into 3.5, which adds things like the matrix multiplication operator that science-y packages will care about and probably port for.
  • ghshephard 11y ago
    You can probably scratch the statistics module as something scientists might be interested in; as much as it's simple set of functions is useful for new users who are overwhelmed by numpy, it doesn't add any new capability to python. With that said - I love it.
  • lqdc13 11y ago
    Almost none of these things are used in scientific computing though. Maybe asyncio and yield from.
    • ubernostrum 11y ago
      I suspect enums have uses, as do the improved async code constructs (and there's more of that in the pipeline).
      • m_mueller 11y ago
        Yes, I do use python for scientific applications and enums are one of the things I miss - I've built around it in python 2.x by using this construct: def enum(*sequential, **named): enums = dict(zip(sequential, range(len(sequential))), **named) return type('Enum', (), enums) Init = enum("NOTHING_LOADED", "DEPENDANT_ENTRYNODE_ATTRIBUTES_LOADED", "ROUTINENODE_ATTRIBUTES_LOADED", "DECLARATION_LOADED" ) myState = Init.NOTHING_LOADED 3.x is still a non starter for me since many clusters where I want my software to work still only come with 2.6, e.g. I can't even use dictionary comprehensions. Adoption for scientific software is heavily influenced by how many external dependencies you have - requiring users without root access to compile python 3.x for their cluster home is a no-go.
• forgottenacc56 11y ago
  Yep stick to Vax/Vms
• titanomachy 11y ago
  Maybe for the sake of having a single version to focus maintenance efforts on?
  • fnordfnordfnord 11y ago
    I've never seen it happen. (having a single version to focus maintenance efforts on) 1. Waiting for other favorite libraries to be ported over. 1. Waiting for other people to work the bugs out. 1. Waiting for a new project to work on. I have work ongoing in Python3 and 2.7; and I have no plans to migrate existing work from 2.7 to 3. I would not have migrated existing projects that are working; let sleeping dogs lie, seriously, you'd have to fight a lot of scientists if you told them you wanted to change anything in their (working) DAQ, just for the hell of it.
• Orangeair 11y ago
  It's not that it isn't good enough, it's that the cost of switching is larger than the value of what they believe they would gain. I believe this is very common in academic settings (consider, for instance, how many people still see no reason to switch away from Fortran).
  • orangecat 11y ago
    It's not that it isn't good enough, it's that the cost of switching is larger than the value of what they believe they would gain. That's exactly what "not good enough" means. Getting rid of the GIL, or a 5x performance increase, or optional static typing might have been worth breaking everyone's code. Somewhat better Unicode handling wasn't.
    • actsasbuffoon 11y ago
      Jython and IronPython both remove the GIL, and PyPy is often roughly 5x faster than CPython. Strangely enough, these projects don't seem to be as widely used as I'd expect. By the way, optional static typing is available in any version of Python by using MyPy.
      • netheril96 11y ago
        Because all the alternatives do not support many C-extensions, especially numpy, without which no scientists would look at Python at all.
      • mixmastamyk 11y ago
        All three of those bundled into the official release might have done it.
  • coldtea 11y ago
    >I believe this is very common in academic settings It's even more common in enterprise settings, where the cost of switching also includes real money, not just some postgraduates porting code over...
  • 11y ago
• mplewis 11y ago
  Because Python 3 made breaking changes that make the langauge easier to use for 99% of people. But the changes are extremely breaking.
  • tomrod 11y ago
    This has been my takeaway too.
• po 11y ago
  First of all, it's not evil so let's not get crazy. "The main reason for Python 2 users to not switch to Python 3 is the lack of motivation/killer features". Which says that users are familiar with what Python 3 has to offer but consider it not good enough. You could have lack of motivation because you're familiar and decide that you don't need it - or - you could have lack of motivation out of ignorance or misunderstanding about the benefits. Both are reasonable and if it's the second one, there would be benefit from being more proactive about directing people to switch and explaining the reasons. Why would you then jump to a conclusion that you have to be more proactive in directing people to switch to Python 3. Or even better, to stop adding features to what 81% of people use. Maintaining 2 lines of development does have a cost associated with it for the entire python community involved. I think overlooking this was part of the problem with choosing this python3 strategy to begin with. I personally would not have done it this way and I get what you're saying about continuing 2.7 line but I think it's too late and now 2.7 and 3.4 have improved to the point where the porting task is reasonable. I think at this point the community should just get it over with. I say this as someone who primarily develops on python 2.7 (mainly due to library dependencies) so I get where you're coming from.
  • nnain 11y ago
    That pretty much sums it up for me. I wouldn't have done it this way, but we are too far ahead on the Python 3 line and it's probably time to let go off the debate and move on to Python 3, at least for new projects. Needless to say that the Python web developers community was set back by couple of years due to diverted attention. When Python should have been looking at concurrency and async support, everyone had to get busy maintaining duplicate code. The biggest issue probably was for the library developers (Django, Flask, Jinja, pymongo etc) to create a new Py3 package. But now that most of the important libraries and frameworks have moved to Python 3, application developers could probably move along with the change. It's not that much work for the app developers.
• est 11y ago
  > by (a) making sure that any new users are always directed to the latest Python 3 version, and (b) releasing, in the near future, new major versions of packages for Python 3 only How about a major speedup? Even a 10% speed up would be a big motivation! You don't need fancy JIT, just less costy function calls and modern interpreter optimizations.
• Grue3 11y ago
  Reminds me of Mozilla and HTTPS.