5 ms·

In my dreams Python has the stability of Perl, then I'm woken by an alarm that a Python script I wrote 6 months ago uses a now-deprecated feature ...

andrewstuart 3y ago
This is a new one on me …. Python is unstable?
- qsort 3y ago
  It's certainly less stable and ubiquitous than Perl. These days I'd rather be on Python (better libs, doesn't spook colleagues, very common on Linux boxes), but it's not an unreasonable position.
- t8sr 3y ago
  Very much so, insofar as code written a few years ago probably doesn’t work anymore. Some of that comes down to libraries not being careful about versioning, but a lot of it is the language itself making seemingly random changes in direction every few years. 10 years ago: range 5 years ago: xrange Today: range again, LOL! I don’t know of any tech companies using Python for anything serious anymore, except data/ML analysis, which is usually not too much code. If you make me rewrite the thing, it’s getting rewrote in Go or Rust, not Python again.
  - andrewstuart 3y ago
    Maybe Perl is stable cause its dead.
    - meepmorp 3y ago
      Latin and Sanskrit are stable af.
      - jjgreen 3y ago
        Latin is pretty stable, but not entirely fixed: https://www.nytimes.com/2003/05/14/world/vatican-introduces-latin-to-21st-century-with-new-dictionary.html https://www.nytimes.com/2003/05/14/world/vatican-introduces-...
      - drewcoo 3y ago
        I took a medieval Latin course in college that was especially challenging because after the empire fell, Latin was absolutely not stable.
  - Roark66 3y ago
    How about a fortune 300 company I consulted for that uses python pretty much exclusively for the deployment processes of their 200+ web/cloud apps? Some of those apps have 1 VM plus a DB and a dozen users. Some have environments that cost £30k a month and 5k users. Python is the only language used for CI/CD. Plus power shell for stuff that needs windows server. 70% is python 2, 30% written/rewritten recently is python 3.
    - josefx 3y ago
      > 70% is python 2 I hope they are paying for security updates since python 2 has hit EOL 3 years ago and libraries had been actively shamed if they didn't drop support for it long before that.
      - Roark66 3y ago
        Nope, not for python 2, but there was tracking of published vulnerabilities. None that were discovered during my time there affected existing python 2 code. Python 2 code is being transitioned to 3 and there is a plan to do so for all of it, but it's definitely not a highest priority task. Usually done when new features are requested. This isn't ideal, but it's not a reason to panic. None of the code is externally facing, none of it accepts user input directly beyond a press of a button in third party software that triggers it. All it does is pretty simple stuff. Infrastructure provisioning etc.
  - smcl 3y ago
    The criticism is that the Python team will deprecate and remove functionality as it's not needed? Boy, you're gonna hate PEP-594. Also Python 2->3 transition was a one-time thing that developers had over a decade to perform, it may have been painful for some but saying it's a random thing that happens "every few years" is a bit dishonest.
    - fullspectrumdev 3y ago
      PEP-594 is actually causing me some anxiety - I deal with a good amount of code that uses some of those “batteries to be removed”. Some of them (telnetlib) I can vendor in, but I wonder how many people who use them will be caught pantsless?
      - smcl 3y ago
        My feeling is that if you're the sort of org who will update the Python version you use, you're going to be switched-on enough to handle this somehow. From the sounds of things it it's a bit of an inconvenience for you that you'd understandably rather not have, but you have it under control. I don't personally use any of these "dead" batteries though, so I can't speak with any authority on the matter
    - stonogo 3y ago
      Are you saying there will never be a Python 4, or are you saying that the 2->3 transition was so badly flubbed nobody will make that mistake again?
      - smcl 3y ago
        Well yeah given that some people are still talking about issues from a software release that happened 15 years ago, it would be incredibly unlikely that they'd want to repeat that. What has me a little bit confused is that we're in a thread talking about how Python somehow "flubbed" after 2->3, despite an explosion in popularity during that period culminating in it being arguably the most popular programming language around. And the counterexample is supposed to be Perl, a language which I have enjoyed using but which has fallen off a cliff during the same period, and which has had an even more enormous and self-defeating flub (Perl 6 aka "Raku"). As I said, I understand if Python 3.x was painful for some organizations. I think the suggestion that it was a failure and that Perl showed us the right way to go is a pretty silly one though.
  - telmo 3y ago
    > I don’t know of any tech companies using Python for anything serious anymore, except data/ML analysis, which is usually not too much code. If you make me rewrite the thing, it’s getting rewrote in Go or Rust, not Python again. It is weirdly comforting to observe how certain things never change over the years, even in tech. One of them is the hyperboles people deploy when attacking programming languages that they do not like: "I don’t know of any tech companies using Python for anything serious anymore". I mean, except for being the 4th most popular language amongst professional according to last year's Stack Overflow survey. Only JavaScript, SQL and HTML/CSS are more popular. Yes, yes, I am sure it is dying... any moment now.
    - t8sr 3y ago
      You just read what you want to read, friend. I don’t particularly dislike Python, in fact I wrote about 50k lines of it a few years ago. My claim is that the big names don’t really use Python outside of data pipelines. Where I’ve worked (including an org that had had Guido on it for a while) usually had guidance saying “no new Python projects”. You can ask people at Google, Meta, etc when was the last time they wrote production Python code if you don’t believe me. That’s not mutually exclusive with web devs on Stack Overflow using the language, nor does it take away from its success in academia.
  - raverbashing 3y ago
    > it’s getting rewrote in Go or Rust, not Python again. Have you ever tried to recompile 1 yr old code in Rust with the latest compiler?
    - orwin 3y ago
      Why wouldn't you tag your 1 year old code with the compiler it was written for? And same question for grandparents. I'm not a great dev, average at best, but at least I control my systems.
      - stonogo 3y ago
        If that's what best practices are for these languages, I now better understand my collegues who will not move away from C/C++. Having to identify a specific compiler version for each bit of code sounds like a nightmare.
        zkldi 3y ago
        it's very easy. you make a file called `rust-toolchain` next to your `Cargo.toml` that contains the version of rust you intend this to compile for. It will then compile for that version.
        bamfly 3y ago
        C and C++ projects of any notably complexity & size often suffer from those exact same kind of "library or build tool or compiler updated—now the project won't build" problems. Absent some pretty heroic & unusual levels of discipline from all involved, anyway (which is also a way to avoid those issues in most other languages that have them). [EDIT] Check out issue trackers for such projects, some time. "Build broke due to [thing] being too new" is a routine issue to encounter.
      - gkbrk 3y ago
        Why should you need to? Just use a stable language, or a language that has a standard or a specification.
  - BeetleB 3y ago
    > but a lot of it is the language itself making seemingly random changes in direction every few years. Outside of 2 -> 3, I can recall only one or two instances of dealing with this in the last 15 years. One was the introduction of "with" and "as" as a keyword. The other one I can't even remember. None of the code I have written on my personal PC in all these years needed modification due to these changes (all of them were in 3rd party code I needed to patch). I still have Python 2 scripts continually running! I have Python 3.10 installed, and never had to fix a broken script of mine since I switched to Python 3 several years ago. > 10 years ago: range 5 years ago: xrange Today: range again, LOL! Eh? When I began using it heavily (before Python 3 existed), both range and xrange were heavily in use - one was a list the other was a generator. Since Python 3 has been stable and fast (circa 2013 or 2014), it's been only range.
  - rcarmo 3y ago
    This goes against my own experience. I moved from Perl 4 to 5 and from Python 2.x to 3.x and have dozens of projects written in Python that have been constantly updated over the past 10 years, none of which broke due to those things - and they are not all in the ML space. Your sample size of one needs expanding.
  - nerdponx 3y ago
    > Very much so, insofar as code written a few years ago probably doesn’t work anymore. Citation needed? Just a week ago I used a Python library completely unchanged from 2013. > Some of that comes down to libraries not being careful about versioning, but a lot of it is the language itself making seemingly random changes in direction every few years. "Seemingly random" is both wrong and insulting. The BDFL did step down and was replaced with a steering council, so maybe that's what you're seeing. I do agree that `match` was a bad addition to the language, but that's one small example among many supporting the opposite opinion. > 10 years ago: range 5 years ago: xrange Today: range again, LOL! Huh? Python 3.x has only ever had range(), so it's been range() for at least 10 years.
- jjgreen 3y ago
  Clearly an example of a parallel universe leaking into my own, can I come and live in yours? Please?
- KaiserPro 3y ago
  One of the things that I noticed when I started python (many many years ago) is that it crashed a lot more than perl. perl you really had to properly abuse it to make it actually crash. Now, some people see that as a feature not a bug (for either perl or python's behaviour)
- kdklol 3y ago
  Can confirm, recently written scripts require modification pretty much every minor version. Take the limit on the default size of BigInts now. Why? Just... why? I had to look into every script add the override line at the top (or check the entire script it ever assumes unlimited BigInt anywhere). No wonder there are still Python 2 scripts in use.
dmz73 3y ago
I wanted to like Python. Every time I tried to use/learn it, the "program" I wanted to use had some issue. The very first one (some 15 years ago) depended on mutually incompatible libraries so I had to spend time not only learning Python but fixing the libraries to work together. Next one was a dlna server that managed to use up all 4GB RAM available on my NAS and make the whole system unusable. Then there was a "compiler" that worked on all OS-es except that on Windows it would 100% not work due to some path string handling when starting a process. How do you even get to that point...that could have never worked on Windows and it's not like Windows is some marginal never used system so no testing was required. Then I tried to write a simple script to transfer some emails via IMAP...and Python idea of supporting IMAP is for me to read the RFC and build the correct string to sent to IMAP server...WTF???? That is the assembler lever of "support" of something. I did try to do that and then I ended up with multiple pages of something that looked like level of arcade game with climbing hills and cliffs of code where it was hard to tell if code was meant to end or if someone got bored of writing and just gave up. I hate Python.
- anthk 3y ago
  Heh. On Python and IMAP, getmail was dog slow against isync/mbsync. Same RAM issues.
Hamuko 3y ago
Deprecation doesn't really mean that your script is broken or going to break anytime soon. unittest.UnitTest.assertEquals() has been deprecated since 2011-02 (Python 3.2) and is set to be actually removed 2023-10 (Python 3.12).
- jjgreen 3y ago
  Not always, but for the sake of your sanity you need to fix those deprecations, if only so you can see the new ones, one of which will break your script at some point.
tokai 3y ago
What? The Perl 6 debacle has gone down even worse than Python 3.
- G3rn0ti 3y ago
  Perl 6 took longer than expected but „Raku“ is alive and well. It even moved into the Tiobe-Index at rank #48 recently: https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ This whole Python/Perl competition was always a bit silly. Both languages had and have their place. I would say Python is so much more popular because it found a niche in ML because of how much more easy it is in Python to interface fast C modules. So you get to write simple Python programs leveraging blazingly fast math libraries. That was always a bit more tricky to do in Perl. But Python as a language is definitely not as flexible as Perl 5. Last time I checked Python didn’t even support multi-line lambdas because its inventor hates those. Python is very much designed in a top-down approach and tries to guide all Python programmers into how there are supposed to solve their problems. Perl 5 was designed with its famous „easy things should be easy, hard problems possible to solve” philosophy. It allows for meta-programming in all the right places which a seasoned Perl developer can reach to when necessary. Perl 5 is a nice middle way between C and Lisp. That being said modern JavaScript turned into a powerful language that fits well into both the frontend and backend side of a web application nowadays and, hence, kind of replaced Perl as glue language for the web. It will also push Python out of web backends at some point I believe.
  - achileas 3y ago
    Having used Python and Perl professionally, I'd have to agree with really all of this. I just want to emphasize Python's niche in ML (since that's what I do with it mostly lately) - it was also helped by a large, early set of libraries specifically for ML that other languages either still don't have or are playing catch-up (Elixir), and its ease of use among academics, a lot of whom went straight from academia to industry.
- b1c837696ba28b 3y ago
  Really? Was Perl 5 deprecated with prejudice across ecosystems, forcing projects to work with a janky, still-evolving replacement well ahead of production-grade stability? Because the boot marks in my ass from the forced march to Py3 are still bleeding.
nerdponx 3y ago
Which feature? Deprecation warnings tend to be in place for several years before removal. There's a formal policy for it: https://peps.python.org/pep-0387/ https://peps.python.org/pep-0387/ > Unless it is going through the deprecation process below, the behavior of an API must not change in an incompatible fashion between any two consecutive releases. Python’s yearly release process (PEP 602) means that the deprecation period must last at least two years. In practice, it's usually longer than two years, except on features that were considered provisional in the first place.

andrewstuart 3y ago

This is a new one on me …. Python is unstable?

qsort 3y ago
It's certainly less stable and ubiquitous than Perl. These days I'd rather be on Python (better libs, doesn't spook colleagues, very common on Linux boxes), but it's not an unreasonable position.
t8sr 3y ago
Very much so, insofar as code written a few years ago probably doesn’t work anymore. Some of that comes down to libraries not being careful about versioning, but a lot of it is the language itself making seemingly random changes in direction every few years. 10 years ago: range 5 years ago: xrange Today: range again, LOL! I don’t know of any tech companies using Python for anything serious anymore, except data/ML analysis, which is usually not too much code. If you make me rewrite the thing, it’s getting rewrote in Go or Rust, not Python again.
- andrewstuart 3y ago
  Maybe Perl is stable cause its dead.
  - meepmorp 3y ago
    Latin and Sanskrit are stable af.
    - jjgreen 3y ago
      Latin is pretty stable, but not entirely fixed: https://www.nytimes.com/2003/05/14/world/vatican-introduces-latin-to-21st-century-with-new-dictionary.html https://www.nytimes.com/2003/05/14/world/vatican-introduces-...
    - drewcoo 3y ago
      I took a medieval Latin course in college that was especially challenging because after the empire fell, Latin was absolutely not stable.
- Roark66 3y ago
  How about a fortune 300 company I consulted for that uses python pretty much exclusively for the deployment processes of their 200+ web/cloud apps? Some of those apps have 1 VM plus a DB and a dozen users. Some have environments that cost £30k a month and 5k users. Python is the only language used for CI/CD. Plus power shell for stuff that needs windows server. 70% is python 2, 30% written/rewritten recently is python 3.
  - josefx 3y ago
    > 70% is python 2 I hope they are paying for security updates since python 2 has hit EOL 3 years ago and libraries had been actively shamed if they didn't drop support for it long before that.
    - Roark66 3y ago
      Nope, not for python 2, but there was tracking of published vulnerabilities. None that were discovered during my time there affected existing python 2 code. Python 2 code is being transitioned to 3 and there is a plan to do so for all of it, but it's definitely not a highest priority task. Usually done when new features are requested. This isn't ideal, but it's not a reason to panic. None of the code is externally facing, none of it accepts user input directly beyond a press of a button in third party software that triggers it. All it does is pretty simple stuff. Infrastructure provisioning etc.
- smcl 3y ago
  The criticism is that the Python team will deprecate and remove functionality as it's not needed? Boy, you're gonna hate PEP-594. Also Python 2->3 transition was a one-time thing that developers had over a decade to perform, it may have been painful for some but saying it's a random thing that happens "every few years" is a bit dishonest.
  - fullspectrumdev 3y ago
    PEP-594 is actually causing me some anxiety - I deal with a good amount of code that uses some of those “batteries to be removed”. Some of them (telnetlib) I can vendor in, but I wonder how many people who use them will be caught pantsless?
    - smcl 3y ago
      My feeling is that if you're the sort of org who will update the Python version you use, you're going to be switched-on enough to handle this somehow. From the sounds of things it it's a bit of an inconvenience for you that you'd understandably rather not have, but you have it under control. I don't personally use any of these "dead" batteries though, so I can't speak with any authority on the matter
  - stonogo 3y ago
    Are you saying there will never be a Python 4, or are you saying that the 2->3 transition was so badly flubbed nobody will make that mistake again?
    - smcl 3y ago
      Well yeah given that some people are still talking about issues from a software release that happened 15 years ago, it would be incredibly unlikely that they'd want to repeat that. What has me a little bit confused is that we're in a thread talking about how Python somehow "flubbed" after 2->3, despite an explosion in popularity during that period culminating in it being arguably the most popular programming language around. And the counterexample is supposed to be Perl, a language which I have enjoyed using but which has fallen off a cliff during the same period, and which has had an even more enormous and self-defeating flub (Perl 6 aka "Raku"). As I said, I understand if Python 3.x was painful for some organizations. I think the suggestion that it was a failure and that Perl showed us the right way to go is a pretty silly one though.
- telmo 3y ago
  > I don’t know of any tech companies using Python for anything serious anymore, except data/ML analysis, which is usually not too much code. If you make me rewrite the thing, it’s getting rewrote in Go or Rust, not Python again. It is weirdly comforting to observe how certain things never change over the years, even in tech. One of them is the hyperboles people deploy when attacking programming languages that they do not like: "I don’t know of any tech companies using Python for anything serious anymore". I mean, except for being the 4th most popular language amongst professional according to last year's Stack Overflow survey. Only JavaScript, SQL and HTML/CSS are more popular. Yes, yes, I am sure it is dying... any moment now.
  - t8sr 3y ago
    You just read what you want to read, friend. I don’t particularly dislike Python, in fact I wrote about 50k lines of it a few years ago. My claim is that the big names don’t really use Python outside of data pipelines. Where I’ve worked (including an org that had had Guido on it for a while) usually had guidance saying “no new Python projects”. You can ask people at Google, Meta, etc when was the last time they wrote production Python code if you don’t believe me. That’s not mutually exclusive with web devs on Stack Overflow using the language, nor does it take away from its success in academia.
- raverbashing 3y ago
  > it’s getting rewrote in Go or Rust, not Python again. Have you ever tried to recompile 1 yr old code in Rust with the latest compiler?
  - orwin 3y ago
    Why wouldn't you tag your 1 year old code with the compiler it was written for? And same question for grandparents. I'm not a great dev, average at best, but at least I control my systems.
    - stonogo 3y ago
      If that's what best practices are for these languages, I now better understand my collegues who will not move away from C/C++. Having to identify a specific compiler version for each bit of code sounds like a nightmare.
      - zkldi 3y ago
        it's very easy. you make a file called `rust-toolchain` next to your `Cargo.toml` that contains the version of rust you intend this to compile for. It will then compile for that version.
      - bamfly 3y ago
        C and C++ projects of any notably complexity & size often suffer from those exact same kind of "library or build tool or compiler updated—now the project won't build" problems. Absent some pretty heroic & unusual levels of discipline from all involved, anyway (which is also a way to avoid those issues in most other languages that have them). [EDIT] Check out issue trackers for such projects, some time. "Build broke due to [thing] being too new" is a routine issue to encounter.
    - gkbrk 3y ago
      Why should you need to? Just use a stable language, or a language that has a standard or a specification.
- BeetleB 3y ago
  > but a lot of it is the language itself making seemingly random changes in direction every few years. Outside of 2 -> 3, I can recall only one or two instances of dealing with this in the last 15 years. One was the introduction of "with" and "as" as a keyword. The other one I can't even remember. None of the code I have written on my personal PC in all these years needed modification due to these changes (all of them were in 3rd party code I needed to patch). I still have Python 2 scripts continually running! I have Python 3.10 installed, and never had to fix a broken script of mine since I switched to Python 3 several years ago. > 10 years ago: range 5 years ago: xrange Today: range again, LOL! Eh? When I began using it heavily (before Python 3 existed), both range and xrange were heavily in use - one was a list the other was a generator. Since Python 3 has been stable and fast (circa 2013 or 2014), it's been only range.
- rcarmo 3y ago
  This goes against my own experience. I moved from Perl 4 to 5 and from Python 2.x to 3.x and have dozens of projects written in Python that have been constantly updated over the past 10 years, none of which broke due to those things - and they are not all in the ML space. Your sample size of one needs expanding.
- nerdponx 3y ago
  > Very much so, insofar as code written a few years ago probably doesn’t work anymore. Citation needed? Just a week ago I used a Python library completely unchanged from 2013. > Some of that comes down to libraries not being careful about versioning, but a lot of it is the language itself making seemingly random changes in direction every few years. "Seemingly random" is both wrong and insulting. The BDFL did step down and was replaced with a steering council, so maybe that's what you're seeing. I do agree that `match` was a bad addition to the language, but that's one small example among many supporting the opposite opinion. > 10 years ago: range 5 years ago: xrange Today: range again, LOL! Huh? Python 3.x has only ever had range(), so it's been range() for at least 10 years.
jjgreen 3y ago
Clearly an example of a parallel universe leaking into my own, can I come and live in yours? Please?
KaiserPro 3y ago
One of the things that I noticed when I started python (many many years ago) is that it crashed a lot more than perl. perl you really had to properly abuse it to make it actually crash. Now, some people see that as a feature not a bug (for either perl or python's behaviour)
kdklol 3y ago
Can confirm, recently written scripts require modification pretty much every minor version. Take the limit on the default size of BigInts now. Why? Just... why? I had to look into every script add the override line at the top (or check the entire script it ever assumes unlimited BigInt anywhere). No wonder there are still Python 2 scripts in use.

dmz73 3y ago

I wanted to like Python. Every time I tried to use/learn it, the "program" I wanted to use had some issue. The very first one (some 15 years ago) depended on mutually incompatible libraries so I had to spend time not only learning Python but fixing the libraries to work together. Next one was a dlna server that managed to use up all 4GB RAM available on my NAS and make the whole system unusable. Then there was a "compiler" that worked on all OS-es except that on Windows it would 100% not work due to some path string handling when starting a process. How do you even get to that point...that could have never worked on Windows and it's not like Windows is some marginal never used system so no testing was required. Then I tried to write a simple script to transfer some emails via IMAP...and Python idea of supporting IMAP is for me to read the RFC and build the correct string to sent to IMAP server...WTF???? That is the assembler lever of "support" of something. I did try to do that and then I ended up with multiple pages of something that looked like level of arcade game with climbing hills and cliffs of code where it was hard to tell if code was meant to end or if someone got bored of writing and just gave up. I hate Python.

anthk 3y ago
Heh. On Python and IMAP, getmail was dog slow against isync/mbsync. Same RAM issues.

Hamuko 3y ago

Deprecation doesn't really mean that your script is broken or going to break anytime soon. unittest.UnitTest.assertEquals() has been deprecated since 2011-02 (Python 3.2) and is set to be actually removed 2023-10 (Python 3.12).

jjgreen 3y ago
Not always, but for the sake of your sanity you need to fix those deprecations, if only so you can see the new ones, one of which will break your script at some point.

tokai 3y ago

What? The Perl 6 debacle has gone down even worse than Python 3.

G3rn0ti 3y ago
Perl 6 took longer than expected but „Raku“ is alive and well. It even moved into the Tiobe-Index at rank #48 recently: https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ This whole Python/Perl competition was always a bit silly. Both languages had and have their place. I would say Python is so much more popular because it found a niche in ML because of how much more easy it is in Python to interface fast C modules. So you get to write simple Python programs leveraging blazingly fast math libraries. That was always a bit more tricky to do in Perl. But Python as a language is definitely not as flexible as Perl 5. Last time I checked Python didn’t even support multi-line lambdas because its inventor hates those. Python is very much designed in a top-down approach and tries to guide all Python programmers into how there are supposed to solve their problems. Perl 5 was designed with its famous „easy things should be easy, hard problems possible to solve” philosophy. It allows for meta-programming in all the right places which a seasoned Perl developer can reach to when necessary. Perl 5 is a nice middle way between C and Lisp. That being said modern JavaScript turned into a powerful language that fits well into both the frontend and backend side of a web application nowadays and, hence, kind of replaced Perl as glue language for the web. It will also push Python out of web backends at some point I believe.
- achileas 3y ago
  Having used Python and Perl professionally, I'd have to agree with really all of this. I just want to emphasize Python's niche in ML (since that's what I do with it mostly lately) - it was also helped by a large, early set of libraries specifically for ML that other languages either still don't have or are playing catch-up (Elixir), and its ease of use among academics, a lot of whom went straight from academia to industry.
b1c837696ba28b 3y ago
Really? Was Perl 5 deprecated with prejudice across ecosystems, forcing projects to work with a janky, still-evolving replacement well ahead of production-grade stability? Because the boot marks in my ass from the forced march to Py3 are still bleeding.

nerdponx 3y ago

Which feature? Deprecation warnings tend to be in place for several years before removal. There's a formal policy for it: https://peps.python.org/pep-0387/ https://peps.python.org/pep-0387/ > Unless it is going through the deprecation process below, the behavior of an API must not change in an incompatible fashion between any two consecutive releases. Python’s yearly release process (PEP 602) means that the deprecation period must last at least two years. In practice, it's usually longer than two years, except on features that were considered provisional in the first place.