Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Python's batteries are leaking”

pyfound.blogspot.com

Post reply on HN
Print view View original

51–60 of 420 posts

Re: “Python's batteries are leaking”

#51

Post by frou_dh »

nerdwaller wrote: post #19
jteppinette wrote: post #16

IMO, Golang does the best job of maintaining a high quality standard library. I disagree that modules should be moved into the external package ecosystem. However, Go isn't preinstalled on most systems like Python. I have to develop enterprise software that runs across a wide range of platforms, and being able to take advantage of the fact that Python is pre-installed on all of these systems with its standard library…

It’ll be interesting to see how Go (Rust, and other new languages) evolve and if they can avoid some level of package decay when they reach the age of Python, Java, etc.

Notably, a number of packages in the Go standard library have officially become "frozen":

https://www.google.com/search?q=site:golang.org/pkg/+"frozen...

Re: “Python's batteries are leaking”

#52

Post by zbentley »

epx wrote: post #38

Why is it so difficult to admit Node.js did the package thing right, by keeping a local folder just for the app, isolation from other apps with zero effort?

I think people conflate NPM-as-package-installation-system, which I would agree works very, very well (though a lot of that is the JavaScript module/import system in general and not NPM specifically), with two other things: NPM the web platform (which has had a lot of pretty severe security/community issues), and the JavaScript community's tendency to proliferate lots and lots of modules, many in competition, to solve problems that other languages' communities tend to solve either via reimplementation or via the standard library.

I think any discussion about NPM or JS packaging compared to other package managers needs to discuss those things as orthogonal, largely unrelated concepts. Otherwise everyone just picks a favorite punching bag (e.g. left-pad) and talks past each other.

Re: “Python's batteries are leaking”

#53

Post by _hardwaregeek »

I've wondered about standard libraries for a while now. What happens if you discover a security vulnerability in your stdlib? Presumably you'd have to bump the language version, deploy it out and beg users to upgrade. Except, users don't upgrade stuff. While if you version the standard library, every new project will get the newer version of the standard library. Sure, there's space tradeoffs, though you could offer a manual linking option. But at the very least, the amount of new projects with the vulnerability will be next to nil.

And what if the standard library just gets dated? Take Node for instance. The fs module has a whole bunch of outdated callback based functions. Sure, you can wrap them in promisify, but it sucks that we have these outdated functions stuck around forever.

There's definitely tradeoffs with package/dependency multiplication, but I don't think standard libraries are as clear cut as people make them out to be.

Re: “Python's batteries are leaking”

#54

Post by alexdong »

jMyles wrote: post #21

