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

Re: “Python's batteries are leaking”

#251

Post by petre » Sun, May 19, 2019, 4:00 AM UTC

aasasd wrote: post #169

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…

> Does anyone have a curated version of PyPI? Pypi have thrown out the downloads counter—a huge misservice to coders. Like I got all day to figure out the best libs for ten different features which I only need in passing, so my primary concern is to not pick complete garbage. So, my solution to that now is to look up Github pages for the libs and choose the one with most stars. As much as I dislike Github for its occ…

Perl has stars on MetaCPAN and every version has a test counter. Download counter is unreliable.

Re: “Python's batteries are leaking”

#252

Post by roca » Sun, May 19, 2019, 4:05 AM UTC

bsder wrote: post #207

dragonwriter wrote: post #106

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

Python cannot be atomized effectively, and the issue is political. The problem is that I cannot count on being able to install new software in many environments. If I fight the battle to get centralized IT to install Python, I now have a guaranteed set of standard libraries as well. I'm never going to get permission to install anything other than default. Ever. Consequently, the standard libraries need to be very com…

Putting code into the standard library doesn't magically create developer resources to maintain it. Indeed, Amber Brown is saying that many libraries in the Python standard library aren't properly maintained. So it's not clear that standard library policy is relevant to the Rust issues you have.

Re: “Python's batteries are leaking”

#253

Post by halter73 » Sun, May 19, 2019, 4:08 AM UTC

Maxious wrote: post #237

Havoc wrote: post #227

Earlier quoted context omitted.

>What kind of place do you work? Not OP but same. I'm currently debating with myself whether I should attempt to install PUTTY. Given that port 22 is blocked and it's not needed for my core role it'll be dicey if I get challenged. Pulling executable code off some repo...no way that is ever officially passing muster. People might do it anyway, but on a personal risk basis. >Can you explain this more? Place that are he…

I'm glad Windows 10 has OpenSSH now: > Microsoft Windows [Version 10.0.17763.437] > (c) 2018 Microsoft Corporation. All rights reserved. > > ssh -V > OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5

I've found the built-in Windows 10 ssh client has trouble with tunneling, so I still use the ssh client included with git.

Re: “Python's batteries are leaking”

#254

Post by roca » Sun, May 19, 2019, 4:13 AM UTC

bscphil wrote: post #234

civility wrote: post #73

Earlier quoted context omitted.

> Having run up against limits of the Python standard library several times in years of writing production software in it and not just learning it, I find the batteries-not-includes-but-easy-to-install approach better on the whole. Obviously it doesn't apply to everyone, and it certainly doesn't apply to most startups or open source developers, but I spent most of the last 20 years working in environments where you h…

>Obviously it doesn't apply to everyone, and it certainly doesn't apply to most startups or open source developers, but I spent most of the last 20 years working in environments where you have to get permission for every third party library you bring on to the network. Situations like this will really make you appreciate "batteries included". I think this particular issue is fairly revealing of the attitudes common a…

Standard libraries serve several functions. One of them is to bless certain versions of certain libraries as "known good". This can be done outside the standard library too, without incurring the penalties of actually moving things into the standard library. Rust definitely needs more work in this area though.

Re: “Python's batteries are leaking”

#255

Post by CodiePetersen » Sun, May 19, 2019, 4:23 AM UTC

Felz wrote: post #198

CodiePetersen wrote: post #181

Earlier quoted context omitted.

Its more expensive trying to fix broken code and working around other work arounds that should not be in production. Slows you down, bloats your code, makes it harder for new employees to learn the system when they come on board, etc.

