11 ms·

Python Versions Used in Commercial Projects, 2016 Edition

160 points by markoa 10y ago

scrollaway 10y ago
Python 3 is omnipresent in my work right now and it is so nice not to have to worry about, for example, unicode issues. The only thing I'm dealing with which is still not Python 3 compatible is AWS Lambda, which only offers 2.7 right now. Supposedly Amazon is working on 3.x but... come on.
- 2T1Qka0rEiPr 10y ago
  Python 3 doesn't remove unicode issues, although granted you probably run into fewer issues when defaulting to unicode over a bytestring.
  - vuanotino 10y ago
    It doesn't? I've ran into UnicodeDecodeError exceptions literally every time I've had to deal with external input in Python 2. It was a nightmare, and it made me hate Python. With Python 3, that simply has never happened to me. Never. I don't know why. I don't know what the change, what the secret sauce was. And what's even better: I don't have to care. Python now simply works for me. So yes, Python did remove Unicode issues.
  - doppel 10y ago
    Because unicode is default and the byte-type is single-byte adressable (rather than 1 character in <encoding>) it makes it more straightforward. It's not perfect, but it helps a lot.
  - sevensor 10y ago
    Python 3 doesn't remove all unicode issues, it's not magic. But the pain is 95% gone compared with Python 2. I write Python for a living, and my life has been a lot better since we switched.
- tyfon 10y ago
  Same at my place, 2.x is banned for all purposes.
  - brianwawok 10y ago
    Ansible only works with 2.x, so that is perhaps the only exception I would make... (if you are an ansible shop). But ansible scripts tend to be like 5 lines, so it is not the same as the scale you would write a webapp or something in Python3...
    - eeZi 10y ago
      For Ansible, it's important to differentiate between the master and client side code. Client side code has to run on everything starting with CentOS 6, so they have to stick with Python 2 for a long time. For the Ansible master (which runs on the management machine), Python 3 porting work is already underway.
    - AdamN 10y ago
      We're a Python shop but all of our Ansible work is just YAML. Ansible is a program more than a library so it's almost irrelevant what version of Python they use. Now, of course it's highly annoying to have to bootstrap python2 on Ubuntu Xenial but that's really not relevant to what version of Python a group uses for regular development. We use Python 3.5 and are VERY happy about it.
- eeZi 10y ago
  Same here. Haven't had a single Unicode bug in production since we switched to Python 3. Also, chained exceptions (extremely valuable in walled-off production environment). Type annotations actually work and have prevented a number of bugs. The asyncio syntax is really nice with Tornado (don't use aiohtto, use Tornado! it's much more mature)
- moduspwnens14 10y ago
  Came here to say this. I've default to Python 3 for all new projects (our new stuff is primarily on Ubuntu 16.04 anyway), but we use AWS Lambda a lot and it's still stuck at 2.7 for now.
- pmontra 10y ago
  They're also only Node 4.3.2. It seems that they need quite a while to test new versions, or they have little man power and are constrained to keep working with what they know it worked.
- msl09 10y ago
  I'm slightly moving backwards. Previously I just make Python 3 scripts with 0% retrocompatibility because I thought that Python 3 was going to happen soon and it was futile to try to resist. Now that my programs and scripts are getting used more frequently at work and outside of work I'm making more Python 2-3 compatible code because often people just try to use python myscript.py (that might just call any interpreter), or they use myscript.py in an development environment that only uses Python 2. It's a bit sad to not be able to use some things that I really love about Python 3 but it makes me happier to see other people enjoying my work, so I'm going to bear with it for now.
- rgacote 10y ago
  The only time we're writing new Python 2.7 code is when we're working with Twisted (and they are vigorously migrating to Python 3). All other new code is Python 3.5 based and we're not looking back at all. Using asyncio has been a delight for a lot of the small, quick web services we need to write (though not a replacement for Twisted). Looking forward to seeing the asyncio infrastructure grow.
binarymax 10y ago
I blame in part, that the default install for OS's like Ubuntu and Mac is Python 2.7. If you are starting python development, and want to support more systems, and you know the default is 2.7, then that's what you will target.
- teekert 10y ago
  Python 3 is the default in 16.04 LTS.
  - deleted 10y ago
    [deleted]
  - 2T1Qka0rEiPr 10y ago
    I just posted that my default Python is 2 and I'm on 16.04.1, but I suppose the upgrade from 15.10 perhaps left the default as-is?
    - teekert 10y ago
      I think the fact that python points to python 2 and python3 points to python 3 does not mean one is default and the other is not. One would think so, yes, but this is a bit of difficult case, for historic reasons. Both versions will need to be present because many things depend on 2 still (ufw for one I believe), python 2 was just there first and hence earned the badge "python". To now switch to explicitly calling it python2 and calling python 3 python would break many things probably. On a clean 16.04 install, python 3 is present, python 2 is not, however, you still need to call python 3 with "python3" [0] [0] https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#Python_3 https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#Python_3 Edit: See qznc's remark on the pep, apparently it's even advised the keep "python" pointing to python 2.
    - dagw 10y ago
      I suppose the upgrade from 15.10 perhaps left the default as-is? Yes. If you do a clean install of 16.04 then you won't python2 installed at all.
  - 10y ago
noir_lord 10y ago
http://i.imgur.com/EJM1viF.png http://i.imgur.com/EJM1viF.png That's why Python 2.7 will be around and maintain dominance for a while. When the latest stable releases of the primary environments are defaulting to something you have to have very good reasons why not to use the default (even when it's easy to change the default). Administrators (in the old school not the new "everything in containers") don't like using non-defaults.
- berntb 10y ago
  Hmm... you really use the system Python installation for development? Python is not pathologically backwards compatible, what happens when the next OS version use a newer Python 2 version?
  - noir_lord 10y ago
    Personally? I don't, I use Python 3 and virtualenvs but then everything I write in Python is for myself to do things for me. If I was writing software that had to be used in as many places as possible or sold, I'd absolutely strongly consider using 2.7.
  - cuu508 10y ago
    You don't simply upgrade your production machines to the next OS version with fingers crossed. You do some testing and validation first. Say, you use containers and so your application is isolated from the host system. When the next version of your host system comes with a new version of Docker, you have to do similar testing and validation anyway.
- juriansluiman 10y ago
  Afaik, it has nothing to do with Ubuntu or any other Linux distro specifically, but this is rather a choice from python itself. See PEP394 [1]: "for the time being, all distributions should ensure that python refers to the same target as python2." I read above as the python community itself made "python" the default for python 2.7 and "python3" for python 3.x. Nevertheless, an unfortunate choice at this time. I understand the reasoning at the time of writing (March 2011) but now this should be reconsidered. [1] https://www.python.org/dev/peps/pep-0394/
