7 ms·

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 visualsati

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.
    - wowzer 10y ago
      I'd love to know what "super fast" means. Are we talking about ETL jobs that would take hours? We run our batch file processing jobs in Python. It's not the fastest. But in a world where we can bring up more instances/containers to help process the work faster, I'd love to know how much faster COBOL is at these jobs that it'd be interesting to consider against the alternatives.
  - Loic 10y ago
    I code in Fortran 77/90 an average of 3 hours a day and I have a lot of fun! For science, the language is just vanishing and you can focus on the equations with at the end a crazy fast code. The other 3 hours are in Python, Go and JS&cie.
kikoreis 10y ago
Also, we (Ubuntu) definitely won't maintain or ship Python 2.7 indefinitely; I'm keeping a keen eye on how the ecosystem moves to decide when that happens.
- herge 10y ago
  You'll keep ship Python 2.7 for more or less time than Perl 5?
  - kikoreis 10y ago
    Hah, that's a trick question. Probably for less, given how deeply Debian tooling depends on perl5.
- module0000 10y ago
  I was under the impression Ubuntu is re-shipping the upstream debian python2x and 3x packages. Are your maintainers packaging 2x from scratch? If so...why?
  - kikoreis 10y ago
    Well, our maintainers (primarily Matthias) package both for Debian and Ubuntu, so they diverge only in the sense that the cadences and versioning are not completely aligned. But regardless of the packaging effort, the real overhead is tracking security for the [overlapping] LTS releases.
willvarfar 10y ago
If they put numbers on it, they'd be telling us how many customers they had? They might - understandably - not want to do that...
eeZi 10y ago
Google Trends chart: https://www.google.com/trends/explore?date=all&q=python%203 https://www.google.com/trends/explore?date=all&q=python%203
- freebs 10y ago
  Google Trends chart Python 2 VS Python 3: https://www.google.com/trends/explore?date=all&q=python%203,python%202 https://www.google.com/trends/explore?date=all&q=python%203,...
  - 1wd 10y ago
    2.6, 2.7, 3.0, 3.1, 3.2: https://www.google.com/trends/explore?date=all&q=python%202.6,python%202.7,python%203.0,python%203.1,python%203.2 https://www.google.com/trends/explore?date=all&q=python%202.... 2.7, 3.3, 3.4, 3.5, 3.6: https://www.google.com/trends/explore?date=all&q=python%202.7,python%203.3,python%203.4,python%203.5,python%203.6 https://www.google.com/trends/explore?date=all&q=python%202....
    - nooorofe 10y ago
      https://www.google.com/trends/explore?date=all&q=python%202.6,python%202.7,python%203.0,python%203.1,python3 https://www.google.com/trends/explore?date=all&q=python%202.... :)))
cauterized 10y ago
It's not just because we "know and love" Python2. We also have immense legacy Python2 codebases that it would be time-consuming and risky to upgrade to Python3. And we have other business priorities we have to pursue. As long as Python2 is viable. Which it still is and probably will be for quite a while. (Even once official support for it is dropped, there will undoubtedly be large enterprises that rely on it and will continue to maintain forks.)
- sametmax 10y ago
  This is why the Python community gave 15 years to migrate. This is why we created many, many tools (2to3, six, Python-future, mypy) to help with it. And this is why Guido is always saying 2.7 users are important and need respect. Still. 15 years. It's not a last minute change. Python has been incredible in maintaining the 2.7 around, giving people help and time to change. I know NO other tech that did that. The JS community breaks his toys every other week. PHP just jumped a version to avoid it. No one is migrating to Perl 6. Python is actually the only one that pulled this off, and have been very, very careful to give you the margin to do it. Everything needs to evolve, and one day you will have to do it. Don't to it in 2020, or it will be way more costly. And yes, you have many advantages in having Python 3, mainly ease of dev, debug and maintenance. This is not as hard as it seems. Took me a week alone to convert a huge system. Don't feel overwhelmed by the task, it's really not the end of the world.
  - cauterized 10y ago
    And when you have almost a million lines of code dating back 10 years; about 3% test coverage; and an executive team breathing down your neck to implement the features that should have been prioritized 5 years ago by the "leadership" they bought the company from? When you have 3 engineers, one of whom is working full time on bugfixes and preventing everything from catching fire and one of whom is working full time on applying the second of 8 major versions' worth of upgrades to your framework (along with third-party dependencies that have to be version-compatible) just to catch up to a version that's still maintained with security patches? When every framework/library upgrade, let alone language version upgrade exposes subtle backwards-incompatibilities with your external services, so you have to upgrade those too, and then spend 2 weeks understanding and solving the resulting forwards-incompatibilities? Just because it was easy for you and your codebase doesn't mean it's going to be easy for everyone else. I'm not saying we'll never doing it. I'm sure as hell not saying we (being the engineering team) don't want to do it. I'm saying we haven't done it yet because we can't do it at all until we complete the other upgrades. We can't do it at all without spending a week or three months or however long finding or writing replacements for crappy (and in a few cases not so crappy) abandoned third-party packages that aren't and never will be supported under Python3. We can't do it until we can spare 3 months from our timeline to exhaustively click-through test the damn thing and verify we haven't broken anything. And saying we had 15 years to migrate is bullshit. Our major dependencies haven't been stable on Python3 for more than about 3 years now. By the way, did I mention before that we have other business priorities? Python2 is still supported. It'll continue to be supported for a few more years. Why should we spend valuable time converting to Python3 now, when the other things we're working on could be the difference between whether or not we're still around in a few more years? No, it won't be more costly in 2020. It'll be less costly. We'll have a larger engineering team because we solved more business problems and customer problems, so the business earned more money and could afford to hire more people. Or we'll already be out of business and it will have had nothing to do with which version of Python we were using.
