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

141–150 of 420 posts

Re: “Python's batteries are leaking”

#141

Post by avar »

gcb0 wrote: post #68
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…

I don't mean OS distributors can't package up CPAN modules. They can do that, no problem, same for the Python equivalents.

I mean that a significant use people get out of Python and Perl is that they aren't bare-bones like say Scheme or Lua where the standard library is really spartan.

It allows you to write useful code that works on the lowest common denominator of "just OS Perl or Python". Whether that's some random version on whatever Linux distro, or *BSD or Solaris or whatever without needing to write your own getopt library or whatever.

Which is why the "let's ship a bare-bones compiler and have people use CPAN or PyPi" is contentious. In theory it shouldn't matter, and for a lot of shops who install hundreds of packages it doesn't, but it does for people who target stdlib-only, which is a big use-case. Particularly since the people who have that use-case are drawn to these languages.

Re: “Python's batteries are leaking”

#142

Post by pfranz »

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…

I'm only going from this article. But I don't think the "ranting" was constructive and I feel like it obscured her point. A lot of comments here thought the goal was to include more (less crufty) packages in the standard library. Which is the opposite of her intention.

I agree with a lot of her arguments. I never understood why tkinter was included (I could see why it might have been added years ago, but before Python3 came along it felt obsolete and unused). I've had to support old versions of Python along with their bugs, and it sucks.

But languages are about choices. Python's syntax and decision to use whitespace is a strong choice--so is their stdlib. I've been on projects that saw performance problems with etree, moved to lxml, then had to go back to etree because of missing features. I've spent a lot of time looking over arrow, dateutil, and moment because datetime seemed inadequate. But I like that there is a thoughtful default that serves many needs. A lot of these examples, like requests, are built right on top of stdlibs--so both would be needed even if it was shipped along with stdlib. I'm ok if code goes there to die because I would hope that due diligence was taken when it was included.

I kind of agree with Guido for a lot of this. I can't wait to move from Python 2 and have looked a lot of the new stdlib and looked for backports. I've looked at twisted and alternatives and I'm so happy something is built in even if its far from perfect.

Re: “Python's batteries are leaking”

#143

Post by dragonwriter »

avar wrote: post #141
gcb0 wrote: post #68

Earlier quoted context omitted.

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…

I don't mean OS distributors can't package up CPAN modules. They can do that, no problem, same for the Python equivalents. I mean that a significant use people get out of Python and Perl is that they aren't bare-bones like say Scheme or Lua where the standard library is really spartan. It allows you to write useful code that works on the lowest common denominator of "just OS Perl or Python". Whether that's some rando…

> 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 unused libraries, but if they are relatively unused because they aren't good rather than because the use case is uncommon, upgradability could solve that.

Of course, you don't solve compatibility for versions before the move to upgradable packages, but at the same time if you solve problems going forward you increase the incentive to upgrade.

Re: “Python's batteries are leaking”

#144

Post by analognoise »

tanilama wrote: post #83

> Brown called out the XML parser and tkinter in particular for making the standard library larger and harder to build, burdening all programmers for the sake of a few Tkinter needs to go...There is very little reason except for the legacy ones, why it needs to be there still...

Tkinter is awesome, I hope it isn't jettisoned. I haven't found anything that easy to use with a similar Canvas.

Being able to add items to a canvas, attach callbacks to them - without tracking them yourself, setting up the infrastructure for indexes, bounding boxes, all that stuff - I haven't found anything else as easy as Tkinter's Canvas.

If there is something better, I'd love to hear about it.

Re: “Python's batteries are leaking”

#146

Post by a1369209993 »

StavrosK wrote: post #82
nicoburns wrote: post #29

Earlier quoted context omitted.

Dictionary in the python sense? There are two! https://doc.rust-lang.org/std/collections/struct.HashMap.htm... https://doc.rust-lang.org/std/collections/struct.BTreeMap.ht...

Oof, I wasted a good hour+ trying to convert from one to the other. Maybe there's an easy way to do this, but not many people on IRC knew (or were available at the time).

Assuming the keys are Hash + Ord, wouldn't that just be:

  for (k,v) in &src
    { dst.insert(k,v); }

?

Re: “Python's batteries are leaking”

#148

Post by rlayton2 »

jonnycomputer wrote: post #131
tanilama wrote: post #83

> Brown called out the XML parser and tkinter in particular for making the standard library larger and harder to build, burdening all programmers for the sake of a few Tkinter needs to go...There is very little reason except for the legacy ones, why it needs to be there still...

Why does it need to go?

It uses a non trivial amount of resources for (nearly) every python install. Therefore if it isnt of substantial use then it should be removed to free those resources

Re: “Python's batteries are leaking”

#149

Post by teek »

pixelrevision wrote: post #55
nerdwaller wrote: post #19

Earlier quoted context omitted.

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

3rd party packages are already a problem because a github repo shouldn't be treated as a dependency source. Gomod solves some problems but still uses git repos as the source.

The primary reason Go can get away with this strategy is because the Go community actively promotes fewer dependencies = better. So if you write Go you have to often accept the fact that the second you add a 3rd party dependency that you're now officially on your own if that dependency breaks or becomes unsupported.

This is not necessarily a bad thing. But in order to move software forward I still think we can do better than to push this responsibility to all individual end users.

This is one area where I feel like most popular languages today still fail compared to CPAN. CPAN's value was not just packaging and distribution, it was an integrated test report pipeline and infrastructure, actively managing and gatekeeping of library maintainers, CPAN mirroring functionality, and easy acceptance of bug reports and user feedback against a library.

Re: “Python's batteries are leaking”

#150

Post by raverbashing »

Good points, some things on the standard library are just painful

My "favourite" library quirk. socket.fromfd is only available on "Unix" on Python 2.X, that was fixed in Python 3.X

The worse offender being the logging library. It's the least pythonic thing in the whole std library (ok maybe ABC is worse, but oh well)

Post reply on HN