lovelearning 10y ago
Title should be changed to "Python Versions Used in Commercial Projects, 2016 Edition". The data pertains only to Semaphore's commercial CI customers.
dr_zoidberg 10y ago
Wouldn't call 28% "largely ignored", rather "still lagging behind". Thing is, 3.6 looks like the real deal breaker here, what Python 3.0 should've been. With asyncio, compact dicts and scandir I've gotten to the point where I can almost justify to my employer why, if everything is still working, we should move to Python 3.6 ("all will be faster" -- I know I'm kind oversimplifying here, but my boss pretty much doesn't understand software and just wants results/money). There's also the sentiment of "I don't know if [insert module here] will be supported", which has become mostly baseless fear, but people still think Py3 support is lacking (when it's not![0]). [0] https://python3wos.appspot.com/ https://python3wos.appspot.com/ -- also, take notice how 9 of this guys come from here [1] [1] http://mozbase.readthedocs.io/en/latest/ http://mozbase.readthedocs.io/en/latest/ Edit: when I posted this comment, the link was titled "Python 3 largely ignored" (not the article per se, but the submitted link had been titled that way). It has been changed, but this was a bit of important context for my comment.
- Siecje 10y ago
  I'm still waiting for supervisor, beanstalkc, and cloudsigma.
  - AdamN 10y ago
    Not sure why supervisor matters, it's just a program. It's the same thing as Homebrew running Ruby - totally doesn't matter what version they're using.
    - mi100hael 10y ago
      It does if you're using their API
  - dr_zoidberg 10y ago
    Of course, specific projects might not be covered, but I've seen a lot of people go "ok, just to be safe I'll use 2.7 in case down the road I get to need anything that's Py2 specific". In your case you know exactly what your needs are, and that they're unsupported in Python 3, but I'm sure that many of those 70% Py2 projects could run just as well in Py3.
d_theorist 10y ago
I'm actually surprised (pleasantly) to see that adoption is that high. I would have guessed at less than 10%. I suppose the sample set (projects using a tool like Semaphore) is likely to be biased towards more forwards-looking teams, but still.
rlpb 10y ago
Commercial projects are the laggards. I'd expect them to be the last to move over. More interesting I think is the progress in distributions. This matters because commercial projects use distributions too, and will need to follow them in the end.
lmm 10y ago
Flamebait title, and doesn't match the article. 30% adoption, while not exactly a big success, is nothing to sniff at.
w8rbt 10y ago
I think this shows just how good Python 2 is ;)
pjc50 10y ago
Let this (and Perl 6) be a lesson to language designers: do not make backward-incompatible changes, ever. It cripples adoption. Java managed this much better by being able to mark APIs as "deprecated".
- berntb 10y ago
  You got a point I agree with but a bad example since Perl 6 is a new language. (That the name don't reflect that is still a heated discussion.) (And Perl 5 code can declare which of the newer features it will support. Excellent backwards compatibility.)
- dri_ft 10y ago
  Then again, continuing to add backward-compatible changes to Perl 5 would have made it an even bigger pile of mud than it already is. Its refusal to make backward-incompatible changes is both the reason why Perl 5 was so ubiquitous and why it's so very ugly. So I can certainly understand the desire to start afresh with 6, in spite of the costs in terms of adoption. It does seem like take-up has been low so far, but it's probably still too early to call whether it will turn out to have been the right choice. I'm less familiar with Python, so can't really comment on there, but it does seem that Python 2.7 had fewer egregious faults than Perl 5.
  - berntb 10y ago
    There are quite a few backwards incompatible extensions for Perl 5. But you must declare what new features to use. Then there is Devel::Declare etc with extensible syntax... :-) http://perldoc.perl.org/feature.html http://perldoc.perl.org/feature.html
- moduspwnens14 10y ago
  I think the main change (accurate handling of strings potentially encoded with multiple bytes) hit a lot of languages from that time in bad ways. I think it's something that more or less had to be done since the alternatives are worse, but we haven't seen a similar issue pop up in a long time. I don't think the lesson applies in many other places. Certainly open to my mind being changed, though!
wtbob 10y ago
Former Python developer here. The problem was two-fold: Python 3 broke backwards- and forward-compatibility (in a practical sense: there were workarounds, but libraries didn't necessarily use 'em, and Python is nothing if not a glue language); and for the longest time there really wasn't a good reason to switch. I think it wasn't until last year that it really started to make sense to go with Python 3 — and by then I'd already switched to Go.
- mherrmann 10y ago
  Python and Go aren't really mutually exclusive though. Some things will better be done in Python, others in Go.
  - rgacote 10y ago
    Tried go and fairly quickly headed back to Python. Kept running into annoyances that slowed development. Not being able to get a NULL back from a database without a third-party library was the final straw (go 1.5, might have changed since then). I understand there's obvious use cases for Go, but an amazing amount of what we do is taking data from place 'A' (web, socket, file), sending it to place 'B' (another web, socket, file), and then returning a result. Go doesn't buy you much that asyncio won't.
    - wtbob 10y ago
      > I understand there's obvious use cases for Go, but an amazing amount of what we do is taking data from place 'A' (web, socket, file), sending it to place 'B' (another web, socket, file), and then returning a result. Go doesn't buy you much that asyncio won't. Static typing. Oh Lord is it nice. When I wrote Python, I never quite knew if there'd be a runtime error (in my code or a library). With Go, there are a lot fewer of those.
      - y4mi 10y ago
        static typing has become possible with python3, though i don't use it for my personal projects.
rtpg 10y ago
this headline is a bit much. 1/3rd of new projects use Python 3! A lot of people are excited about the language now that a lot of the warts have been dealt with and language compat is higher than ever. Though all it takes is one dependency to throw a wrench in the plans, the major projects are Py3 now. Though porting large python 2 projects is still a huuuuuge pain. This is more a result of python 2 badness than python 3. But a lot of work.
sixhobbits 10y ago
Maybe unjustified, but I'm always kind of suspicious of a post which is largely focused on raw data (like this one) and which presents only pie-chart visualsations [0]. Yes, Python has a pretty dirty history, with many people choosing to stick to the Python 2.7 that they knew and loved. And yes, commercial software tends to move waaay slower than the wider community (many banks are still running COBOL). If you're focused on making money and pleasing clients then "it worked for us before" is always going to be the strongest argument. Major players in the Python eco system have pledged to move away from Python 2 [1], and if we had non pie-chart visualisations, I'm sure we'd see huge trends towards Python 3 in the last year. Even slow-moving corporations are starting to use Python3. Yes, MacOS defaulting to Python2 is still a problem, but Ubuntu switching to default Python3 is already a huge step to get companies to move forwards. [0] http://www.businessinsider.com/pie-charts-are-the-worst-2013-6 http://www.businessinsider.com/pie-charts-are-the-worst-2013... [1] https://python3statement.github.io/ https://python3statement.github.io/
- qznc 10y ago
  Do not underestimate COBOL. The latest version is from 2014. https://en.wikipedia.org/wiki/COBOL#COBOL_2014 https://en.wikipedia.org/wiki/COBOL#COBOL_2014
  - 1wd 10y ago
    How many commercial projects use COBOL 2014 though? I know Fortran 77 is still considered newfangled in some circles, even though Fortran 90, 95, 2003, 2008, 2015 exist. Same with C90, C++98, etc.
    - zcdziura 10y ago
      Net-new COBOL code is being written every day in the Enterprise world. I work on a team that's actively updating and maintaining a large COBOL codebase. The default standard that most people write to is COBOL-85. Just because the language is old doesn't mean that it can't be the right tool for the right job. For batch processing-type tasks, there nothing better than COBOL on the mainframe. By default, COBOL doesn't allow for you to dynamically allocate memory. That makes it incredibly easy for the compiler and system to optimize the compiled code and make it run super fast. COBOL is great for what it was designed for: processing data. If you want to read data from a file/database, process it in some way, and then save that data back to the database/another file, you can't do much better than what COBOL offers.
