4 ms·

Honestly it's kinda disappointing that the CGI library would not be included in Python if proposed today. Why would wsgiref get included then? I get the argume

by rtpg 5y ago

Honestly it's kinda disappointing that the CGI library would not be included in Python if proposed today. Why would wsgiref get included then? I get the arguments for a small standard library in theory, but given how absolutely nightmarish it is to deal with python requirements in a "will work every time" way, I don't know where we end up with the Python standard library in general. Not making a slippery slope argument for the list of packages in this change. Just like, even when languages like Rust build for the ground up with good package management, everything requires 1000 different packages and it's a whole thing. So if you don't have a great way of shipping dependencies, and on top of that the standard library is in "please don't let me get bigger", it makes me a bit sad.

samhw 5y ago
This is an argument for good package management. There’s no way around it. You can’t add everything anyone could ever hypothetically need into the standard library, just because Pip is rubbish. (I mean, I don’t care. I use Rust. I’m just arguing on behalf of the poor people who are still abused by their employers, or wacky enough to voluntarily choose to use Python.)
- rtpg 5y ago
  I use Rust and Python, and I don't believe that Rust's strategies regarding standard libraries are great either. And let's not talk about Javascript "in order to use CSS with Webpack you need to download this 20 line package with its own release cycle"-style noncense. I do believe that package management solutions are needed. But I also think that a big standard library is A Good Thing, especially in a universe where some random micro-package will just lose its maintainer and cause 100 knock-on effects.
  - dragonwriter 5y ago
    > But I also think that a big standard library is A Good Thing, especially in a universe where some random micro-package will just lose its maintainer and cause 100 knock-on effects. Standard libraries have the same problems; in fact, part of the reason these are being removed from Python's stdlib is...they don't have maintainers.
    - rtpg 5y ago
      What I have had a lot of is that infra fixes (like "oh this is now a keyword in the latest Python release, there's a trivail fix") just ends up not happening and then your packages are all in limbo. I understand not having maintainers for actual bug fixes of tricky things. But the "maintainer disappearing" scenario has almost always been just for keeping things running. And in particular people show up with patches! Just well... some arbitrary person was a maintainer, is no longer there, and now there are bunch of people who would love to do most of the work. I think that "lack of succession strategies" is what really gets these packages, rather than the lack of willing maintainers. Combine that with deep dependency trees and you have a lot of stuff that needs to happen. I get it though. And I maintain some packages but I don't get involved in standard library shenanigans cuz my imagination is there's a lot of friction there. Just I like that things will probably be there for a while if its in the standard library.
  - lmm 5y ago
    A large "standard platform" may be a good thing, but it should definitely be decoupled from the language proper. (And personally I would say Javascript is doing it better than most languages on the library management front).
    - samhw 5y ago
      Eh, it's hard to talk about JavaScript because of all the different layers. My personal take is: JavaScript itself (ECMAScript) is an ugly and flawed but clearly generally productive language; Node is a work of art; NPM is horrendous with near-to-no redeeming qualities. TypeScript redeems lots of the problems with JavaScript, and I'm hopeful that Deno will ameliorate a lot of the problems with NPM (Yarn is good for what it is, but barely covers 3% of the necessary changes). Also, an honorary mention for ESBuild (and the lesser-known SWC, extremely similarly optimal but eking out a small win due to Rust's advantages over Go). Both of them are terrific improvements over the extant tooling.

by rtpg 5y ago

samhw 5y ago

This is an argument for good package management. There’s no way around it. You can’t add everything anyone could ever hypothetically need into the standard library, just because Pip is rubbish. (I mean, I don’t care. I use Rust. I’m just arguing on behalf of the poor people who are still abused by their employers, or wacky enough to voluntarily choose to use Python.)

rtpg 5y ago
I use Rust and Python, and I don't believe that Rust's strategies regarding standard libraries are great either. And let's not talk about Javascript "in order to use CSS with Webpack you need to download this 20 line package with its own release cycle"-style noncense. I do believe that package management solutions are needed. But I also think that a big standard library is A Good Thing, especially in a universe where some random micro-package will just lose its maintainer and cause 100 knock-on effects.
- dragonwriter 5y ago
  > But I also think that a big standard library is A Good Thing, especially in a universe where some random micro-package will just lose its maintainer and cause 100 knock-on effects. Standard libraries have the same problems; in fact, part of the reason these are being removed from Python's stdlib is...they don't have maintainers.
  - rtpg 5y ago
    What I have had a lot of is that infra fixes (like "oh this is now a keyword in the latest Python release, there's a trivail fix") just ends up not happening and then your packages are all in limbo. I understand not having maintainers for actual bug fixes of tricky things. But the "maintainer disappearing" scenario has almost always been just for keeping things running. And in particular people show up with patches! Just well... some arbitrary person was a maintainer, is no longer there, and now there are bunch of people who would love to do most of the work. I think that "lack of succession strategies" is what really gets these packages, rather than the lack of willing maintainers. Combine that with deep dependency trees and you have a lot of stuff that needs to happen. I get it though. And I maintain some packages but I don't get involved in standard library shenanigans cuz my imagination is there's a lot of friction there. Just I like that things will probably be there for a while if its in the standard library.
- lmm 5y ago
  A large "standard platform" may be a good thing, but it should definitely be decoupled from the language proper. (And personally I would say Javascript is doing it better than most languages on the library management front).
  - samhw 5y ago
    Eh, it's hard to talk about JavaScript because of all the different layers. My personal take is: JavaScript itself (ECMAScript) is an ugly and flawed but clearly generally productive language; Node is a work of art; NPM is horrendous with near-to-no redeeming qualities. TypeScript redeems lots of the problems with JavaScript, and I'm hopeful that Deno will ameliorate a lot of the problems with NPM (Yarn is good for what it is, but barely covers 3% of the necessary changes). Also, an honorary mention for ESBuild (and the lesser-known SWC, extremely similarly optimal but eking out a small win due to Rust's advantages over Go). Both of them are terrific improvements over the extant tooling.