Is the quality of the dependencies you use really so bad that it'd take you more time to fix them than to write your own code and then fix that? Like I can see where I'd make that tradeoff, but it'd have to be a small function in a really niche use case, which isn't really that common. (I work on the JVM though and don't know how good/bad Python libraries would be in general.)

Well it matters when you roll it out at scale. I suppose client side you don't have to worry too much. I think it's still a bit lazy but it doesn't have too much of an impact on small projects. But, as an example, the last company I worked at we made a neural network engine from scratch because we were just not happy about the available frameworks, their heavy dependency usage, and their very specific requirements of os and language versions. In our tests while I was there, we were able to get 3 times the speed up against the fastest framework of the ones we tested, which was Tensorflow. A lot of the speed up came from just taking good programming practices into account and knowing the system in and out and potential weak points. That's how much the dependencies were killing the speed. Since I've left, that's one of their main things now, just making high quality machine learning modules that get the best bang for their buck.

So yeah, I'd say the dependencies are pretty bad. It's a process outside of your control and you kind of just have to deal with whatever is under the hood. More importantly though, what's under the hood was likely meant to be general purpose and there is more than likely a better way to do it for your particular situation. And as she mentions a lot of the bugs are indefinitely there so you just have to have permanent workarounds, which is never good.

Re: “Python's batteries are leaking”

#256

Post by CodiePetersen » Sun, May 19, 2019, 4:25 AM UTC

pjc50 wrote: post #200

CodiePetersen wrote: post #167

I like python, its a nice simple language that you can use to pump out a proof of concept real quick with little hassle, but for full on production I avoid it. But I think this is a larger trend in programming, in my opinion the majority of programmers are super lazy. Everyone is in a mad dash to get the cool new thing out so they just slap a bunch of dependencies on it and damn the consequences of developer debt dow…

This is in no way specific to Python, and I think happens eventually in most languages. Only the heavier formal systems remain manageable.

Oh definitely. I think though, for whatever reason, python has quite a bit more of it than most. I think that's probably partly because of how fast it has been adopted and rolled out.

Re: “Python's batteries are leaking”

#257

Post by petre » Sun, May 19, 2019, 4:27 AM UTC

Aeolun wrote: post #222

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…

Node is ostensibly batteries included, but they’re weird, arcane batteries powered by tears. Therefore, to get anything done easily usually requires an external package.

Node doesn't even have a stdlib. You have to npm or yarn anything. And yes most of the time it will end in tears. That's not my definition of batteries included, but rather some batteries might explode, others might only ignite, we wish you the best of luck.

Re: “Python's batteries are leaking”

#258

Post by syntaxfree » Sun, May 19, 2019, 4:27 AM UTC

mlevental wrote: post #11

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.

how is that an excuse for being uncivil? if you're burnt out then don't attend the talk? simple.

There's galaxies or distance between "this is acceptable" and "this is understandable".

People are screwed up. You are, too. I hope your business partners and allies don't hold you to the standard you're bearing when your time to behave badly comes.

Re: “Python's batteries are leaking”

#259

Post by analog31 » Sun, May 19, 2019, 4:38 AM 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?

This question suggests a criterion for what batteries should be included, which is platform dependence. What both Tkinter and IDLE do, is ensure that there is a basic GUI library, and a code editor, that can run on any platform.

Coming from Visual Basic, and similar things (HyperCard, Turbo Pascal), being able to run a program with GUI on both Windows and Linux with no code changes was nothing short of amazing to me. So maybe that's one way to draw the line with batteries, namely to make it so a beginner can get started with Python, with no regrets about which OS they're using. This requires some out-of-box hardware abstraction, where they keyboard, mouse, and display, all effectively count as hardware.

Re: “Python's batteries are leaking”

#260

Post by CodiePetersen » Sun, May 19, 2019, 4:40 AM UTC

sgustard wrote: post #212

CodiePetersen wrote: post #167

I like python, its a nice simple language that you can use to pump out a proof of concept real quick with little hassle, but for full on production I avoid it. But I think this is a larger trend in programming, in my opinion the majority of programmers are super lazy. Everyone is in a mad dash to get the cool new thing out so they just slap a bunch of dependencies on it and damn the consequences of developer debt dow…

If a programmer is lazy, forcing him to use Java or C++ isn't going to fix it. And I've seen good developers ship plenty of quality code in Python or Ruby.

That's not what I'm saying, what I'm saying is that if there is a known bug in a python library, don't use it and code it from scratch. Especially if your job is to roll it out at a large scale. You could save your company tons of money just by taking the time to do it right. But yeah, you can ship python and ruby all you want. That's fine, but if you are using buggy or broken libraries because you don't want to code one up yourself, then that is in fact not quality and is indeed lazy.

Me personally, for my company I would not hire any contractor making code for me in python. Not because python is inherently bad or unoptimized in all cases, but because I know the general tendency is to use lots of dependencies. Pythons motto over all is easy over hard that has really spread in the community in a not so good way. Like I said though, I use it, I like it, it is awesome for banging out prototypes, but I avoid it for production. There is just to many potholes to the point I would rather just code something from scratch closer to the hardware, which I will admit I do not enjoy xD, but if its what needs to be done, then so be it. There are just a lot of things that I work on where even 5% efficiency could save you thousands.