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.
“Python's batteries are leaking”
121–130 of 420 posts
Re: “Python's batteries are leaking”
#122Wow this is not the conduct I expect from a language creator. I don’t care if you’re Albert Einstein. Humility and being able to take criticism is far more admirable to me.
We weren't there. He might've needed to be someplace else.
People leave all the time during talks, and I've been to talks where most people left as soon as Q&A started.
Re: “Python's batteries are leaking”
#123I'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…
You're trading things to update. Either the bug is in the standard library and you need to update the standard library or the bug is not in the standard library and you need to update not-the-standard-library. Either way, the maintainer of the library can't get everybody to upgrade.
Re: “Python's batteries are leaking”
#124She 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 "…
That problem does not seem to happen with the Haskell Platform. Maybe it's because GHC has almost no batteries at all, so nobody thinks it's sufficient, or maybe it's because distros get it in a single package, so it does not feel like installing 100 libraries.
Re: “Python's batteries are leaking”
#125I'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…
> What happens if you discover a security vulnerability in your stdlib?
As the user of the stdlib, it really depends on what the security issue is. For most users, if they can verify they're not using module X, then there's no problem and no rush for them to upgrade. In a language like Python that's very dynamic, you also might be able to download a hotfix .py file provided by the language maintainers (or any other party) as an alternative to upgrading, or as something for the interim while you wait for the upgrade to get released, backported and released for older major versions, and available for the deploy environment -- this might even take the form of an iptables rule, depending on the issue. In short my point is that there are alternatives besides bumping one release's release version and hoping people upgrade.
> Except, users don't upgrade stuff.
Actually users do. Not all users, but your sweeping statement isn't true of all users either. Experience and reading reports tell me that many if not most users actually upgrade, especially when there's a significant security issue and especially when upgrading is easy. 2.7.14 to 2.7.15 was a problem for no one.
For the users who don't upgrade, they're not likely to upgrade a third party / split off thing any more than the core language.
There's also another party of users worth mentioning, those that don't upgrade specific things because past upgrades have been a terrible experience. This is a reputation issue.
> 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.
Sucks for whom? I've been out of the Node ecosystem for several years, is there a pfs module that uses promises (either built-in or as an external lib)? If so users can use that if they want. Does it suck for the maintainer? I don't see how if those functions are small and don't really need any maintenance.
What would suck is if all the existing programs that wrote some fs-using code a long time ago and haven't had to touch it now suddenly need to go update it to satisfy people's fashions.
You might be interested in this talk that makes the case to stop breaking your API especially if you're requiring more and providing less. https://www.youtube.com/watch?v=oyLBGkS5ICk
Re: “Python's batteries are leaking”
#126I 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.
Coupled with weak infrastructure around third-party library selection. npms.io has a "quality" score (which npm pulled in recently), but that magick number includes things like download counts, if the homepage is on a custom domain (!?) and if the readme has badges (!!?). It doesn't include code quality metrics, if the package or git repo is using GPG signing, or clear signs of abandonment, like N ignored PRs, or N,000 ignored open issues.
I've been astounded how few non-trivial packages are actually in a consumable state, and how many seemingly-simple packages have N dependencies that pull in M more. By and large it's a zombie wasteland of cruft.
I wouldn't really trust only-crowdsourced ratings, but I think that might be a nice component for npms.io to include, perhaps. Stackoverflow answers, for example, seem to be directionally correct if you sort by upvote count.
Re: “Python's batteries are leaking”
#127If 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…
What they need is an Apache Commons or Guava of Python. They're both defacto part of the standard java library.
I try to avoid Guava because they have a habit of making incompatible breaking changes, and because so many libraries depend on it, it's likely to cause version conflicts. The way Apache Commons puts the major version in the package is much better in that regard.
Re: “Python's batteries are leaking”
#128> She thinks that some bugs in the standard library will never be fixed. This is actually an interesting paradox to be in, and one that Linus Torvalds recently commented on. His focus, like Guido’s, is the user and even fixing a bug can break the user. https://lkml.org/lkml/2018/8/3/621
This isn't a paradox. once it's released it's not a bug anymore, it's just behaviour. document the behaviour, but breaking compatibility with previous versions is a bug. it doesn't matter how obviously wrong the previous behaviour is.
> but breaking compatibility with previous versions is a bug
That's how you get an inconsistent mess that never evolves. There's something called semver, increase the version number and do the fix / refactors / radical redesign / whatever. People will see that you've went from version 1.0 to 87.3 in one year and they may choose not to use your thing because you're moving too fast for them, but that's life...
Re: “Python's batteries are leaking”
#129Earlier quoted context omitted.
> 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 under…
In that case the right thing to do is to make it clear that you're not prioritizing number of users, you're not here to solve problems for users other than yourself at least in the short term (because you're interested in pursuing your vision, not implementing feature requests from people without good taste), and that you're not trying to take everyone's feedback into account. Then people stop expecting you to do mor…
I think the tone of your post seems to imply that writing languages in some quasi-democratic (rather than oligarchic/dictatorial/elitist) way is or should be default. In fact, those assumptions are not the default (I can't think of any languages that are truly democratic, certainly most big ones aren't). Nor should it work like that imo, we don't design power plants by referendum. We put experts in a room, probably with a dictatorial decision maker and everyone else can whistle (or at least would really have to shout loud and be clearly right to be heard).
Also, if you're going for max language usage through design, how do you do that? By trying to perfect your design, so it's kind of an irrelevant motivator. Rich got a ton of clojure users (relative to his resources), he did that by having strong (reasoned) beliefs, not by opening the floor to a vote. Rich did /not/ say that he was only building Clojure only for his company, that's a very misleading statement that you've made.
Re: “Python's batteries are leaking”
#130The 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.