4 ms·

I have a terrible admission to make: one of the reason I like Python is its huge standard library, and I like that because I just ... despise looking for librar

I have a terrible admission to make: one of the reason I like Python is its huge standard library, and I like that because I just ... despise looking for libraries, trying to install them, evaluating their fitness, and so on. I view dependencies outside of the standard library as a kind of technical debt, not because I suffer from Not Invented Here and want to code it myself, no, I look and think, "Why isn't this in the standard library with a working set of idioms around it?" I haven't developed anything with more than five digits of code to it, which is fine for me, but part of it is just ... avoidance of having to screw with libraries. Ran into a pip issue I won't go into (it requires a lot of justification to see how I got there) and just ... slumped over. This has been a bad spot in Python for a long, long time. While people are busy cramming their favorite feature from their last language into Python, this sort of thing has languished. Sadly, I have nothing to offer but encouragement, I don't know the complexities of packaging, it seems like a huge topic that perhaps nobody really dreamed Python would have to seriously deal with twenty years ago.

itake 4y ago
More packages in the standard library means it can run in less machines and more extra junk needs to be installed. Minimal standard library languages let you pick and choose what needs to be run. Golang is a nice happy medium since it’s compiled.
samwillis 4y ago
> despise looking for libraries, trying to install them, evaluating their fitness, and so on. This is exactly why I prefer the larger opinionated web frameworks (Django, Vue.js) to the smaller more composable frameworks (Flask, React). I don’t what to make decisions every time I need a new feature, I want something that “just works”. Python and Django just work, and brilliantly at that!
- deleted 4y ago
  [deleted]
- 5d8767c68926 4y ago
  Currently dealing with Flask and it makes me sad from the endless decision fatigue. Enormous variations in quality of code, documentation, SO answers, etc. To not even consider the potential for supply side attacks. With Django there is a happy path answer for most everything. If I run into a problem, I know I'm not the first.
mrweasel 4y ago
If requests and a basic web framework was in the standard library you’d effectively eliminate the majority of my dependencies. Honestly I doubt see the package management being an issue for most end-users. Between the builtin venv, conda and Docker I feel that the use-cases for most is well covered. The only focus area I really see is better documentation. Easier to read documentation more precisely. Perhaps a set of templates to help people getting start with something like pyproject. It feels like the survey is looking for a specific answer, or maybe it’s just that surveys are really hard to do. In any case I find responses to be mostly: I have no opinion one way or the other.
- rpcope1 4y ago
  Something like bottle.py would be an excellent candidate for inclusion. The real reason to avoid putting anything into the standard library is that it seems to often be the place where code goes to stagnate and die for Python.
  - at_a_remove 4y ago
    I am not sure why that has turned into a truism. Really good code in the standard library should reach a level of near perfection, then eventually transition into hopeful speed gains, after which you're really only changing that code because the language has changed or the specification has updated.