Siecje 10y ago
What would a project that supports both Python2 and Python3 show up as in these charts? How many of the projects support both?
someguydave 10y ago
I'm glad that python 2 is unpopular with cool kids. Otherwise they might be inserting broken feature every minor revision.
bdg 10y ago
Of course it is. Python is full of language snobs who insist their language is beautiful and the quality is great. They insist there's no reason to change, except for some reason, to go.
INTPenis 10y ago
I expend considerable effort that I am not obliged to expend to use Python 3 whenever possible. I'm sure that I'm not unique. Right now in my life the major things stopping me from using python 3 for all the things are. * Ansible * Two large in-house developed apps taken over from previous devs * Debian Wheezy And as you can guess, at least one of those will hopefully disappear soon. Other than that I try to use python 3 as much as possible. I know a lot of the workaround for getting pyvenv working on various distros for example. I also know about a lot of alternative libs like ldap3, dnspython3 and more.
- taneq 10y ago
  > I expend considerable effort that I am not obliged to expend to use Python 3 whenever possible. Isn't that kind of a bad sign, though? Should it really require 'considerable effort' to use the latest release of a fairly widely adopted language?
  - INTPenis 10y ago
    It's a good sign in the sense that people want to move forward. But yes, it's a bad sign in the sense that more effort is required than with Python 2. It's getting better all the time though. Most of the effort is because of a local Mac OS development environment, legacy Debian Wheezy systems that are hard to replace, but also legacy Ubuntu systems that are hard to replace.
- cuu508 10y ago
  On 1st point, yes, you need Python 2 for Ansible (and Fabric) but it lives nicely side by side with Python 3, so your apps–the not-legacy ones at least–can use Python 3 no problem. I think about Python 2 as Ansible's dependency, not something I have to use because it's there.
- AdamN 10y ago
  We use Ansible (system 2.7) but our code is written in 3.5. I'm not sure what you're talking about since never the twain shall meet. It's BAD to use the system Python for any of your internal production code (use a virtualenv!).
spdy 10y ago
From my personal opinion just porting a project from 2->3 we will get there. Python 3.6 offers to much to let is pass. Ecosystem has moved far enough its just a matter of time when big frameworks etc. deprecate python 2.7 and this mostly happen around the real EOL of it.
vuanotino 10y ago
The only thing I haven't liked when comparing 2 to 3, is how 3 is even slower. CPython is so slow, they really should start taking performance more seriously.
- majewsky 10y ago
  Taking a guess here: Maybe all the people who are concerned about performance have moved to PyPy?
  - vuanotino 10y ago
    They don't support 3 :(
    - majewsky 10y ago
      What, PyPy? Their homepage states 3.3.5 compatibility: http://pypy.org/ http://pypy.org/
      - vuanotino 10y ago
        Oh, I am sure they didn't last time I checked. Thank you.
      - xapata 10y ago
        And they're skipping 3.4 going straight to 3.5
  - xapata 10y ago
    That or using NumPy for any arithmetic bottlenecks. But the new dict and a few other optimizations in 3.6 will make attribute lookups pretty close to C++ speed if not the same.
verytrivial 10y ago
Interesting data-point, but what is the trend? We already know 2.7 is a victim of its own success, right?
danielsamuels 10y ago
Where I work we're just waiting on Ansible. Everything else we write and use works with Python 3, except the tool we use to deploy it all. Frustrating.
- randlet 10y ago
  Why not use both? I'm shipping python 3 software using Ansible and it works great.
  - danielsamuels 10y ago
    Using version 2.2?
    - AdamN 10y ago
      Ansible is just a program - I'm not sure where the confusion lies. You can use Chef (Ruby) to deploy Python apps after all ... the version of Python used by Ansible is totally irrelevant to the interpreter you use for your codebase.
      - danielsamuels 10y ago
        As far as I remember, if your local virtual environment is Python 3 Ansible doesn't work (might not even install).
        randlet 10y ago
        Just like neokya said, you just create a Python 2 virtualenv for deployment and a Python 3 one for development.
        neokya 10y ago
        well, you can install ansible outside local virtualenv. It's a single program like Firefox, so probably you won't need different versions and could be installed as such.
est 10y ago
Python really should learn from PHP7. Yes, it breaks a lot of things, but it's totally worth it for the performance gains. Py3k solves problems partially like Unicode or async/await but it's a non-issue for skilled python2 developers. People like incentives to upgrade. Period.
- eeZi 10y ago
  Lots of incentives for us: - clean Unicode support which prevents mistakes which used to bite us in production - native async syntax, compatible with Tornado - asynchronous generators (yield from a coroutine!) - pathlib and os.scandir - type annotations - matrix multiplication - chained exceptions - faster dicts, ordered by default So many useful features, and with the latest Python 3 releases porting has become really easy thanks to improved compatibility with the old syntax.
  - icegreentea 10y ago
    They are all pluses, but most of those didn't exist till the last couple years. So effectively the first 6 or so years of Python 3 existing had much less incentive. I think the flip around - ~30% adoption of a newest version at 1-2 years in - especially one that breaks backwards compatibility isn't bad. I've started numerous python projects at work over the last year all on 2.7. I think we just started the last one. We're finally ready to jump to 3.
    - dr_zoidberg 10y ago
      Indeed, and ordered dicts come from Py 3.6, which is in beta now and expected for December. If async and this had been in Py3 from the start, they could've done a far better argument saying "hey, we broke all this stuff, but you get asyinc I/O and faster dicts" (a note of faster dicts: since many classes and language mechanisms use dicts, it should have an encompassing effect on all of python performance -- maybe not 30% or 40% faster, but a few % all around, which is kind of what micro benchmarks are showing with 3.6 betas)
  - est 10y ago
TheAceOfHearts 10y ago
I don't follow the Python community closely, so I might be totally off the mark here, but my general impression is that it was shipped prematurely. From what I've read, in more recent years a lot of work has gone into easing the transition... But it seems a bit late. As an outside I wonder: did they fail to put in a reasonable effort at all in providing a smooth transition from the start, or did they try and failed to account to the realities of our world? Recklessly breaking backwards compatibility without a smooth migration plan is hostile to developers. Although it's not a programming language, this is something that I think React has gotten right with their current versioning scheme [0]. [0] https://facebook.github.io/react/blog/2016/02/19/new-versioning-scheme.html https://facebook.github.io/react/blog/2016/02/19/new-version...
- xapata 10y ago
  There's a smooth upgrade path via importing from `__future__`, but that doesn't help if you've been ignoring non-text data in your strings. The automatic 2to3 translators don't know what de/encoding you want to use. Upgrading to 3 doesn't cause bugs, it reveals bugs that many people would rather brush under the rug.
