Live data from Hacker News

“Python's batteries are leaking”

pyfound.blogspot.com

181–190 of 420 posts

Re: “Python's batteries are leaking”

#181
post #173

I like python, its a nice simple language that you can use to pump out a proof of concept real quick with little hassle, but for full on production I avoid it. But I think this is a larger trend in programming, in my opinion the majority of programmers are super lazy. Everyone is in a mad dash to get the cool new thing out so they just slap a bunch of dependencies on it and damn the consequences of developer debt dow…

> More people would rather roll with an MVP as the final product than build something from scratch that's more robust, resilient, and efficient. Well, yeah, of course. It's expensive to reinvent the wheel.

Its more expensive trying to fix broken code and working around other work arounds that should not be in production. Slows you down, bloats your code, makes it harder for new employees to learn the system when they come on board, etc.

Re: “Python's batteries are leaking”

#182
Isn't part of the issue mixing general purpose code that doesn't change very often (the kind that belongs in a standard library) with code that changes all the time (the kind that belongs on PyPI)?

I remember one of Go's core devs voicing some of the same concerns regarding the SMTP-library [0] a while back.

https://golang.org/pkg/net/smtp/

Re: “Python's batteries are leaking”

#183
post #156
post #60

Earlier quoted context omitted.

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

The default "Anaconda" install is like 7Gb after it grabs everything. Turnkey if you're using all that stuff anyway, but otherwise not particularly worth it. Miniconda on the other hand I'm finding meets my needs exactly. The base install is standard.

Re: “Python's batteries are leaking”

#184
post #158

Earlier quoted context omitted.

> 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.

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

Well, yeah, but you're not going to have much of a language at all if you optimize for quality of life of the language maintainer.

Re: “Python's batteries are leaking”

#185
post #174

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…

Requests depends on urllib3 which would also have to go into the stdlib. It also contains a CA bundle which the core devs don’t want to do. It also likely the internal implementation doesn’t follow core dev standards and practices, a common problem with integrating external libs. Finally there’s a risk it would slow or discourage new feature development by tying it to the core release cycle. A better approach might b…

That makes sense; if it makes any difference I don’t necessarily mean “take code from X and drop it in” so much as “if the consensus appears to be that the X api is better then add that to stdlib”. I like that notion of adding the X api, or parts thereof, And then having a third party X+ package. Maybe I just like the idea of something I built being “worthy” of stdlib.

Re: “Python's batteries are leaking”

#186
post #60
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…

https://wiki.python.org/moin/PythonDistributions

Re: “Python's batteries are leaking”

#187

Earlier quoted context omitted.

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.

There is one major difference: an abandoned external package may break with newer python versions, whereas you can always count on stdlib packages being updated for new versions.

Re: “Python's batteries are leaking”

#188
post #156

Earlier quoted context omitted.

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

not likely IMO. i've found conda - which is their environment management tool - to be a hassle unless one needs specific numpy/scipy/GPU libs. i'm using pipsi and pew, although i'll look into pyenv.

Former conda dev lead here. Definitely interested in more details regarding what part of the conda experience you found to be a hassle, if you’re willing to share.

Re: “Python's batteries are leaking”

#189

Earlier quoted context omitted.

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

There is one major difference: an abandoned external package may break with newer python versions, whereas you can always count on stdlib packages being updated for new versions.

exactly. and i'm in academic software. its even worse.

Re: “Python's batteries are leaking”

#190

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…

> Does anyone have a curated version of PyPI?

I'm not entirely sure what you're looking for, but have you tried https://www.enthought.com/product/enthought-deployment-manag... ?

Edit: example

    $ edm envs create tester36 --version 3.6
    $ edm shell -e tester36
    (tester36) $ edm install ipython matplotlib pyqt
Post reply on HN