Guido is a good dude, through-and-through, despite his perhaps bad behavior here. Amber is nothing short of an open source hero, having brought Twisted, one of the best open source projects in the world, to new heights. Her insights are as important as anyone in the python community, and after six consecutive PyCons sprinting at the Twisted table (including literally in a chair with Amber to my left and Glyph to my r…

The problem with rants is it stings and it divides.

When it comes to constructive criticism, I think Amber did a good job with her criticism but can do better at the constructive front. Her problem statement was spot on and I agree that the direction she proposed is a good one.

However, to separate the standard library from the core is probably even more dramatic than the Python 2 to 3 migration. Is that what the community can afford at the moment? What's needed to make the transition? What's the opportunity costs? i.e. what other developments we can do for a bigger impact? What are the pros and cons?

Re: “Python's batteries are leaking”

#55

Post by pixelrevision »

nerdwaller wrote: post #19
jteppinette wrote: post #16

IMO, Golang does the best job of maintaining a high quality standard library. I disagree that modules should be moved into the external package ecosystem. However, Go isn't preinstalled on most systems like Python. I have to develop enterprise software that runs across a wide range of platforms, and being able to take advantage of the fact that Python is pre-installed on all of these systems with its standard library…

It’ll be interesting to see how Go (Rust, and other new languages) evolve and if they can avoid some level of package decay when they reach the age of Python, Java, etc.

I’ve been working with go a lot lately and they seem really focused on not letting this happen. Every single thing in the language and standard library seem completely focused on minimalism and compiler time. The standard lib is unlikely to change all that much and people are not picking the language for a bunch of convenience features.

Third party package problems will be an issue at some point but that’s more due to them be so focused on minimalism they don’t have clear guidance on setting up and maintaining packages.

Re: “Python's batteries are leaking”

#56

Post by geofft »

userbinator wrote: post #10
axaxs wrote: post #2

Why, time and time again, does Guido seem incapable of reasonable debate, or ideas that challenge his own? It's completely rude to interrupt a presenter with 'what is your point?' Years ago I was in contact with the author of Nuitka, who was very excited to share his work thus far. During his presentation, Guido kept huffing and making snide comments under his breath. All because he disagrees with the premise behind…

It seems that those programming language communities which have a more "social" aspect also tends to lead to more associated drama like this.

Seems like there might be some other confounding factors here:

- A language that is simply less active or whose users feel less ability to have a say in the language's development is going to be both less social and less dramatic, but also carries a high chance that existing users are only there for legacy reasons and are always considering moving to another language better suited for their purposes.

- A language run by a corporation is less "social," and has the drama play out in business negotiations, closed-door committee meetings, and lawsuits instead of on blogs and public mailing lists and (in this case) closed-door meetings with an expectation of public reporting.

I'm not aware of any drama in the ASP community, but that probably also had something to do with many users having picked Python for their next project instead of ASP. I'm aware of some drama in the Clojure community, the conclusion of which seems to have been that Clojure is their corporate sponsor's language and if it doesn't work for you you should find something else.

Re: “Python's batteries are leaking”

#57

Post by KaiserPro »

I clicked on this link think "uh oh standard ill informed rant post"

However brown has solid good points.

The brilliant selling point of python is the massive standard lib. If the quality of the libraries fall, then python's use as a tool drops dramatically.

One of Node's massive failures is that is has no standard lib.

Re: “Python's batteries are leaking”

#58

Post by lone_haxx0r »

geofft wrote: post #35
pavlov wrote: post #8

Earlier quoted context omitted.

Maybe he’s simply burnt out? The pressure of being in charge of something as big as Python must be intense. People make demands on his time and expect the “benevolent dictator” to cunningly solve everything like a modern day Salomon. I know he gave up the title, but as he personifies Python, I imagine the influx of requests for his attention may not have subsided much.

Nobody required him to be in charge of Python. Nobody required him to personify Python. Plenty of languages have succeeded without their creators handling every little detail, from C to JavaScript to PHP to Java. A core skill of any open-source project maintainer is recognizing when you're burnt out enough that your continued presence isn't helping the community and is just getting in the way of others, and stepping…

> Plenty of languages have succeeded without their creators handling every little detail, from C to JavaScript to PHP to Java.

Sure, if your definition of success is being used by as many people as possible, but there are other (more) important criteria for asserting the quality of a language.

When you have a vision for your project, you might be afraid that other people are going to ruin it, because they don't understand, or they don't have good taste, etc.

Re: “Python's batteries are leaking”

#59

Post by perlgeek »

_hardwaregeek wrote: post #53

I've wondered about standard libraries for a while now. What happens if you discover a security vulnerability in your stdlib? Presumably you'd have to bump the language version, deploy it out and beg users to upgrade. Except, users don't upgrade stuff. While if you version the standard library, every new project will get the newer version of the standard library. Sure, there's space tradeoffs, though you could offer…

> I've wondered about standard libraries for a while now. What happens if you discover a security vulnerability in your stdlib?

That depends on what you are writing.

For an application that is deployed stand-alone, you'll likely fat-package it with python and all the libraries. In case of a security issue, you create a new version of your application that bundles the fixed python.

For an application that is deployed on the system python (more typical on Linux), it's the system admin's task to update the system python.

Re: “Python's batteries are leaking”

#60

Post by jzl »

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 uses miniconda, pipenv, virtualenv, or anything else like it, as far as I am concerned the days of ever using the system python are over. I will always create my own personal "distro" on the fly with full control over the python version and every add-on package.

Post reply on HN