Even if (or especially if) you are not on the latest and greatest Python version(s), I think it is still valuable to take the survey. We are locked in at 2.6 no matter what on one of our projects. We slowly whittle it away into other services, but making it modern is not feasible.
The reality is that Python2 and Python3 are really two different languages, not unlike C and C++. This is being recognized more as time passes.
Should Python2 be consigned to history? Should C have been? I'm not so sure now. Python3 has a lot more to know, but not necessarily a lot more that's useful for what I do.
It's the paradox of the heap. Should Python 2.6 be considered a different language than Python 2.7? What about Python 1.6 and Python 2.0? Perl 5 and Perl 6? What's the exact amount of changes necessary to switch between "new version of the same language" and "new language"? You might thing that the answer is "breaking changes", but every change breaks someone's workflow (https://xkcd.com/1172/), and even a minor release like Python 2.7.9 had some breaking changes (and yet it's widely considered the same language as Python 2.7.8).
I consider Python 2.latest to be the same language as Python 1.5.2, which was the first I used. They are upward compatible, aside from very small and presumably unavoidable changes.
Python 3 is pretty similar, but nonetheless is very different, thinking of it as the same language will cause you grief. Modern advice is to use the 'python2' and 'python3' commands--never just 'python'.
C and C++ are radically different that is not an accurate comparison. Python 3 has many minor breaking changes and few bigger changes. Most huge codebases that support 3 have huge amount of support code that makes it compatible with 2. Probably 80% of the changes in 3 could've been done in an backwards-compatible way, but they actively chose not to.
I'm still surprised that python survived it, the update was so incompetently done. Just the huge amount of wasted developer resources on this mostly unnecessary update is staggering.
I think overall it is still very immature, I wish there was someone more competent who lead the project. Its not just a lack of resources to blame for its many shortcomings in my opinion.
* the syntax is obtuse and limited on a completely arbitrary restriction of not wanting to extend the parser. (The idea of decoupling type annotations from the type checking implementation is completely insane)
* in most situations you will not know if mypy actually does anything on any given line of code or silently ignores it. There are some options to enable more strict checking but that is almost completely useless because...
* most/all libraries (even standard library) packages have none or very few type annotations (stubs) available and this will likely never actually get better due to its aforementioned incompetent design.
* there is a huge amount of tiny little annoyances and mistakes in the design of the type system you will stumble on when working with it on any large scale
* the mypy type inference (or lack thereof) is terrible, compare it with type inference in C++ (auto) or Rust to see the difference to a competently done type system.
* the mypy software itself has a history of a huge amount of bugs and regressions speaking to its immaturity (1,130 open issues in github at the moment)
I feel most people who will defend mypy no matter what, have probably not had the "pleasure" of using it in a significantly large codebase.
But... I still use it, people should still use it, shitty static code analysis is still better than nothing.
Is there actual hard data out there that suggests that Python provides significant benefits over a statically typed compiled language?
I’ve been thinking quite a bit about how it seems that despite how fun Python is to write the dynamic types are really just a determinant with upsides that are essentially anecdotal. Why would one take a performance hit and give up a type system without hard evidence that there would be significant improvements to other metrics?
Developper productivity is order of magnitude more important than performance on most software.
Dynamic typing is by design more productive at first.
Static type systems might allow better productivity on the long term (maintenability, scalability of à big, complex codebase).
If this advantage of static typing is a myth, or a truth (and by how much does it increase average productivity, for which project size?) is a really interesting question and I don't know any scientific study on the topic.
I did read a study that showed that static types catch only a few percentage of bugs and that practices such as systematic code reviews, documentation/comments, unit testing and integration testing, and methods such as TDD, each of them has a far bigger impact than static typing.
(it would be nice if they had measured too the impact of fuzzing, analytics, debuggers and language features such as having a GC).
This study does not say that using all those practices obscolete the need of static typing but it show the irrationality that many "purist/religious" developpers have by claiming writing a program in a dynamically typed language is a maintenance nightmare while not saying anything about enforcing the said practices despite them having empirically a far bigger impact on bug catching and thus "code quality".
Having cut my professional teeth on php, perl, ruby, and python, I find no reduced speed working in Go. In fact, I think it is faster to develop in Go. The only time this is not the case is very simple run-once scripts where I don't need tests, and even then I'm not convinced that python is faster.
> Is there actual hard data out there that suggests that Python provides significant benefits over a statically typed compiled language?
You are asking for hard data on a badly defined question. What kind of benefits are you talking about? Does learning curve count? Does speed of development and prototyping count? Does lack of build/compile cycle count?
If I want to run analysis on some data or play around with a machine learning model or actually do any other "I just wanna see what happens" type of experiment, python provides a lot of advantages over a lot of other languages.
If I want to create a simple set of REST style fetch-from-db-and-return-JSON APIs, python is great. There are other options, like Go and Node, but Python is pretty good.
There are other scenarios like this, but these two are the first ones that come to my mind.
I am currently working on a medium sized python project (about 25K LOC or so) and I am starting to think of rewriting some of the key pieces in a compiled, statically typed language for better performance and maintainability. But I feel that at this size and smaller I still have the benefits of quick development cycle.
As someone who has been working in the _same_ python codebase for near a decade (off and on, it is an ancillary internal service with ~150k lines of code that does not get enough love), I speak from experience when I say that any service being maintained needs to have static typing. `def foo(bar)` - what _is_ bar?! What can I do with it? I either get to dig up and up the stack or pull out a debugger. Additionally, in python, you can iterate over a string or a list, so now you have to protect against both being passed in. Even this simple thing has caused many-o-bug in my experience. Half the tests are type validations.
Seems like the survey was HEAVILY weighted to learn about how people use python for web / big data / cloud.
As an embedded stick-in-the-mud Python2 developer, I'm mildly frustrated. It seems that the python community has been taken over by people trying to compete with NodeJS. Other use cases exist!
That’s uncharitable and, if I may, a bit of a projection maybe. JetBrains runs this poll every year. You can check results and questions for previous years. The trends are pretty clear (if naturally skewed towards people who will answer a web poll, i.e. “web people”).
The fact of the matter is simply that Py3 has established itself as the main version of the language, and that datascience and web are two sectors where Python usage is currently ballooning. It may or may not stay that way in the future, but that’s how it is at the moment.
It's a bit of a shame you're being voted down I think. I use python for a lot of web work, but just as much non-web applications work and felt that the survey was missing a lot of other options.
Flask is what got me interested in Python, I consider my self a web dev. When I was starting with a Raspberry Pi project I was just going to work with examples and tweak them to my needs. After going through a simple Flask Blog course on YouTube, I decided to pick up a book, learn the basic of Python first, and then come back to my original project. The syntax and zen philosophy have me hooked.
I think the python ‘developers’ this survey targets is only the tip of the iceberg.
I’ve been using python for 15+ years, writing production tools, yet I’m not a developer and this is not the focus of my job. I expect there are vast numbers of Python coders out there who develop meaningful tools using Python and know the language well, but whose main activity is not software dev.
Clearly, the survey reflects the audience targeted by JetBrains i.e. web and data scientists - whatever the latter really means.
33 comments
[ 3.4 ms ] story [ 79.0 ms ] threadNice concise, adaptive survey.
Should Python2 be consigned to history? Should C have been? I'm not so sure now. Python3 has a lot more to know, but not necessarily a lot more that's useful for what I do.
Python 3 is pretty similar, but nonetheless is very different, thinking of it as the same language will cause you grief. Modern advice is to use the 'python2' and 'python3' commands--never just 'python'.
I'm still surprised that python survived it, the update was so incompetently done. Just the huge amount of wasted developer resources on this mostly unnecessary update is staggering.
And even then there is stuff like implicit conversions or the ?: operator, whose semantics differ between C and C++.
I still occasionally see people trying to compile or link C++ with 'gcc'. Does that work? Maybe or even most of the time, but doing that is a sin.
* the syntax is obtuse and limited on a completely arbitrary restriction of not wanting to extend the parser. (The idea of decoupling type annotations from the type checking implementation is completely insane)
* in most situations you will not know if mypy actually does anything on any given line of code or silently ignores it. There are some options to enable more strict checking but that is almost completely useless because...
* most/all libraries (even standard library) packages have none or very few type annotations (stubs) available and this will likely never actually get better due to its aforementioned incompetent design.
* there is a huge amount of tiny little annoyances and mistakes in the design of the type system you will stumble on when working with it on any large scale
* the mypy type inference (or lack thereof) is terrible, compare it with type inference in C++ (auto) or Rust to see the difference to a competently done type system.
* the mypy software itself has a history of a huge amount of bugs and regressions speaking to its immaturity (1,130 open issues in github at the moment)
I feel most people who will defend mypy no matter what, have probably not had the "pleasure" of using it in a significantly large codebase.
But... I still use it, people should still use it, shitty static code analysis is still better than nothing.
I’ve been thinking quite a bit about how it seems that despite how fun Python is to write the dynamic types are really just a determinant with upsides that are essentially anecdotal. Why would one take a performance hit and give up a type system without hard evidence that there would be significant improvements to other metrics?
You are asking for hard data on a badly defined question. What kind of benefits are you talking about? Does learning curve count? Does speed of development and prototyping count? Does lack of build/compile cycle count?
If I want to run analysis on some data or play around with a machine learning model or actually do any other "I just wanna see what happens" type of experiment, python provides a lot of advantages over a lot of other languages.
If I want to create a simple set of REST style fetch-from-db-and-return-JSON APIs, python is great. There are other options, like Go and Node, but Python is pretty good.
There are other scenarios like this, but these two are the first ones that come to my mind.
I am currently working on a medium sized python project (about 25K LOC or so) and I am starting to think of rewriting some of the key pieces in a compiled, statically typed language for better performance and maintainability. But I feel that at this size and smaller I still have the benefits of quick development cycle.
Different strokes for different folks, my friend.
As an embedded stick-in-the-mud Python2 developer, I'm mildly frustrated. It seems that the python community has been taken over by people trying to compete with NodeJS. Other use cases exist!
The fact of the matter is simply that Py3 has established itself as the main version of the language, and that datascience and web are two sectors where Python usage is currently ballooning. It may or may not stay that way in the future, but that’s how it is at the moment.
https://www.zope.org/
Probably the biggest reason to use Python back in early 2000's.
> embedded stick-in-the-mud Python2 developer
Python (CPython) is also getting crowded out on the low-end thanks to native languages getting easier: Rust, Go, even modern C++.
I'm also not fond of the nodejs style "download another copy of these 300 microlibraries and compile them all".
I’ve been using python for 15+ years, writing production tools, yet I’m not a developer and this is not the focus of my job. I expect there are vast numbers of Python coders out there who develop meaningful tools using Python and know the language well, but whose main activity is not software dev.
Clearly, the survey reflects the audience targeted by JetBrains i.e. web and data scientists - whatever the latter really means.