dom0 10y ago
Also, for the Python ecosystem closed source projects are less relevant than the open parts of the ecosystem. And the open side has rather clearly decided which versions will go forward. On a data level: I wouldn't be surprised if most of theese projects are either not actually new (ie. only added to their CI system, codebase is older) or is related/interacts/integrated to/into a Python 2 codebase, which arguably isn't a from-scratch project, either.
ma2rten 10y ago
As a data point: Google still uses python 2 and they used to employ Guido van Rossum.
- Redoubts 10y ago
  Doesn't his current employer also use python 2?
  - Animats 10y ago
    Yes. He has to maintain Python 2.7 as his day job at Dropbox.
    - Demiurge 10y ago
      And isn't he working on Piston, high performance JIT Python, which is python2.7 compatible?
      - poooogles 10y ago
        AFAIK he's mostly working on mypy/typing at Dropbox.
- freyir 10y ago
  Google is entering dinosaur territory. Big and impactful, but as a consequence, slow to change and laden with decades of preexisting infrastructure. I wouldn't expect them to be using Python 3.

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.
  - wowzer 10y ago
    I'd love to know what "super fast" means. Are we talking about ETL jobs that would take hours? We run our batch file processing jobs in Python. It's not the fastest. But in a world where we can bring up more instances/containers to help process the work faster, I'd love to know how much faster COBOL is at these jobs that it'd be interesting to consider against the alternatives.
- Loic 10y ago
  I code in Fortran 77/90 an average of 3 hours a day and I have a lot of fun! For science, the language is just vanishing and you can focus on the equations with at the end a crazy fast code. The other 3 hours are in Python, Go and JS&cie.

kikoreis 10y ago

Also, we (Ubuntu) definitely won't maintain or ship Python 2.7 indefinitely; I'm keeping a keen eye on how the ecosystem moves to decide when that happens.

herge 10y ago
You'll keep ship Python 2.7 for more or less time than Perl 5?
- kikoreis 10y ago
  Hah, that's a trick question. Probably for less, given how deeply Debian tooling depends on perl5.
module0000 10y ago
I was under the impression Ubuntu is re-shipping the upstream debian python2x and 3x packages. Are your maintainers packaging 2x from scratch? If so...why?
- kikoreis 10y ago
  Well, our maintainers (primarily Matthias) package both for Debian and Ubuntu, so they diverge only in the sense that the cadences and versioning are not completely aligned. But regardless of the packaging effort, the real overhead is tracking security for the [overlapping] LTS releases.

willvarfar 10y ago

If they put numbers on it, they'd be telling us how many customers they had? They might - understandably - not want to do that...

eeZi 10y ago

Google Trends chart: https://www.google.com/trends/explore?date=all&q=python%203 https://www.google.com/trends/explore?date=all&q=python%203

freebs 10y ago
Google Trends chart Python 2 VS Python 3: https://www.google.com/trends/explore?date=all&q=python%203,python%202 https://www.google.com/trends/explore?date=all&q=python%203,...
- 1wd 10y ago
  2.6, 2.7, 3.0, 3.1, 3.2: https://www.google.com/trends/explore?date=all&q=python%202.6,python%202.7,python%203.0,python%203.1,python%203.2 https://www.google.com/trends/explore?date=all&q=python%202.... 2.7, 3.3, 3.4, 3.5, 3.6: https://www.google.com/trends/explore?date=all&q=python%202.7,python%203.3,python%203.4,python%203.5,python%203.6 https://www.google.com/trends/explore?date=all&q=python%202....
  - nooorofe 10y ago
    https://www.google.com/trends/explore?date=all&q=python%202.6,python%202.7,python%203.0,python%203.1,python3 https://www.google.com/trends/explore?date=all&q=python%202.... :)))

