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].<p>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.<p>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.<p>[0] <a href="http://www.businessinsider.com/pie-charts-are-the-worst-2013-6" rel="nofollow">http://www.businessinsider.com/pie-charts-are-the-worst-2013...</a><p>[1] <a href="https://python3statement.github.io/" rel="nofollow">https://python3statement.github.io/</a>
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).<p>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]).<p>[0] <a href="https://python3wos.appspot.com/" rel="nofollow">https://python3wos.appspot.com/</a> -- also, take notice how 9 of this guys come from here [1]<p>[1] <a href="http://mozbase.readthedocs.io/en/latest/" rel="nofollow">http://mozbase.readthedocs.io/en/latest/</a><p>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.
Python 3 is omnipresent in my work right now and it is so nice not to have to worry about, for example, unicode issues.<p>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.
<a href="http://i.imgur.com/EJM1viF.png" rel="nofollow">http://i.imgur.com/EJM1viF.png</a><p>That's why Python 2.7 will be around and maintain dominance for a while.<p>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).<p>Administrators (in the old school not the new "everything in containers") don't like using non-defaults.
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.
Users generally update by default, if thousands upon thousands didn't it's because someone else fucked up.<p>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.<p>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.<p>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?
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.<p>So for this feature alone, I'm all in on Python 3.
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?<p>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].<p>[0] <a href="https://facebook.github.io/react/blog/2016/02/19/new-versioning-scheme.html" rel="nofollow">https://facebook.github.io/react/blog/2016/02/19/new-version...</a>
Python really should learn from PHP7.<p>Yes, it breaks a lot of things, but it's totally worth it for the performance gains.<p>Py3k solves problems partially like Unicode or async/await but it's a non-issue for skilled python2 developers.<p>People like incentives to upgrade. Period.
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.<p>Right now in my life the major things stopping me from using python 3 for all the things are.<p><pre><code> * Ansible
* Two large in-house developed apps taken over from previous devs
* Debian Wheezy
</code></pre>
And as you can guess, at least one of those will hopefully disappear soon.<p>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.<p>I also know about a lot of alternative libs like ldap3, dnspython3 and more.
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.<p>Though all it takes is one dependency to throw a wrench in the plans, the major projects are Py3 now.<p>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.
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).<p>I don’t want to <i>add</i> 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.)
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.
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.<p>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.
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.
Python 3 is the default teaching language for the RaspberryPi. The BBC micro:bit runs MicroPython - a reimplementation of Python 3 for microcontrollers.<p>Teachers and kids are already ahead of the game.<p>When today's kids graduate they'll view Python2.7 in perhaps the same way I view Delphi or VB6 ("you're still using <i>that</i>..?" etc,).
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.
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.<p>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.
I'm actually surprised (pleasantly) to see that adoption is that high. I would have guessed at less than 10%.<p>I suppose the sample set (projects using a tool like Semaphore) is likely to be biased towards more forwards-looking teams, but still.
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.
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.
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.
Sentry is also still Python 2.7, thanks to Armin and his friends:<p><a href="https://github.com/getsentry/sentry/issues/1152" rel="nofollow">https://github.com/getsentry/sentry/issues/1152</a>
Let this (and Perl 6) be a lesson to language designers: <i>do not make backward-incompatible changes, ever</i>. It cripples adoption. Java managed this much better by being able to mark APIs as "deprecated".
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.<p>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.
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.
Title should be changed to "Python Versions Used in Commercial Projects, 2016 Edition". The data pertains only to Semaphore's commercial CI customers.
The only thing I haven't liked when comparing 2 to 3, is how 3 is even slower.<p>CPython is so slow, they really should start taking performance more seriously.
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.