- ubernostrum 10y ago
  Python 3 was shipped with the expectation that the migration would be long. Python 3.0 was the proof-of-concept release, basically, and it wasn't really until 3.3 that momentum started picking up around porting. 3.5 and soon 3.6 are beginning to offer large, attractive new features people want and can't get on 2.7, which further incentivizes the move. But in order to make it happen, and to provide the long lead time for migration, 3.0 had to get out the door when it did. So it wasn't "premature".
knlje 10y ago
My colleagues at academia (scientific computing) mostly default to Python 2. Personally I'll switch to Python 3 when approximately over 50% of my colleagues use it or when some mind blowing new feature or library is introduced only for Python 3. Makes things simpler this way. Also, I don't currently have enough spare time to port all my code.
- rglullis 10y ago
  Don't be so scared of porting your code. On my current work, we have a few thousand lines of python (spanning different services and supporting libraries) throughout in ~18 months and we were blocked by pika (a module for communication with AMQP servers). When pika got a python3 compatible version, we ran out of excuses to not use python3, but still my colleague was worried that "it would take too long to port things, and our-code-is-working-so-why-bother". I decided to try it anyway, and it took me less than a lazy Friday afternoon to run 2to3 on all the packages and get the tests to pass. Given that your work is with scientific computing and (presumably?) you have control over the deployment environments, I'd really recommend that you avoid do the switch sooner than later.
  - eeZi 10y ago
    Can confirm. Ported our internal stuff and it was much easier and faster than expected.
  - dr_zoidberg 10y ago
    > Don't be so scared of porting your code. I stuck with that line, because maybe his colleagues are also waiting for "50% of colleagues using Py3" and it's just a deadlock until some few brave enough starts to port and tip the balance.
- scaryclam 10y ago
  I find this really surprising as all of the scientific libraries that I know about support python 3. Python 3 also has a load of improvements that would make scientific programming faster. Perhaps instead of thinking about not having spare time to port your code, that you're saving time for future you by not creating more work to port over when you end up really needing that mind blowing new library :)
joobus 10y ago
My office has moved new projects to Go. We were using twisted web server which still isn't p3 compatible. It also doesn't help that Python is basically single-threaded.
- xapata 10y ago
  Stop spreading misinformation. Python is fine for multithreading despite the GIL. It's simply that there's no free lunch -- no one strategy for parallelism is best for all programs.
ntoll 10y ago
Python 3 is the default teaching language for the RaspberryPi. The BBC micro:bit runs MicroPython - a reimplementation of Python 3 for microcontrollers. Teachers and kids are already ahead of the game. When today's kids graduate they'll view Python2.7 in perhaps the same way I view Delphi or VB6 ("you're still using that..?" etc,).
- mavhc 10y ago
  And then Codecademy go and use Python 2, sigh
drej 10y ago
Coming from a country with an extended alphabet, I've always been aware of encoding issues, especially before almost everyone settled on using UTF. So the treatment in Python 3 (and equally in Go) is a game changer for me and many other language users out there. I'm not saying that, say, American developers don't need to support other alphabets, just that it's less pressing since they don't tend to deal with them on a daily basis. So for this feature alone, I'm all in on Python 3.
denfromufa 10y ago
Sentry is also still Python 2.7, thanks to Armin and his friends: https://github.com/getsentry/sentry/issues/1152 https://github.com/getsentry/sentry/issues/1152
- chuamo 10y ago
  looks to me they have maybe changed their stance? See commits. https://github.com/getsentry/sentry/tree/master/src/sentry/middleware https://github.com/getsentry/sentry/tree/master/src/sentry/m...
vasco 10y ago
Users generally update by default, if thousands upon thousands didn't it's because someone else fucked up. I find it funny how a small group of people thinks they know better than the outer community, to the point that they feel like they should have a say in what thousands of businesses use to run successful code. More than this, I would argue that most people using Python 3 are those new to the language. This is only from personal experience, so it's really just anecdote. PS: In a kind of jesty side-note, I know the general argument is that "python 2 was broken", but really, how broken can something be when thousands of businesses depend on it and more than that, choose to keep using it when a "better" alternative comes about?
- rgacote 10y ago
  My company has been writing a significant portion of their commercial code in Python since version 1.5 and (almost) everything new in Python 3.5.
perlin 10y ago
Anecdotally, we had a simple events API running Python 2.7/Flask/uwsgi/nginx that needed to do quick I/O operations on a growing # of HTTP requests. To increase throughout, we experimented with Python 3 for its async/await style concurrency. It didn't seem to help much and we ended up just rewriting that API in Go and see way better throughout-to-resource ratios by shipping 5mb binaries to Docker & Kubernetes. Point is, we're a hybrid shop that does all first pass services in Python 2.7 and then move them to Go when they become suffiently trafficked and/or critical.
swalsh 10y ago
I've recently started using python a lot more, it was a natural progression when I moved from using a windows dev machine to a mac book. One day I needed to do something quick, and python was the quickest way to do it. I typed python into my terminal, saw 2.7, and built from that. I had no incentive to look into upgrading, I had everything I needed to accomplish what I wanted. My good experience then has grown to the point where it's probably the second most common tool in my toolbag, but it's still an "I need to do xyz, and I don't care how it looks I just want to see if this will work". So I still stick with the defaults. I only think about using the latest greatest tools if I think the code I'm writing has long term potential.
fdgdasfadsf 10y ago
Python2 is stable. This is actually a major advantage in some applications.
upofadown 10y ago
As languages go, Python 3 is pretty successful. It unfortunately shares a name with the language it is a variant of so people tend to compare the popularity of the two. The popularity of Python 3 should be judged against all similar languages, not just the insanely popular Python 2.
makecheck 10y ago
I’m not sure why but the Mac has not installed a "/usr/bin/python3" so I continue to avoid 3.x migration (aside from minor things like "__future__" imports for division and print_function). I don’t want to add a dependency for end users when my current code works fine with the built-in Python at 2.x. Nor do I want to bloat the size of downloads to embed something like an entire interpreter binary. (Swift has the same issue; there is currently no way to refer to it externally, as it is in flux; I do not want to embed loads of Swift libraries in every build so I will wait to migrate until they have stabilized binaries and made them available from a common root.)
fermigier 10y ago
How do they define "commercial" ? How do they define "new" ?
cakeface 10y ago
Is python's upgrade difficulties from 2.7 to 3.x due to being interpreted rather than compiled? I feel like the types of problems seen in a non compatible upgrade are exactly what I consider easy problems in Java. Look for the compilation issues, fix them, done. In Java I am largely talking about library upgrade issues because Java made the decision to remain language backwards compatible. Something that has it's costs but also some real benefits. See Linux and it's promises to never break user space.

