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.
“Python's batteries are leaking”
181–190 of 420 posts
Re: “Python's batteries are leaking”
#182I remember one of Go's core devs voicing some of the same concerns regarding the SMTP-library [0] a while back.
Re: “Python's batteries are leaking”
#183Earlier 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
Re: “Python's batteries are leaking”
#184Earlier 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.
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”
#185The 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…
Re: “Python's batteries are leaking”
#186She 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…
Re: “Python's batteries are leaking”
#187Earlier 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.
Re: “Python's batteries are leaking”
#188Earlier 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.
Re: “Python's batteries are leaking”
#189Earlier 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.
Re: “Python's batteries are leaking”
#190The 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'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