manuelabeledo 4y ago
This is one of the reasons why I don't quite like Node. It feels like everything is a dependency. It seems ridiculous to me that there isn't a native method for something as simple and ubiquitous as putting a thread to sleep, or that there is an external library (underscore) that provides 100+ methods that seem to be staples in any modern language. Python is nice in that way. It is also opinionated in a cohesive and community driven manner, e.g. PEP8.
qayxc 4y ago
> I view dependencies outside of the standard library as a kind of technical debt That's an interesting position. So are you suggesting that very specialised packages such as graph plotting, ML-packages, file formats, and image processing should be part of the standard library? What about very OS/hardware-specific packages, such as libraries for microcontrollers? There are many areas that don't have a common agreed-upon set of idioms or functionality and that are way too specialised to be useful for most users. I really don't think putting those into the standard library would be a good idea.
- at_a_remove 4y ago
  Hrm. Graph-plotting ... yes. File formats ... yes, as many as possible. Image processing, given the success of ImageMagick, I'd say yes there as well. I don't know much about ML to say. OS-specific packages, quite possibly. The thing about the standard library is that it is like high school: there's a lot of stuff you think you will never need, and you're right about most of it, but the stuff you do need you're glad you had something going, at least.
  - qayxc 4y ago
    ImageMagick is actually a good example: I use Python as my primary tool for shell scripting (I don't like "traditional" shell scripts for various reasons) - if I can use Python to control external tools such as ImageMagick, why would I want to include all its functionality, codecs, effects, etc. in the standard library? Including too much leads to a huge burden for the maintainers and consequently results in this: https://peps.python.org/pep-0594/ https://peps.python.org/pep-0594/ Quote: > Times have changed. With the introduction of PyPI (née Cheeseshop), setuptools, and later pip, it became simple and straightforward to download and install packages. Nowadays Python has a rich and vibrant ecosystem of third-party packages. It’s pretty much standard to either install packages from PyPI or use one of the many Python or Linux distributions. > On the other hand, Python’s standard library is piling up with cruft, unnecessary duplication of functionality, and dispensable features.

itake 4y ago

More packages in the standard library means it can run in less machines and more extra junk needs to be installed. Minimal standard library languages let you pick and choose what needs to be run. Golang is a nice happy medium since it’s compiled.

samwillis 4y ago

> despise looking for libraries, trying to install them, evaluating their fitness, and so on. This is exactly why I prefer the larger opinionated web frameworks (Django, Vue.js) to the smaller more composable frameworks (Flask, React). I don’t what to make decisions every time I need a new feature, I want something that “just works”. Python and Django just work, and brilliantly at that!

deleted 4y ago
[deleted]
5d8767c68926 4y ago
Currently dealing with Flask and it makes me sad from the endless decision fatigue. Enormous variations in quality of code, documentation, SO answers, etc. To not even consider the potential for supply side attacks. With Django there is a happy path answer for most everything. If I run into a problem, I know I'm not the first.

mrweasel 4y ago

If requests and a basic web framework was in the standard library you’d effectively eliminate the majority of my dependencies. Honestly I doubt see the package management being an issue for most end-users. Between the builtin venv, conda and Docker I feel that the use-cases for most is well covered. The only focus area I really see is better documentation. Easier to read documentation more precisely. Perhaps a set of templates to help people getting start with something like pyproject. It feels like the survey is looking for a specific answer, or maybe it’s just that surveys are really hard to do. In any case I find responses to be mostly: I have no opinion one way or the other.

rpcope1 4y ago
Something like bottle.py would be an excellent candidate for inclusion. The real reason to avoid putting anything into the standard library is that it seems to often be the place where code goes to stagnate and die for Python.
- at_a_remove 4y ago
  I am not sure why that has turned into a truism. Really good code in the standard library should reach a level of near perfection, then eventually transition into hopeful speed gains, after which you're really only changing that code because the language has changed or the specification has updated.

manuelabeledo 4y ago

This is one of the reasons why I don't quite like Node. It feels like everything is a dependency. It seems ridiculous to me that there isn't a native method for something as simple and ubiquitous as putting a thread to sleep, or that there is an external library (underscore) that provides 100+ methods that seem to be staples in any modern language. Python is nice in that way. It is also opinionated in a cohesive and community driven manner, e.g. PEP8.

qayxc 4y ago

> I view dependencies outside of the standard library as a kind of technical debt That's an interesting position. So are you suggesting that very specialised packages such as graph plotting, ML-packages, file formats, and image processing should be part of the standard library? What about very OS/hardware-specific packages, such as libraries for microcontrollers? There are many areas that don't have a common agreed-upon set of idioms or functionality and that are way too specialised to be useful for most users. I really don't think putting those into the standard library would be a good idea.

at_a_remove 4y ago
Hrm. Graph-plotting ... yes. File formats ... yes, as many as possible. Image processing, given the success of ImageMagick, I'd say yes there as well. I don't know much about ML to say. OS-specific packages, quite possibly. The thing about the standard library is that it is like high school: there's a lot of stuff you think you will never need, and you're right about most of it, but the stuff you do need you're glad you had something going, at least.
- qayxc 4y ago
  ImageMagick is actually a good example: I use Python as my primary tool for shell scripting (I don't like "traditional" shell scripts for various reasons) - if I can use Python to control external tools such as ImageMagick, why would I want to include all its functionality, codecs, effects, etc. in the standard library? Including too much leads to a huge burden for the maintainers and consequently results in this: https://peps.python.org/pep-0594/ https://peps.python.org/pep-0594/ Quote: > Times have changed. With the introduction of PyPI (née Cheeseshop), setuptools, and later pip, it became simple and straightforward to download and install packages. Nowadays Python has a rich and vibrant ecosystem of third-party packages. It’s pretty much standard to either install packages from PyPI or use one of the many Python or Linux distributions. > On the other hand, Python’s standard library is piling up with cruft, unnecessary duplication of functionality, and dispensable features.