cauterized 10y ago

It's not just because we "know and love" Python2. We also have immense legacy Python2 codebases that it would be time-consuming and risky to upgrade to Python3. And we have other business priorities we have to pursue. As long as Python2 is viable. Which it still is and probably will be for quite a while. (Even once official support for it is dropped, there will undoubtedly be large enterprises that rely on it and will continue to maintain forks.)

sametmax 10y ago
This is why the Python community gave 15 years to migrate. This is why we created many, many tools (2to3, six, Python-future, mypy) to help with it. And this is why Guido is always saying 2.7 users are important and need respect. Still. 15 years. It's not a last minute change. Python has been incredible in maintaining the 2.7 around, giving people help and time to change. I know NO other tech that did that. The JS community breaks his toys every other week. PHP just jumped a version to avoid it. No one is migrating to Perl 6. Python is actually the only one that pulled this off, and have been very, very careful to give you the margin to do it. Everything needs to evolve, and one day you will have to do it. Don't to it in 2020, or it will be way more costly. And yes, you have many advantages in having Python 3, mainly ease of dev, debug and maintenance. This is not as hard as it seems. Took me a week alone to convert a huge system. Don't feel overwhelmed by the task, it's really not the end of the world.
- cauterized 10y ago
  And when you have almost a million lines of code dating back 10 years; about 3% test coverage; and an executive team breathing down your neck to implement the features that should have been prioritized 5 years ago by the "leadership" they bought the company from? When you have 3 engineers, one of whom is working full time on bugfixes and preventing everything from catching fire and one of whom is working full time on applying the second of 8 major versions' worth of upgrades to your framework (along with third-party dependencies that have to be version-compatible) just to catch up to a version that's still maintained with security patches? When every framework/library upgrade, let alone language version upgrade exposes subtle backwards-incompatibilities with your external services, so you have to upgrade those too, and then spend 2 weeks understanding and solving the resulting forwards-incompatibilities? Just because it was easy for you and your codebase doesn't mean it's going to be easy for everyone else. I'm not saying we'll never doing it. I'm sure as hell not saying we (being the engineering team) don't want to do it. I'm saying we haven't done it yet because we can't do it at all until we complete the other upgrades. We can't do it at all without spending a week or three months or however long finding or writing replacements for crappy (and in a few cases not so crappy) abandoned third-party packages that aren't and never will be supported under Python3. We can't do it until we can spare 3 months from our timeline to exhaustively click-through test the damn thing and verify we haven't broken anything. And saying we had 15 years to migrate is bullshit. Our major dependencies haven't been stable on Python3 for more than about 3 years now. By the way, did I mention before that we have other business priorities? Python2 is still supported. It'll continue to be supported for a few more years. Why should we spend valuable time converting to Python3 now, when the other things we're working on could be the difference between whether or not we're still around in a few more years? No, it won't be more costly in 2020. It'll be less costly. We'll have a larger engineering team because we solved more business problems and customer problems, so the business earned more money and could afford to hire more people. Or we'll already be out of business and it will have had nothing to do with which version of Python we were using.

dom0 10y ago

Also, for the Python ecosystem closed source projects are less relevant than the open parts of the ecosystem. And the open side has rather clearly decided which versions will go forward. On a data level: I wouldn't be surprised if most of theese projects are either not actually new (ie. only added to their CI system, codebase is older) or is related/interacts/integrated to/into a Python 2 codebase, which arguably isn't a from-scratch project, either.

ma2rten 10y ago

As a data point: Google still uses python 2 and they used to employ Guido van Rossum.

Redoubts 10y ago
Doesn't his current employer also use python 2?
- Animats 10y ago
  Yes. He has to maintain Python 2.7 as his day job at Dropbox.
  - Demiurge 10y ago
    And isn't he working on Piston, high performance JIT Python, which is python2.7 compatible?
    - poooogles 10y ago
      AFAIK he's mostly working on mypy/typing at Dropbox.
freyir 10y ago
Google is entering dinosaur territory. Big and impactful, but as a consequence, slow to change and laden with decades of preexisting infrastructure. I wouldn't expect them to be using Python 3.