“Python's batteries are leaking” • Hacker News Board

Re: “Python's batteries are leaking”

#101

Post by jteppinette » Sat, May 18, 2019, 8:25 PM UTC

mehrdadn wrote: post #87

jteppinette wrote: post #12

> six is non-optional for writing code for Python 2 and 3 I maintain a Python 2 & 3 compatible project that has no external dependencies.

I do similarly as you (maintain 2/3 code without dependencies) but every time I have to do string encoding/decoding it kills me to find a way that half works, and I don't have a ready solution in my mind for these that doesn't break half the time. How do you handle non-ASCII in a compatible manner? Like Unicode stdio? Unicode file paths? Unicode sys.argv? string_escape/unicode_escape? I feel like Python 3 completely…

You have to invest some time in understanding how strings (byte strings and unicode) work in Python. I put this off for way too long.

After A TON OF PAIN I decided to put the time in to watch the talk "Pragmatic Unicode, or, How do I stop the pain?"[0] by Ned Batchelder and it all just clicked. Now, I make unicode sandwiches like a boss.

[0] https://youtu.be/sgHbC6udIqc

Re: “Python's batteries are leaking”

#102

Post by walshemj » Sat, May 18, 2019, 8:25 PM UTC

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…

You use CPAN all the time in perl develpment

Re: “Python's batteries are leaking”

#103

Post by edflsafoiewq » Sat, May 18, 2019, 8:28 PM UTC

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).

    use std::iter::FromIterator;
    BTreeMap::from_iter(hash_map.into_iter())

Re: “Python's batteries are leaking”

#104

Post by smitty1e » Sat, May 18, 2019, 8:29 PM UTC

alexdong wrote: post #54

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

Is there a limit to how constructive the feedback can be?

What do we know? Software configuration management is a heinous problem.

Python gets it more correct than most.

Let us rejoice, be patient, and respect everyone's good-faith efforts.

Re: “Python's batteries are leaking”

#105

Post by smitty1e » Sat, May 18, 2019, 8:31 PM UTC

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...

There is the expectation of IDLE, no? Isn't that a tkinter product?

Re: “Python's batteries are leaking”

#106

Post by dragonwriter » Sat, May 18, 2019, 8:32 PM UTC

Note that similar issues were raised with Ruby stdlib, which is being addressed in part with “Gemification” of stdlib, so that all of stdlib (targeted for 3.0, though it's been going on since 2.4)[0] is being moved out to externally-updatable packages that are included by default (default and bundled gems), so that it is still “batteries included” but the batteries are at least replaceable.

Amber's suggestion seems to be in the same direction (though perhaps not as extreme.)

[0] https://www.slideshare.net/mobile/hsbt/gemification-for-ruby...

Re: “Python's batteries are leaking”

#107

Post by geofft » Sat, May 18, 2019, 8:37 PM UTC

ryl00 wrote: post #94

geofft wrote: post #44

Earlier quoted context omitted.

I found that attractive when I first learned Python, but when I (much more recently) started picking up Rust, I was blown away by how easy and normal it is to use external packages: the build tool and package manager are the same thing and shipped with the language, the hello-world-equivalent docs assume you're using it, and even the Rust compiler and standard library themselves can (carefully) depend on external pac…

> When Python's standard library was first being written, there were no easy package managers for any language Wasn't perl's CPAN developed around that time period (mid '90s) ?

Emphasis on easy :-P Using CPAN in even the late '00s was an ordeal.

Re: “Python's batteries are leaking”

#108

Post by stochastastic » Sat, May 18, 2019, 8:42 PM UTC

The 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 successful packages like Requests? Tried it and it didn’t work? Too much bloat? Already got too much on the to-do list?

Re: “Python's batteries are leaking”

#109

Post by alexdong » Sat, May 18, 2019, 8:44 PM UTC

tptacek wrote: post #88

alexdong wrote: post #54

Earlier quoted context omitted.

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

Is "embrace PyPI and move things like asyncio there" not a constructive suggestion, or is she sort of being penalized because the most reasonable solution to the problem can be described in less than half a sentence so it's seems like there's more complaint than solution?

Yup. Totally agree with you on that. And yes this one is a constructive proposal.

My problem is on the like part.

Where shall we draw the line and how do we decide? To me this is a far more interesting discussion. (Maybe it has happened. I don’t go to many conferences these days so I might be missing something here. )

She mentioned http.client vs requests, datetime vs. moments etc, which are also quite correct to me. How about the cgilibs? Or pickle? Or the collections? Or unittest? Stay or go?

Lastly, the title of the talk can be tempered a bit. No? We all know what a leaking battery mean right? Toxic.

Re: “Python's batteries are leaking”

#110

Post by dragonwriter » Sat, May 18, 2019, 8:54 PM UTC

alexdong wrote: post #109

tptacek wrote: post #88

Earlier quoted context omitted.

Is "embrace PyPI and move things like asyncio there" not a constructive suggestion, or is she sort of being penalized because the most reasonable solution to the problem can be described in less than half a sentence so it's seems like there's more complaint than solution?

Yup. Totally agree with you on that. And yes this one is a constructive proposal. My problem is on the like part. Where shall we draw the line and how do we decide? To me this is a far more interesting discussion. (Maybe it has happened. I don’t go to many conferences these days so I might be missing something here. ) She mentioned http.client vs requests, datetime vs. moments etc, which are also quite correct to me.…

> Where shall we draw the line and how do we decide?

Why does there need to be a line? As long as the package manager is part of the core distribution (even if it is itself an upgradable package) why not moving everything into packages, even if some are maintained by the core team and have the stable version at time of distribution release included with the core distribution—but perhaps installed only on demand?