160 points by markoa 10y ago

Python 3 is omnipresent in my work right now and it is so nice not to have to worry about, for example, unicode issues. The only thing I'm dealing with which is still not Python 3 compatible is AWS Lambda, which only offers 2.7 right now. Supposedly Amazon is working on 3.x but... come on.

2T1Qka0rEiPr 10y ago
Python 3 doesn't remove unicode issues, although granted you probably run into fewer issues when defaulting to unicode over a bytestring.
- vuanotino 10y ago
  It doesn't? I've ran into UnicodeDecodeError exceptions literally every time I've had to deal with external input in Python 2. It was a nightmare, and it made me hate Python. With Python 3, that simply has never happened to me. Never. I don't know why. I don't know what the change, what the secret sauce was. And what's even better: I don't have to care. Python now simply works for me. So yes, Python did remove Unicode issues.
- doppel 10y ago
  Because unicode is default and the byte-type is single-byte adressable (rather than 1 character in <encoding>) it makes it more straightforward. It's not perfect, but it helps a lot.
- sevensor 10y ago
  Python 3 doesn't remove all unicode issues, it's not magic. But the pain is 95% gone compared with Python 2. I write Python for a living, and my life has been a lot better since we switched.
tyfon 10y ago
Same at my place, 2.x is banned for all purposes.
- brianwawok 10y ago
  Ansible only works with 2.x, so that is perhaps the only exception I would make... (if you are an ansible shop). But ansible scripts tend to be like 5 lines, so it is not the same as the scale you would write a webapp or something in Python3...
  - eeZi 10y ago
    For Ansible, it's important to differentiate between the master and client side code. Client side code has to run on everything starting with CentOS 6, so they have to stick with Python 2 for a long time. For the Ansible master (which runs on the management machine), Python 3 porting work is already underway.
  - AdamN 10y ago
    We're a Python shop but all of our Ansible work is just YAML. Ansible is a program more than a library so it's almost irrelevant what version of Python they use. Now, of course it's highly annoying to have to bootstrap python2 on Ubuntu Xenial but that's really not relevant to what version of Python a group uses for regular development. We use Python 3.5 and are VERY happy about it.
eeZi 10y ago
Same here. Haven't had a single Unicode bug in production since we switched to Python 3. Also, chained exceptions (extremely valuable in walled-off production environment). Type annotations actually work and have prevented a number of bugs. The asyncio syntax is really nice with Tornado (don't use aiohtto, use Tornado! it's much more mature)
moduspwnens14 10y ago
Came here to say this. I've default to Python 3 for all new projects (our new stuff is primarily on Ubuntu 16.04 anyway), but we use AWS Lambda a lot and it's still stuck at 2.7 for now.
pmontra 10y ago
They're also only Node 4.3.2. It seems that they need quite a while to test new versions, or they have little man power and are constrained to keep working with what they know it worked.
msl09 10y ago
I'm slightly moving backwards. Previously I just make Python 3 scripts with 0% retrocompatibility because I thought that Python 3 was going to happen soon and it was futile to try to resist. Now that my programs and scripts are getting used more frequently at work and outside of work I'm making more Python 2-3 compatible code because often people just try to use python myscript.py (that might just call any interpreter), or they use myscript.py in an development environment that only uses Python 2. It's a bit sad to not be able to use some things that I really love about Python 3 but it makes me happier to see other people enjoying my work, so I'm going to bear with it for now.
rgacote 10y ago
The only time we're writing new Python 2.7 code is when we're working with Twisted (and they are vigorously migrating to Python 3). All other new code is Python 3.5 based and we're not looking back at all. Using asyncio has been a delight for a lot of the small, quick web services we need to write (though not a replacement for Twisted). Looking forward to seeing the asyncio infrastructure grow.

binarymax 10y ago

I blame in part, that the default install for OS's like Ubuntu and Mac is Python 2.7. If you are starting python development, and want to support more systems, and you know the default is 2.7, then that's what you will target.

teekert 10y ago
Python 3 is the default in 16.04 LTS.
- deleted 10y ago
  [deleted]
- 2T1Qka0rEiPr 10y ago
  I just posted that my default Python is 2 and I'm on 16.04.1, but I suppose the upgrade from 15.10 perhaps left the default as-is?
  - teekert 10y ago
    I think the fact that python points to python 2 and python3 points to python 3 does not mean one is default and the other is not. One would think so, yes, but this is a bit of difficult case, for historic reasons. Both versions will need to be present because many things depend on 2 still (ufw for one I believe), python 2 was just there first and hence earned the badge "python". To now switch to explicitly calling it python2 and calling python 3 python would break many things probably. On a clean 16.04 install, python 3 is present, python 2 is not, however, you still need to call python 3 with "python3" [0] [0] https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#Python_3 https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#Python_3 Edit: See qznc's remark on the pep, apparently it's even advised the keep "python" pointing to python 2.
  - dagw 10y ago
    I suppose the upgrade from 15.10 perhaps left the default as-is? Yes. If you do a clean install of 16.04 then you won't python2 installed at all.
- 10y ago

noir_lord 10y ago

http://i.imgur.com/EJM1viF.png http://i.imgur.com/EJM1viF.png That's why Python 2.7 will be around and maintain dominance for a while. When the latest stable releases of the primary environments are defaulting to something you have to have very good reasons why not to use the default (even when it's easy to change the default). Administrators (in the old school not the new "everything in containers") don't like using non-defaults.

berntb 10y ago
Hmm... you really use the system Python installation for development? Python is not pathologically backwards compatible, what happens when the next OS version use a newer Python 2 version?
- noir_lord 10y ago
  Personally? I don't, I use Python 3 and virtualenvs but then everything I write in Python is for myself to do things for me. If I was writing software that had to be used in as many places as possible or sold, I'd absolutely strongly consider using 2.7.
- cuu508 10y ago
  You don't simply upgrade your production machines to the next OS version with fingers crossed. You do some testing and validation first. Say, you use containers and so your application is isolated from the host system. When the next version of your host system comes with a new version of Docker, you have to do similar testing and validation anyway.
juriansluiman 10y ago
Afaik, it has nothing to do with Ubuntu or any other Linux distro specifically, but this is rather a choice from python itself. See PEP394 [1]: "for the time being, all distributions should ensure that python refers to the same target as python2." I read above as the python community itself made "python" the default for python 2.7 and "python3" for python 3.x. Nevertheless, an unfortunate choice at this time. I understand the reasoning at the time of writing (March 2011) but now this should be reconsidered. [1] https://www.python.org/dev/peps/pep-0394/

lovelearning 10y ago

Title should be changed to "Python Versions Used in Commercial Projects, 2016 Edition". The data pertains only to Semaphore's commercial CI customers.

dr_zoidberg 10y ago

