“Python's batteries are leaking” • Hacker News Board

Re: “Python's batteries are leaking”

#151

Post by liability » Sat, May 18, 2019, 10:20 PM UTC

tanilama wrote: post #83

> Brown called out the XML parser and tkinter in particular for making the standard library larger and harder to build, burdening all programmers for the sake of a few Tkinter needs to go...There is very little reason except for the legacy ones, why it needs to be there still...

If Tkinter goes, then Python is dead to me. I use Python for small dep-free single file GUIs for small projects meant to be used by people who have Python installed but can't be bothered to go through an installation checklist. Tkinter is great for that and is the only reason I bother using Python for anything.

Re: “Python's batteries are leaking”

#152

Post by wirrbel » Sat, May 18, 2019, 10:20 PM UTC

mjw1007 wrote: post #50

If your project has any third-party dependencies, and so (nowadays) you're going to set up requirements.txt and virtualenv and whatever anyway, I can see that you're going to think things like "this XML parser in the standard library is just getting in the way; I can get a better one from PyPi". But I think a lot of the value of a large standard library is that it makes it possible to write more programs without need…

Last week I have written a Python script purely relying on the stdlib. Basically a coworkers shell script had to be adjusted to account for newer datafiles I was processing and I am not that experienced with shell script magic. I typed down 15 lines of Python code only relying on the std lib and was happy, it ran on the server's 2.x Python without an issue. This is the primary selling point of a larger std. library.

But, I do wonder whether it needs to grow. Python is in a stage where adoption of new std library features is inherently slow, not only in third-party libraries like twisted, but also in applications, even if they use newer Python versions.

What kills Python here is that it is most commonly bundled with the linux distribution or the OS (true also on mac). This reduces cycle times drastically. Compare this to newr language platforms that people like to install in newer versions on older platforms quite regularly.

Some recent additions would be fine additions at an early stage of language development, but surely not for Python.

Re: “Python's batteries are leaking”

#153

Post by debatem1 » Sat, May 18, 2019, 10:21 PM UTC

stochastastic wrote: post #108

The Python standard library has been a huge help for me. Evaluating which third party packages to trust and handling updates is a hassle. (Would love a solution for this. Does anyone have a curated version of PyPI?) I’m surprised that people want to slim it down other than for performance on a more constrained system. As an aside, why doesn’t the Python standard library extend/replace features with code from successf…

The quote about the stdlib being "where packages go to die" was, for a long time, considered a feature and not a bug. The theory was that once a package is in the stdlib its development should slow to prioritize stability over new features.

This may somewhat explain why lots of successful packages are not in the stdlib: putting them in effectively killed future development until a few years ago. But today that argument is inconsistently applied and I'm not sure if it's a rule worth keeping.

Re: “Python's batteries are leaking”

#154

Post by jsmeaton » Sat, May 18, 2019, 10:22 PM UTC

alexdong wrote: post #109

tptacek wrote: post #88

Earlier quoted context omitted.

Is "embrace PyPI and move things like asyncio there" not a constructive suggestion, or is she sort of being penalized because the most reasonable solution to the problem can be described in less than half a sentence so it's seems like there's more complaint than solution?

Yup. Totally agree with you on that. And yes this one is a constructive proposal. My problem is on the like part. Where shall we draw the line and how do we decide? To me this is a far more interesting discussion. (Maybe it has happened. I don’t go to many conferences these days so I might be missing something here. ) She mentioned http.client vs requests, datetime vs. moments etc, which are also quite correct to me.…

I thought the title was very clever. I associated the leaking with “leaky abstraction” more than anything.

Re: “Python's batteries are leaking”

#155

Post by pfranz » Sat, May 18, 2019, 10:22 PM UTC

will4274 wrote: post #121

What's the point of saying that a standard library feature was not added soon enough? Nobody can go back in time and add it earlier. I can complain to death about features missing from C++11 or I can start using C++14.

I think the point is that if those things in stdlib were external packages then older versions of the language would be easier to support because you could just update the package. I think the way it was phrased made it really easy to misunderstand.

