7 ms·

2019 Python Developer Survey

96 points by luord 7y ago

EllipticCurve 7y ago
Thanks for the link, participated. Nice concise, adaptive survey.
mixmastamyk 7y ago
FYI, the link to start the survey was in the center of the page. A bit hard to see on my mobile.
c4urself 7y ago
Take the survey here: https://surveys.jetbrains.com/s3/c9-python-developers-survey-2019 https://surveys.jetbrains.com/s3/c9-python-developers-survey...
sethammons 7y ago
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.
- downerending 7y ago
  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.
  - cesarb 7y ago
    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/ 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).
    - downerending 7y ago
      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'.
  - laggan 7y ago
    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.
  - pjmlp 7y ago
    Try to compile any post C89 code with a C++ compiler to see how far you will go. And even then there is stuff like implicit conversions or the ?: operator, whose semantics differ between C and C++.
    - downerending 7y ago
      Indeed, C and C++ have always been two different languages. Hence the "not unlike". 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.
baq 7y ago
No questions about mypy?
- phonethrowaway 7y ago
  The way they implemented type hinting has been a huge turn off to me. What are your thoughts?
  - azhenley 7y ago
    What in particular? Do you have any suggestions on how you would like it to work?
    - tinix 7y ago
      The syntax is what gets me... it's so unpythonic. Like the walrus operator... No thanks!
  - laggan 7y ago
    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.
ilovecaching 7y ago
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?
- The_rationalist 7y ago
  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".
  - sethammons 7y ago
    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.
- deleted 7y ago
  [deleted]
bjt2n3904 7y ago
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!
- toyg 7y ago
  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.
- scaryclam 7y ago
  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.
- wil421 7y ago
  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.
- pjmlp 7y ago
  Actually Python was there first. https://www.zope.org/ https://www.zope.org/ Probably the biggest reason to use Python back in early 2000's.
- paulddraper 7y ago
  I learned Python in 2011 for a Django project. > 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++.
floki999 7y ago
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.

96 points by luord 7y ago

EllipticCurve 7y ago

Thanks for the link, participated. Nice concise, adaptive survey.

mixmastamyk 7y ago

FYI, the link to start the survey was in the center of the page. A bit hard to see on my mobile.

c4urself 7y ago

Take the survey here: https://surveys.jetbrains.com/s3/c9-python-developers-survey-2019 https://surveys.jetbrains.com/s3/c9-python-developers-survey...

sethammons 7y ago

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.

downerending 7y ago
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.
- cesarb 7y ago
  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/ 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).
  - downerending 7y ago
    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'.
- laggan 7y ago
  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.
- pjmlp 7y ago
  Try to compile any post C89 code with a C++ compiler to see how far you will go. And even then there is stuff like implicit conversions or the ?: operator, whose semantics differ between C and C++.
  - downerending 7y ago
    Indeed, C and C++ have always been two different languages. Hence the "not unlike". 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.

baq 7y ago

No questions about mypy?

phonethrowaway 7y ago
The way they implemented type hinting has been a huge turn off to me. What are your thoughts?
- azhenley 7y ago
  What in particular? Do you have any suggestions on how you would like it to work?
  - tinix 7y ago
    The syntax is what gets me... it's so unpythonic. Like the walrus operator... No thanks!
- laggan 7y ago
  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.

ilovecaching 7y ago

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?

The_rationalist 7y ago
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".
- sethammons 7y ago
  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.
deleted 7y ago
[deleted]

bjt2n3904 7y ago

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!

toyg 7y ago
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.
scaryclam 7y ago
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.
wil421 7y ago
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.
pjmlp 7y ago
Actually Python was there first. https://www.zope.org/ https://www.zope.org/ Probably the biggest reason to use Python back in early 2000's.
paulddraper 7y ago
I learned Python in 2011 for a Django project. > 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++.

floki999 7y ago

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.