Wouldn't call 28% "largely ignored", rather "still lagging behind". Thing is, 3.6 looks like the real deal breaker here, what Python 3.0 should've been. With asyncio, compact dicts and scandir I've gotten to the point where I can almost justify to my employer why, if everything is still working, we should move to Python 3.6 ("all will be faster" -- I know I'm kind oversimplifying here, but my boss pretty much doesn't understand software and just wants results/money). There's also the sentiment of "I don't know if [insert module here] will be supported", which has become mostly baseless fear, but people still think Py3 support is lacking (when it's not![0]). [0] https://python3wos.appspot.com/ https://python3wos.appspot.com/ -- also, take notice how 9 of this guys come from here [1] [1] http://mozbase.readthedocs.io/en/latest/ http://mozbase.readthedocs.io/en/latest/ Edit: when I posted this comment, the link was titled "Python 3 largely ignored" (not the article per se, but the submitted link had been titled that way). It has been changed, but this was a bit of important context for my comment.

Siecje 10y ago
I'm still waiting for supervisor, beanstalkc, and cloudsigma.
- AdamN 10y ago
  Not sure why supervisor matters, it's just a program. It's the same thing as Homebrew running Ruby - totally doesn't matter what version they're using.
  - mi100hael 10y ago
    It does if you're using their API
- dr_zoidberg 10y ago
  Of course, specific projects might not be covered, but I've seen a lot of people go "ok, just to be safe I'll use 2.7 in case down the road I get to need anything that's Py2 specific". In your case you know exactly what your needs are, and that they're unsupported in Python 3, but I'm sure that many of those 70% Py2 projects could run just as well in Py3.

d_theorist 10y ago

I'm actually surprised (pleasantly) to see that adoption is that high. I would have guessed at less than 10%. I suppose the sample set (projects using a tool like Semaphore) is likely to be biased towards more forwards-looking teams, but still.

rlpb 10y ago

Commercial projects are the laggards. I'd expect them to be the last to move over. More interesting I think is the progress in distributions. This matters because commercial projects use distributions too, and will need to follow them in the end.

lmm 10y ago

Flamebait title, and doesn't match the article. 30% adoption, while not exactly a big success, is nothing to sniff at.

w8rbt 10y ago

I think this shows just how good Python 2 is ;)

pjc50 10y ago

Let this (and Perl 6) be a lesson to language designers: do not make backward-incompatible changes, ever. It cripples adoption. Java managed this much better by being able to mark APIs as "deprecated".

berntb 10y ago
You got a point I agree with but a bad example since Perl 6 is a new language. (That the name don't reflect that is still a heated discussion.) (And Perl 5 code can declare which of the newer features it will support. Excellent backwards compatibility.)
dri_ft 10y ago
Then again, continuing to add backward-compatible changes to Perl 5 would have made it an even bigger pile of mud than it already is. Its refusal to make backward-incompatible changes is both the reason why Perl 5 was so ubiquitous and why it's so very ugly. So I can certainly understand the desire to start afresh with 6, in spite of the costs in terms of adoption. It does seem like take-up has been low so far, but it's probably still too early to call whether it will turn out to have been the right choice. I'm less familiar with Python, so can't really comment on there, but it does seem that Python 2.7 had fewer egregious faults than Perl 5.
- berntb 10y ago
  There are quite a few backwards incompatible extensions for Perl 5. But you must declare what new features to use. Then there is Devel::Declare etc with extensible syntax... :-) http://perldoc.perl.org/feature.html http://perldoc.perl.org/feature.html
moduspwnens14 10y ago
I think the main change (accurate handling of strings potentially encoded with multiple bytes) hit a lot of languages from that time in bad ways. I think it's something that more or less had to be done since the alternatives are worse, but we haven't seen a similar issue pop up in a long time. I don't think the lesson applies in many other places. Certainly open to my mind being changed, though!

wtbob 10y ago

Former Python developer here. The problem was two-fold: Python 3 broke backwards- and forward-compatibility (in a practical sense: there were workarounds, but libraries didn't necessarily use 'em, and Python is nothing if not a glue language); and for the longest time there really wasn't a good reason to switch. I think it wasn't until last year that it really started to make sense to go with Python 3 — and by then I'd already switched to Go.

mherrmann 10y ago
Python and Go aren't really mutually exclusive though. Some things will better be done in Python, others in Go.
- rgacote 10y ago
  Tried go and fairly quickly headed back to Python. Kept running into annoyances that slowed development. Not being able to get a NULL back from a database without a third-party library was the final straw (go 1.5, might have changed since then). I understand there's obvious use cases for Go, but an amazing amount of what we do is taking data from place 'A' (web, socket, file), sending it to place 'B' (another web, socket, file), and then returning a result. Go doesn't buy you much that asyncio won't.
  - wtbob 10y ago
    > I understand there's obvious use cases for Go, but an amazing amount of what we do is taking data from place 'A' (web, socket, file), sending it to place 'B' (another web, socket, file), and then returning a result. Go doesn't buy you much that asyncio won't. Static typing. Oh Lord is it nice. When I wrote Python, I never quite knew if there'd be a runtime error (in my code or a library). With Go, there are a lot fewer of those.
    - y4mi 10y ago
      static typing has become possible with python3, though i don't use it for my personal projects.

rtpg 10y ago

this headline is a bit much. 1/3rd of new projects use Python 3! A lot of people are excited about the language now that a lot of the warts have been dealt with and language compat is higher than ever. Though all it takes is one dependency to throw a wrench in the plans, the major projects are Py3 now. Though porting large python 2 projects is still a huuuuuge pain. This is more a result of python 2 badness than python 3. But a lot of work.

sixhobbits 10y ago

Maybe unjustified, but I'm always kind of suspicious of a post which is largely focused on raw data (like this one) and which presents only pie-chart visualsations [0]. Yes, Python has a pretty dirty history, with many people choosing to stick to the Python 2.7 that they knew and loved. And yes, commercial software tends to move waaay slower than the wider community (many banks are still running COBOL). If you're focused on making money and pleasing clients then "it worked for us before" is always going to be the strongest argument. Major players in the Python eco system have pledged to move away from Python 2 [1], and if we had non pie-chart visualisations, I'm sure we'd see huge trends towards Python 3 in the last year. Even slow-moving corporations are starting to use Python3. Yes, MacOS defaulting to Python2 is still a problem, but Ubuntu switching to default Python3 is already a huge step to get companies to move forwards. [0] http://www.businessinsider.com/pie-charts-are-the-worst-2013-6 http://www.businessinsider.com/pie-charts-are-the-worst-2013... [1] https://python3statement.github.io/ https://python3statement.github.io/

