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

Re: “Python's batteries are leaking”

#111

Post by pvg » Sat, May 18, 2019, 8:55 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.…

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

Come on. Python has had the 'batteries' metaphor for decades and this is a straightforward and obvious play on it. You're bringing 'toxic' into this which I suppose is technically and biochemically correct (both, surely, the best kinds of correct) but has far, far more negative connotations than the title warrants. You're having to work really hard to make a generic thing sound dreadful.

Re: “Python's batteries are leaking”

#112

Post by sigzero » Sat, May 18, 2019, 8:56 PM UTC

smitty1e wrote: post #105

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?

It is.

Re: “Python's batteries are leaking”

#113

Post by tanilama » Sat, May 18, 2019, 8:59 PM UTC

smitty1e wrote: post #105

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?

But this only can't justify that tkinter being part of the STANDARD library.

Taking tkinter out of the standard library won't stop IDLE being built with it, if they chose to do so.

Re: “Python's batteries are leaking”

#114

Post by znpy » Sat, May 18, 2019, 9:01 PM UTC

I have mixed feelings about this because I've seen both parts of the same situation.

In certain situations, I've been working with a python interpreter on a RHEL machine where pip was not installed (and I was not allowed to install it as well as make other modification: the machine was owned by the client and I had to work with what I had available).

- having some basic functionality in the core libraries was a godsend because I could work with that, even though it was not "ergonomic"

- not being ergonomic, it was a "poor experience" (and certainly not optimized or anything nice to see).

Re: “Python's batteries are leaking”

#115

Post by detaro » Sat, May 18, 2019, 9:01 PM UTC

tanilama wrote: post #113

smitty1e wrote: post #105

Earlier quoted context omitted.

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

But this only can't justify that tkinter being part of the STANDARD library. Taking tkinter out of the standard library won't stop IDLE being built with it, if they chose to do so.

Depends, do you consider IDLE part of the standard library? (it's separated in many distributions, but documented in the standard library documentation, so it's a bit mixed, but it's probably okay to not consider it part of the library, but just the standard distribution)

Re: “Python's batteries are leaking”

#116

Post by dataflow » Sat, May 18, 2019, 9:02 PM UTC

jteppinette wrote: post #101

mehrdadn wrote: post #87

Earlier quoted context omitted.

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

Uhm I think you misunderstood the problem. I already understand Unicode, and I can handle Unicode just fine as far as the facilities are there, in both Python 2 and Python 3 -- individually. The places where I have trouble are (1) where either or both languages do something nonsensical, (2) where the facilities just don't seem to be there (sys.argv?), (3) where there are bugs (try writing binary to stdout with IDLE open), or (4) where there seems no reasonable way to write code that behaves correctly in both languages without making your own little translation layer. Like as an example for #1, "a".encode('unicode_escape') == b'a' makes no sense. Why should escaping a string suddenly turn it into bytes? I never even specified an encoding for those bytes. And similarly why should "a".decode('unicode_escape') be an error? It makes perfect sense. What they did looked nice in theory (no implicit conversions between bytes and strings etc.) but IMHO they practically completely wrecked strings in Python 3.

Re: “Python's batteries are leaking”

#117

Post by dragonwriter » Sat, May 18, 2019, 9:04 PM UTC

tanilama wrote: post #113

smitty1e wrote: post #105

Earlier quoted context omitted.

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

But this only can't justify that tkinter being part of the STANDARD library. Taking tkinter out of the standard library won't stop IDLE being built with it, if they chose to do so.

Though OS packaging may frequently obscure this because OS packagers break up the language distribution, Idle is part of the language distribution, so (unless you expand the distribution to include core packages outside of stdlib, as with Ruby’s gemification effort) it has to be built with stdlib alone. Tkinter, therefore, needs to be part of stdlib.

Re: “Python's batteries are leaking”

#118

Post by llukas » Sat, May 18, 2019, 9:05 PM UTC

stochastastic wrote: post #108

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

+100

> As an aside, why doesn’t the Python standard library extend/replace features with code from successful packages like Requests?

It is possible (ie. asyncio was separate package). It is slow process though.

Re: “Python's batteries are leaking”

#119

Post by tanilama » Sat, May 18, 2019, 9:10 PM UTC

dragonwriter wrote: post #117

tanilama wrote: post #113

Earlier quoted context omitted.

But this only can't justify that tkinter being part of the STANDARD library. Taking tkinter out of the standard library won't stop IDLE being built with it, if they chose to do so.

Though OS packaging may frequently obscure this because OS packagers break up the language distribution, Idle is part of the language distribution, so (unless you expand the distribution to include core packages outside of stdlib, as with Ruby’s gemification effort) it has to be built with stdlib alone. Tkinter, therefore, needs to be part of stdlib.

Taking IDLE outside of the standard distribution and make a separate download link for it, isn't in anyway going to hurt Python at this point.

Just move tkinter like what they do with typing package is good enough to address everyone's need.

Re: “Python's batteries are leaking”

#120

Post by notatoad » Sat, May 18, 2019, 9:11 PM UTC

nerdwaller wrote: post #22

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