I think this goes to her point of Twisted wanting to support really old versions of Python and they would be a lot more comfortable not supporting really old versions of packages.

Re: “Python's batteries are leaking”

#156

Post by imiric » Sat, May 18, 2019, 10:24 PM UTC

jzl wrote: post #60

avar wrote: post #45

She seems to be advocating that Python do pretty much what Perl has ended up doing, which is "we have some batteries, but we haven't been adding new ones for a decade or more". The reasons are similar, it's a constant drag on core compiler development to need to support various batteries included that most core contributors aren't going to care about, so it's easier to tell people "use CPAN". There was even talk of "…

The idea of "distros" for python is interesting, and to a certain extent has already happened: just look at Anaconda. I've been using built-in environment isolation tools such as virtualenv for ages but have recently switched over to using miniconda for all things python. Among other things it has amazing support across all three major OS's, and I happen to be dealing with all three at any given time. Whether one use…

As a non-scientific user of pyenv[0], would I benefit from switching to Anaconda/miniconda?

[0]: https://github.com/pyenv/pyenv

Re: “Python's batteries are leaking”

#157

Post by esotericn » Sat, May 18, 2019, 10:28 PM UTC

Most of this post seems to revolve around the idea of py2 having an outdated standard library.

https://pythonclock.org/ has Py2 reaching EOL in 7 months. Realistically I'd say the time passed years ago.

py3 is over ten years old now. We're not talking about some new unstable piece of kit, I'd imagine that a large percentage, perhaps even 50%, of the HN audience started their career after the transition had already started.

Re: “Python's batteries are leaking”

#158

Post by avar » Sat, May 18, 2019, 10:30 PM UTC

dragonwriter wrote: post #143

avar wrote: post #141

Earlier quoted context omitted.

I don't mean OS distributors can't package up CPAN modules. They can do that, no problem, same for the Python equivalents. I mean that a significant use people get out of Python and Perl is that they aren't bare-bones like say Scheme or Lua where the standard library is really spartan. It allows you to write useful code that works on the lowest common denominator of "just OS Perl or Python". Whether that's some rando…

> Which is why the "let's ship a bare-bones compiler and have people use CPAN or PyPi" is contentious. But you don't have to ship just a bare-bones interpreter to deal with the problem of stdlib staleness, you just need the stdlib libraries to be updatable via package manager, you don't need to not ship a baseline version of them with the interpreter. That doesn't deal with the bloat issue raised with relatively unus…

Sure, in Perl these are called "dual-life" modules. It makes things easy for users, but makes the life of the compiler-maintainer worse.

Now not only do they need to ship a stable compiler+large-stdlib, but they can't even rely on there being a 1=1 version relationship between the two, instead it'll be many=many as users might use multiple library versions with multiple compiler versions.

Re: “Python's batteries are leaking”

#159

Post by falcor84 » Sat, May 18, 2019, 10:34 PM UTC

jonnycomputer wrote: post #130

stochastastic wrote: post #108

The Python standard library has been a huge help for me. Evaluating which third party packages to trust and handling updates is a hassle. (Would love a solution for this. Does anyone have a curated version of PyPI?) I’m surprised that people want to slim it down other than for performance on a more constrained system. As an aside, why doesn’t the Python standard library extend/replace features with code from successf…

I've come to use packages outside of the standard library very sparingly; been burned too many times to find that development of some package stopped or slowed down and backing out can be a real pita.

What is your argument here? Standard library module development is also extremely slow.

Re: “Python's batteries are leaking”

#160

Post by detaro » Sat, May 18, 2019, 10:37 PM UTC

esotericn wrote: post #157

Most of this post seems to revolve around the idea of py2 having an outdated standard library. https://pythonclock.org/ has Py2 reaching EOL in 7 months. Realistically I'd say the time passed years ago. py3 is over ten years old now. We're not talking about some new unstable piece of kit, I'd imagine that a large percentage, perhaps even 50%, of the HN audience started their career after the transition had already st…

You read that wrong. Most of the points apply to Python 2 and 3 equally, or even only to Python 3. (obviously with the exception of the one of Python 2 not having gotten some useful bits, but the pattern continues)