qznc 10y ago
Do not underestimate COBOL. The latest version is from 2014. https://en.wikipedia.org/wiki/COBOL#COBOL_2014 https://en.wikipedia.org/wiki/COBOL#COBOL_2014
- 1wd 10y ago
  How many commercial projects use COBOL 2014 though? I know Fortran 77 is still considered newfangled in some circles, even though Fortran 90, 95, 2003, 2008, 2015 exist. Same with C90, C++98, etc.
  - zcdziura 10y ago
    Net-new COBOL code is being written every day in the Enterprise world. I work on a team that's actively updating and maintaining a large COBOL codebase. The default standard that most people write to is COBOL-85. Just because the language is old doesn't mean that it can't be the right tool for the right job. For batch processing-type tasks, there nothing better than COBOL on the mainframe. By default, COBOL doesn't allow for you to dynamically allocate memory. That makes it incredibly easy for the compiler and system to optimize the compiled code and make it run super fast. COBOL is great for what it was designed for: processing data. If you want to read data from a file/database, process it in some way, and then save that data back to the database/another file, you can't do much better than what COBOL offers.

Siecje 10y ago

What would a project that supports both Python2 and Python3 show up as in these charts? How many of the projects support both?

someguydave 10y ago

I'm glad that python 2 is unpopular with cool kids. Otherwise they might be inserting broken feature every minor revision.

bdg 10y ago

Of course it is. Python is full of language snobs who insist their language is beautiful and the quality is great. They insist there's no reason to change, except for some reason, to go.

INTPenis 10y ago

I expend considerable effort that I am not obliged to expend to use Python 3 whenever possible. I'm sure that I'm not unique. Right now in my life the major things stopping me from using python 3 for all the things are. * Ansible * Two large in-house developed apps taken over from previous devs * Debian Wheezy And as you can guess, at least one of those will hopefully disappear soon. Other than that I try to use python 3 as much as possible. I know a lot of the workaround for getting pyvenv working on various distros for example. I also know about a lot of alternative libs like ldap3, dnspython3 and more.

taneq 10y ago
> I expend considerable effort that I am not obliged to expend to use Python 3 whenever possible. Isn't that kind of a bad sign, though? Should it really require 'considerable effort' to use the latest release of a fairly widely adopted language?
- INTPenis 10y ago
  It's a good sign in the sense that people want to move forward. But yes, it's a bad sign in the sense that more effort is required than with Python 2. It's getting better all the time though. Most of the effort is because of a local Mac OS development environment, legacy Debian Wheezy systems that are hard to replace, but also legacy Ubuntu systems that are hard to replace.
cuu508 10y ago
On 1st point, yes, you need Python 2 for Ansible (and Fabric) but it lives nicely side by side with Python 3, so your apps–the not-legacy ones at least–can use Python 3 no problem. I think about Python 2 as Ansible's dependency, not something I have to use because it's there.
AdamN 10y ago
We use Ansible (system 2.7) but our code is written in 3.5. I'm not sure what you're talking about since never the twain shall meet. It's BAD to use the system Python for any of your internal production code (use a virtualenv!).

spdy 10y ago

From my personal opinion just porting a project from 2->3 we will get there. Python 3.6 offers to much to let is pass. Ecosystem has moved far enough its just a matter of time when big frameworks etc. deprecate python 2.7 and this mostly happen around the real EOL of it.

vuanotino 10y ago

The only thing I haven't liked when comparing 2 to 3, is how 3 is even slower. CPython is so slow, they really should start taking performance more seriously.

majewsky 10y ago
Taking a guess here: Maybe all the people who are concerned about performance have moved to PyPy?
- vuanotino 10y ago
  They don't support 3 :(
  - majewsky 10y ago
    What, PyPy? Their homepage states 3.3.5 compatibility: http://pypy.org/ http://pypy.org/
    - vuanotino 10y ago
      Oh, I am sure they didn't last time I checked. Thank you.
    - xapata 10y ago
      And they're skipping 3.4 going straight to 3.5
- xapata 10y ago
  That or using NumPy for any arithmetic bottlenecks. But the new dict and a few other optimizations in 3.6 will make attribute lookups pretty close to C++ speed if not the same.

verytrivial 10y ago

Interesting data-point, but what is the trend? We already know 2.7 is a victim of its own success, right?

danielsamuels 10y ago

Where I work we're just waiting on Ansible. Everything else we write and use works with Python 3, except the tool we use to deploy it all. Frustrating.

randlet 10y ago
Why not use both? I'm shipping python 3 software using Ansible and it works great.
- danielsamuels 10y ago
  Using version 2.2?
  - AdamN 10y ago
    Ansible is just a program - I'm not sure where the confusion lies. You can use Chef (Ruby) to deploy Python apps after all ... the version of Python used by Ansible is totally irrelevant to the interpreter you use for your codebase.
    - danielsamuels 10y ago
      As far as I remember, if your local virtual environment is Python 3 Ansible doesn't work (might not even install).
      - randlet 10y ago
        Just like neokya said, you just create a Python 2 virtualenv for deployment and a Python 3 one for development.
      - neokya 10y ago
        well, you can install ansible outside local virtualenv. It's a single program like Firefox, so probably you won't need different versions and could be installed as such.

est 10y ago

Python really should learn from PHP7. Yes, it breaks a lot of things, but it's totally worth it for the performance gains. Py3k solves problems partially like Unicode or async/await but it's a non-issue for skilled python2 developers. People like incentives to upgrade. Period.

eeZi 10y ago
Lots of incentives for us: - clean Unicode support which prevents mistakes which used to bite us in production - native async syntax, compatible with Tornado - asynchronous generators (yield from a coroutine!) - pathlib and os.scandir - type annotations - matrix multiplication - chained exceptions - faster dicts, ordered by default So many useful features, and with the latest Python 3 releases porting has become really easy thanks to improved compatibility with the old syntax.
- icegreentea 10y ago
  They are all pluses, but most of those didn't exist till the last couple years. So effectively the first 6 or so years of Python 3 existing had much less incentive. I think the flip around - ~30% adoption of a newest version at 1-2 years in - especially one that breaks backwards compatibility isn't bad. I've started numerous python projects at work over the last year all on 2.7. I think we just started the last one. We're finally ready to jump to 3.
  - dr_zoidberg 10y ago
    Indeed, and ordered dicts come from Py 3.6, which is in beta now and expected for December. If async and this had been in Py3 from the start, they could've done a far better argument saying "hey, we broke all this stuff, but you get asyinc I/O and faster dicts" (a note of faster dicts: since many classes and language mechanisms use dicts, it should have an encompassing effect on all of python performance -- maybe not 30% or 40% faster, but a few % all around, which is kind of what micro benchmarks are showing with 3.6 betas)
- est 10y ago

TheAceOfHearts 10y ago

I don't follow the Python community closely, so I might be totally off the mark here, but my general impression is that it was shipped prematurely. From what I've read, in more recent years a lot of work has gone into easing the transition... But it seems a bit late. As an outside I wonder: did they fail to put in a reasonable effort at all in providing a smooth transition from the start, or did they try and failed to account to the realities of our world? Recklessly breaking backwards compatibility without a smooth migration plan is hostile to developers. Although it's not a programming language, this is something that I think React has gotten right with their current versioning scheme [0]. [0] https://facebook.github.io/react/blog/2016/02/19/new-versioning-scheme.html https://facebook.github.io/react/blog/2016/02/19/new-version...

