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

61–70 of 420 posts

Re: “Python's batteries are leaking”

#61

Post by mjw1007 »

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…

Aren't conservatism and minimalism pulling in opposite directions here?

Amber wants to remove asyncio from the standard library. That's minimalism but not conservatism.

Re: “Python's batteries are leaking”

#62

Post by jimnotgym »

bdcravens wrote: post #42
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.

Has DHH, Matz, Ryan Dahl, the Allaires, Larry Wall, or anyone else who founded a language or related-project been known for behaving like this?

Linus Torvalds has been known to, yes! He even took a little break to deal with it.

https://www.zdnet.com/article/linus-torvalds-takes-a-break-f...

Re: “Python's batteries are leaking”

#63

Post by zbentley »

0xbadcafebee wrote: post #41

It's funny to me that they're making a point that PyPI is better than core, because actually I think PyPI has created a rather crap ecosystem. The non-hierarchial organization of packages, the lack of curation, lack of inheriting past functionality and extending it as more standard functionality, etc has resulted in a confusing sprawl of packages with duplicate, incompatible, buggy functionality. It's a bit like Linu…

Wow, I've had a really opposite experience with CPAN modules. I've overwhelmingly found them to not respect encapsulation (messing with all sorts of global state, not mentioning that they're doing it, and failing to clean up after themselves or even provide the tools to clean up well), be massively inconsistent in their APIs, have messy and hard-to-parse documentation (still better than Python's conventions here, though), and have some really silly hierarchy-related decisions, most of which I suspect stem from inter-maintainer politics and infighting, of which I've observed a large amount.

Sure, I've found some gems on CPAN, but, having worked on both Perl, Python, and Java at reasonable scale for awhile, I cannot understand all the praise CPAN gets. It's the worst-quality scripting language package ecosystem out there. Even NPM does a better job, and some things about NPM are awful. CPAN might have been the first/only/best package manager for a get-shit-done scripting language at some point, but not any more.

Separately, I agree about modules which extend language functionality (e.g. class systems, async programming, runtime typing) specifically. Perl does pretty well in that area. While many of those language-extension modules really don't play well with any other metaprogramming tools being installed in the project, I don't imagine that any alternatives in other languages do, either. My main beef above is with "simple" (read: not pervasive semantics changes) modules like IPC utilities, HTTP clients, or loggers that don't know how to stay in their lanes.

Re: “Python's batteries are leaking”

#64

Post by hashhar »

I think the best model i have seen for a lean stdlib has been that of Golang. You have the standard lib and then you have the packages under Golang.org/x/ which are experimental packages that sometimes end up being merged into the core language. The stuff which is not in the stdlib (TOML, yaml etc.) have been supported very well by community packages.

Re: “Python's batteries are leaking”

#65

Post by nullwasamistake »

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…

What they need is an Apache Commons or Guava of Python. They're both defacto part of the standard java library.

Re: “Python's batteries are leaking”

#66

Post by twic »

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 "…

> There was even talk of "distros" for the interpreter. Where the core bits would be similar to what Linux is, and all the batteries would be provide as collections of add-on packages.

Not a million miles from the modularisation that Java has been going through.

Re: “Python's batteries are leaking”

#67

Post by guitarbill »

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…

the problem is it can fall apart quickly. the XML parsing in the standard library is limited and slow, so most people consume lxml instead [0]. so it depends on the case. counterpoint: e.g. pathlib being in included is great. it was at least inspired by 3rd party libraries, but the features are relatively stable and the scope defined, and relatively few dependencies, and so moving it into the standard library is a win IMO. not only for import ease, but for consistency.

[0] https://pypi.org/project/lxml/

Re: “Python's batteries are leaking”

#68

Post by gcb0 »

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 "…

And perl solved that perfectly: just let the OS/distro solve the 100s of packages. And it have been solved, despite you claiming otherwise on your last paragraph.

When did you have to use cpan in a modern system? Compare that to how many times you had to use pip.

Now, if you use a crappy OS or distro (or god forbid, some container built by you have no idea who on top of nobody knows what) then yeah, you are bound to do the leg work yourself, but you will be doing that regardless of the language/subsystem you are trying to use in that case.

Not to mention that it is the only way to do things professionally. For example, if you must have a system that parses XML but for company policy is not allowed to have even the means of performing a network request. With python you either have both xml and an http library and whatever else included and you will either have to do a special package with a striped down python+xml only or get a corporate exception. While on other languages you can install only the xml parser component package and your code will run happily and be compliant with company policy.

Re: “Python's batteries are leaking”

#69

Post by geofft »

lone_haxx0r wrote: post #58
geofft wrote: post #35

Earlier quoted context omitted.

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 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 more than you can, and you can slowly and quietly pursue your vision and perhaps find a small number of collaborators who share your taste.

Clojure sort of had this moment recently, where various people in the community were unhappy with the language direction and Rich Hickey (who is a person who cares about vision and taste in a language) made it quite clear that addressing their problems directly wasn't his definition of success. He was building a language for himself / his company to use, and if it worked for other people, great, and if they wanted to contribute to his vision, great, but if it didn't work for them, they should not expect Clojure to change. https://gist.github.com/richhickey/1563cddea1002958f96e7ba95... That, at least, is clear, and it means that authors of significant third-party libraries that are clashing with the vision of the language (and its community) can make an informed decision to spend time elsewhere, avoiding frustration on all sides. https://twitter.com/cemerick/status/1067111260611850240

I don't think Guido is/was actually trying to do this, and I think it's unfair to say that was his goal. If it was, then he was deliberately tricking people by having a core team, BDFL-Delegates, a language summit, etc. If it was, then he was being rude by asking her to come to the language summit instead of saying "Amber, Twisted is very good but your vision for Python is not my vision for Python." Guido, as far as I can tell, built Python to be a widely-used language, not a language following any sort of vision he started with. Guido does want Twisted and other Twisted-scale projects around, and does want Python to be a useful language for them. That's why I say that if he's burned out, the right way to execute his vision (which is exactly what he's doing, in fact) is to step aside graciously.

Re: “Python's batteries are leaking”

#70

Post by _hardwaregeek »

perlgeek wrote: post #59
_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…

I'm talking from a language maintainer perspective. From a user perspective, sure, you can upgrade. But that doesn't mean everybody will upgrade. In general, people don't like upgrading. That's why browsers all automatically update these days.
Post reply on HN