4 ms·

Another rule of thumb would be: "How many years from now do you still want this to work?" If I run a shell script I wrote ten years ago, it works. If I run a Py

by scbrg 7y ago

Another rule of thumb would be: "How many years from now do you still want this to work?" If I run a shell script I wrote ten years ago, it works. If I run a Python script I wrote ten years ago, it's quite likely to fail with a SyntaxError. This, I say as someone who loves Python and I use it as my primary language both privately and at work. But I have to admit, Python scripts do not really age well.

np_tedious 7y ago
I'm really struggling to think of an example that doesn't involve py2 --> py3. Can you share a few?
- scbrg 7y ago
  Well, py2 -> py3 is obviously one. Before that, well it's been a while. But with and yield were added as a keywords (breaking any code using them as a variables). The xreadlines module disappeared at some point (I'm sure a few other modules have died along the way). At some point you couldn't raise anything you wanted as exceptions any more. Oh, and the source encoding declaration. That's what I remember off the top of my head. Minor things that are handled in things that are maintained, sure. But many things are also built once and then expected to run for a long time - especially in the role shell scripts usually fill. Note, that I don't argue that any of these changes were bad. They were all good changes that made the language better. But, they resulted in old code breaking. One extra headache to deal with for the poor schmuck that was responsible for upgrading this server or that to the latest OS release.
- edoceo 7y ago
  I had one like that, years ago, in a 2.3 to 2.7 environment update. Had to just update a few lines. But, we knew to watch for it in test, cause we knew of the update. We test our she'll scripts too, when the env changes. Anecdotally the Py is slightly more touchy than Bash
bsder 7y ago
> If I run a shell script I wrote ten years ago, it works. I'll provide the counterexample. Any scripts I wrote more than 10 years ago for actual "Bourne shell" /bin/sh often fail in mysterious (and sometimes silent) ways when run under bash. Bash is just as guilty of backward incompatibility as Python is. Python at least generally has the decency to squawk about it.
- scbrg 7y ago
  Well, I won't argue with that. When I say shell script, I mean POSIX. I never write bash scripts (although admittedly, I do miss pipefail).
acdha 7y ago
I haven't really found that to be a problem, with some code I still use daily which was started before Python 3.0 was released. The py3 transition was real but it was also something which took seconds to run through futurize/modernize. Over the years I've spent way more time going into inconsistencies about the various platform tools (e.g. GNU vs. BSD implementations of sed, grep, find, etc. even before you ge to the space aliens-with-broken-translators realm of AIX) — which using Python avoided needing to care about — or library / file naming changes. Similarly, a few years back there was way more time used when various HTTPS improvements flushed out code using old versions of OpenSSL or, worse, gnutls.
- scbrg 7y ago
  I'm glad you mentioned SSL. Because hey - that broke some scripts in 2.7.9 ;-) https://www.python.org/dev/peps/pep-0466/ https://www.python.org/dev/peps/pep-0466/ (Can't remember the details, but it may have been something about some extra hoop you'd have to jump through to trust self signed certs that broke our testing infrastructure)
  - acdha 7y ago
    Totally agree - I just don’t see that as a distinguishing factor since we had a bunch of shell scripts break, too, as various CLI tools stopped behaving consistently.
    - scbrg 7y ago
      I guess this is a YMMV thing. My experience is that Python rots more than shell scripts, but of course I understand that this may not be universally true, and depends a lot on what your scripts actually do (and, to a large extent, on how they're written, of course).

by scbrg 7y ago

np_tedious 7y ago

I'm really struggling to think of an example that doesn't involve py2 --> py3. Can you share a few?

scbrg 7y ago
Well, py2 -> py3 is obviously one. Before that, well it's been a while. But with and yield were added as a keywords (breaking any code using them as a variables). The xreadlines module disappeared at some point (I'm sure a few other modules have died along the way). At some point you couldn't raise anything you wanted as exceptions any more. Oh, and the source encoding declaration. That's what I remember off the top of my head. Minor things that are handled in things that are maintained, sure. But many things are also built once and then expected to run for a long time - especially in the role shell scripts usually fill. Note, that I don't argue that any of these changes were bad. They were all good changes that made the language better. But, they resulted in old code breaking. One extra headache to deal with for the poor schmuck that was responsible for upgrading this server or that to the latest OS release.
edoceo 7y ago
I had one like that, years ago, in a 2.3 to 2.7 environment update. Had to just update a few lines. But, we knew to watch for it in test, cause we knew of the update. We test our she'll scripts too, when the env changes. Anecdotally the Py is slightly more touchy than Bash

bsder 7y ago

> If I run a shell script I wrote ten years ago, it works. I'll provide the counterexample. Any scripts I wrote more than 10 years ago for actual "Bourne shell" /bin/sh often fail in mysterious (and sometimes silent) ways when run under bash. Bash is just as guilty of backward incompatibility as Python is. Python at least generally has the decency to squawk about it.

scbrg 7y ago
Well, I won't argue with that. When I say shell script, I mean POSIX. I never write bash scripts (although admittedly, I do miss pipefail).

acdha 7y ago

I haven't really found that to be a problem, with some code I still use daily which was started before Python 3.0 was released. The py3 transition was real but it was also something which took seconds to run through futurize/modernize. Over the years I've spent way more time going into inconsistencies about the various platform tools (e.g. GNU vs. BSD implementations of sed, grep, find, etc. even before you ge to the space aliens-with-broken-translators realm of AIX) — which using Python avoided needing to care about — or library / file naming changes. Similarly, a few years back there was way more time used when various HTTPS improvements flushed out code using old versions of OpenSSL or, worse, gnutls.

scbrg 7y ago
I'm glad you mentioned SSL. Because hey - that broke some scripts in 2.7.9 ;-) https://www.python.org/dev/peps/pep-0466/ https://www.python.org/dev/peps/pep-0466/ (Can't remember the details, but it may have been something about some extra hoop you'd have to jump through to trust self signed certs that broke our testing infrastructure)
- acdha 7y ago
  Totally agree - I just don’t see that as a distinguishing factor since we had a bunch of shell scripts break, too, as various CLI tools stopped behaving consistently.
  - scbrg 7y ago
    I guess this is a YMMV thing. My experience is that Python rots more than shell scripts, but of course I understand that this may not be universally true, and depends a lot on what your scripts actually do (and, to a large extent, on how they're written, of course).