xapata 10y ago
There's a smooth upgrade path via importing from `__future__`, but that doesn't help if you've been ignoring non-text data in your strings. The automatic 2to3 translators don't know what de/encoding you want to use. Upgrading to 3 doesn't cause bugs, it reveals bugs that many people would rather brush under the rug.
ubernostrum 10y ago
Python 3 was shipped with the expectation that the migration would be long. Python 3.0 was the proof-of-concept release, basically, and it wasn't really until 3.3 that momentum started picking up around porting. 3.5 and soon 3.6 are beginning to offer large, attractive new features people want and can't get on 2.7, which further incentivizes the move. But in order to make it happen, and to provide the long lead time for migration, 3.0 had to get out the door when it did. So it wasn't "premature".

knlje 10y ago

My colleagues at academia (scientific computing) mostly default to Python 2. Personally I'll switch to Python 3 when approximately over 50% of my colleagues use it or when some mind blowing new feature or library is introduced only for Python 3. Makes things simpler this way. Also, I don't currently have enough spare time to port all my code.

rglullis 10y ago
Don't be so scared of porting your code. On my current work, we have a few thousand lines of python (spanning different services and supporting libraries) throughout in ~18 months and we were blocked by pika (a module for communication with AMQP servers). When pika got a python3 compatible version, we ran out of excuses to not use python3, but still my colleague was worried that "it would take too long to port things, and our-code-is-working-so-why-bother". I decided to try it anyway, and it took me less than a lazy Friday afternoon to run 2to3 on all the packages and get the tests to pass. Given that your work is with scientific computing and (presumably?) you have control over the deployment environments, I'd really recommend that you avoid do the switch sooner than later.
- eeZi 10y ago
  Can confirm. Ported our internal stuff and it was much easier and faster than expected.
- dr_zoidberg 10y ago
  > Don't be so scared of porting your code. I stuck with that line, because maybe his colleagues are also waiting for "50% of colleagues using Py3" and it's just a deadlock until some few brave enough starts to port and tip the balance.
scaryclam 10y ago
I find this really surprising as all of the scientific libraries that I know about support python 3. Python 3 also has a load of improvements that would make scientific programming faster. Perhaps instead of thinking about not having spare time to port your code, that you're saving time for future you by not creating more work to port over when you end up really needing that mind blowing new library :)

joobus 10y ago

My office has moved new projects to Go. We were using twisted web server which still isn't p3 compatible. It also doesn't help that Python is basically single-threaded.

xapata 10y ago
Stop spreading misinformation. Python is fine for multithreading despite the GIL. It's simply that there's no free lunch -- no one strategy for parallelism is best for all programs.

ntoll 10y ago

Python 3 is the default teaching language for the RaspberryPi. The BBC micro:bit runs MicroPython - a reimplementation of Python 3 for microcontrollers. Teachers and kids are already ahead of the game. When today's kids graduate they'll view Python2.7 in perhaps the same way I view Delphi or VB6 ("you're still using that..?" etc,).

mavhc 10y ago
And then Codecademy go and use Python 2, sigh

drej 10y ago

Coming from a country with an extended alphabet, I've always been aware of encoding issues, especially before almost everyone settled on using UTF. So the treatment in Python 3 (and equally in Go) is a game changer for me and many other language users out there. I'm not saying that, say, American developers don't need to support other alphabets, just that it's less pressing since they don't tend to deal with them on a daily basis. So for this feature alone, I'm all in on Python 3.

denfromufa 10y ago

Sentry is also still Python 2.7, thanks to Armin and his friends: https://github.com/getsentry/sentry/issues/1152 https://github.com/getsentry/sentry/issues/1152

chuamo 10y ago
looks to me they have maybe changed their stance? See commits. https://github.com/getsentry/sentry/tree/master/src/sentry/middleware https://github.com/getsentry/sentry/tree/master/src/sentry/m...

vasco 10y ago

Users generally update by default, if thousands upon thousands didn't it's because someone else fucked up. I find it funny how a small group of people thinks they know better than the outer community, to the point that they feel like they should have a say in what thousands of businesses use to run successful code. More than this, I would argue that most people using Python 3 are those new to the language. This is only from personal experience, so it's really just anecdote. PS: In a kind of jesty side-note, I know the general argument is that "python 2 was broken", but really, how broken can something be when thousands of businesses depend on it and more than that, choose to keep using it when a "better" alternative comes about?

rgacote 10y ago
My company has been writing a significant portion of their commercial code in Python since version 1.5 and (almost) everything new in Python 3.5.

perlin 10y ago

Anecdotally, we had a simple events API running Python 2.7/Flask/uwsgi/nginx that needed to do quick I/O operations on a growing # of HTTP requests. To increase throughout, we experimented with Python 3 for its async/await style concurrency. It didn't seem to help much and we ended up just rewriting that API in Go and see way better throughout-to-resource ratios by shipping 5mb binaries to Docker & Kubernetes. Point is, we're a hybrid shop that does all first pass services in Python 2.7 and then move them to Go when they become suffiently trafficked and/or critical.

swalsh 10y ago

I've recently started using python a lot more, it was a natural progression when I moved from using a windows dev machine to a mac book. One day I needed to do something quick, and python was the quickest way to do it. I typed python into my terminal, saw 2.7, and built from that. I had no incentive to look into upgrading, I had everything I needed to accomplish what I wanted. My good experience then has grown to the point where it's probably the second most common tool in my toolbag, but it's still an "I need to do xyz, and I don't care how it looks I just want to see if this will work". So I still stick with the defaults. I only think about using the latest greatest tools if I think the code I'm writing has long term potential.

fdgdasfadsf 10y ago

Python2 is stable. This is actually a major advantage in some applications.

upofadown 10y ago

As languages go, Python 3 is pretty successful. It unfortunately shares a name with the language it is a variant of so people tend to compare the popularity of the two. The popularity of Python 3 should be judged against all similar languages, not just the insanely popular Python 2.

makecheck 10y ago

I’m not sure why but the Mac has not installed a "/usr/bin/python3" so I continue to avoid 3.x migration (aside from minor things like "__future__" imports for division and print_function). I don’t want to add a dependency for end users when my current code works fine with the built-in Python at 2.x. Nor do I want to bloat the size of downloads to embed something like an entire interpreter binary. (Swift has the same issue; there is currently no way to refer to it externally, as it is in flux; I do not want to embed loads of Swift libraries in every build so I will wait to migrate until they have stabilized binaries and made them available from a common root.)

fermigier 10y ago

How do they define "commercial" ? How do they define "new" ?

cakeface 10y ago

Is python's upgrade difficulties from 2.7 to 3.x due to being interpreted rather than compiled? I feel like the types of problems seen in a non compatible upgrade are exactly what I consider easy problems in Java. Look for the compilation issues, fix them, done. In Java I am largely talking about library upgrade issues because Java made the decision to remain language backwards compatible. Something that has it's costs but also some real benefits. See Linux and it's promises to never break user space.