3 ms·

In the Python community this is called the "dead batteries" problem, and the example I like to bring up is the csv sniffer: https://docs.python.org/3/library/c

In the Python community this is called the "dead batteries" problem, and the example I like to bring up is the csv sniffer: https://docs.python.org/3/library/csv.html#csv.Sniffer https://docs.python.org/3/library/csv.html#csv.Sniffer This feature runs some heuristics and invents a new dialect of CSV based on a sample of the file. That should send chills down your spine, there is literally no safe way to use this thing. Using it in production is a bug in and of itself and will likely lead to security issues.

pjmlp 4y ago
I rather use a dead battery that somehow helps me doing my work, even if with a couple of warts, than trying to see how random package gets compiled on platform XYZ.
- maxbond 4y ago
  Totally understand not wanting to spend time vetting dependencies. For what it's worth, most packages "just work" on most platforms. My experience with WASM and microcontrollers is fairly limited, but I haven't had too much trouble there either. Or at least, less trouble than I would've anticipated.
  - pjmlp 4y ago
    Lets say I instal Python package for IBM I, I am sure that the standard library is supported. How many Rust packages work on IBM i? IBM i was a random example, there are plenty of platforms out there.
    - maxbond 4y ago
      If Rust added support for that operating system, than all of the packages that didn't rely on platform specific features would work (which is to say, virtually all of them). As it is, I'd speculate that with some fiddling you could probably get them working there today, but you'd have to repeat that every time you wanted to move to a new version of Rust. That isn't really a function of whether or not the language is batteries included, and making it batteries not included can make porting the language to new platforms simpler. But if you're working in an environment where Rust support is poor and Python support is rich, then yeah it totally makes sense to choose Python over Rust, I'm not any sort of absolutist.
      - pjmlp 4y ago
        That isn't the point, rather it is hit-and-miss with external libraries.
        maxbond 4y ago
        I've not had the experience that Rust libraries rely on platform specific behavior (ignoring things that specifically expose the capabilities of a platform specific like a HAL crate or an io_uring crate). I've had far less trouble than I anticipated getting up and running in embedded and WASM contexts. Have you had a different experience that's leading you to these views?
        pjmlp 4y ago
        As mentioned, assuming rustc and cargo exist for IBM i, what will cargo build on any random project do?
        maxbond 4y ago
        Well, I responded to this hypothetical, so I guess we just disagree.
bigbillheck 4y ago
Python deprecates stuff all the time. I got bit by this just last week when dusting off some old code and trying to update it from 3.7 only to find out that it's broken because stuff got moved around and now some imports don't work.

pjmlp 4y ago

I rather use a dead battery that somehow helps me doing my work, even if with a couple of warts, than trying to see how random package gets compiled on platform XYZ.

maxbond 4y ago
Totally understand not wanting to spend time vetting dependencies. For what it's worth, most packages "just work" on most platforms. My experience with WASM and microcontrollers is fairly limited, but I haven't had too much trouble there either. Or at least, less trouble than I would've anticipated.
- pjmlp 4y ago
  Lets say I instal Python package for IBM I, I am sure that the standard library is supported. How many Rust packages work on IBM i? IBM i was a random example, there are plenty of platforms out there.
  - maxbond 4y ago
    If Rust added support for that operating system, than all of the packages that didn't rely on platform specific features would work (which is to say, virtually all of them). As it is, I'd speculate that with some fiddling you could probably get them working there today, but you'd have to repeat that every time you wanted to move to a new version of Rust. That isn't really a function of whether or not the language is batteries included, and making it batteries not included can make porting the language to new platforms simpler. But if you're working in an environment where Rust support is poor and Python support is rich, then yeah it totally makes sense to choose Python over Rust, I'm not any sort of absolutist.
    - pjmlp 4y ago
      That isn't the point, rather it is hit-and-miss with external libraries.
      - maxbond 4y ago
        I've not had the experience that Rust libraries rely on platform specific behavior (ignoring things that specifically expose the capabilities of a platform specific like a HAL crate or an io_uring crate). I've had far less trouble than I anticipated getting up and running in embedded and WASM contexts. Have you had a different experience that's leading you to these views?
        pjmlp 4y ago
        As mentioned, assuming rustc and cargo exist for IBM i, what will cargo build on any random project do?
        maxbond 4y ago
        Well, I responded to this hypothetical, so I guess we just disagree.

bigbillheck 4y ago

Python deprecates stuff all the time. I got bit by this just last week when dusting off some old code and trying to update it from 3.7 only to find out that it's broken because stuff got moved around and now some imports don't work.