Live data from Hacker News

“Python's batteries are leaking”

pyfound.blogspot.com

191–200 of 420 posts

Re: “Python's batteries are leaking”

#191

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…

It's important to use dataclasses/attrs, pytest, mypy, pylint. Those tools transform python from an ad hoc language to a robust one.

For speed, pypy is the way to go.

Re: “Python's batteries are leaking”

#192

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…

Python was one of the first languages I learned.

Recently started using Go a little, and it does feel better but it just takes longer for me to write (probably because it's newer to me too). At work, people want things quickly. I'd love to be able to spend my time writing things properly in Go, but it's just not as quick and easy as Python is.

Re: “Python's batteries are leaking”

#193
post #169

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…

Pypi still has a download counter, but it will tend to reflect which libraries are used in ci, so it's a biased estimate.

Re: “Python's batteries are leaking”

#194
post #96
post #17

Earlier quoted context omitted.

From my own past experience with depression, it’s not as simple as “I’ll just stop doing all the things that have kept me in motion until now.” This is not meant to speculate on van Rossum’s health, just trying to point out that there are situations where apparent rudeness may be out of the person’s immediate control.

If you're sufficiently in control of your actions to keep developing a major programming language, you're sufficiently in control of your actions to either not be rude while doing so or be aware that you're going to be rude and need to find a way of dealing with the situation (avoiding it, taking extra time before speaking, working with a therapist, whatever). Mental health issues don't excuse bad behavior. (Also, pe…

> Mental health issues don't excuse bad behavior.

Basically agreed.

> If you're sufficiently in control of your actions to keep developing a major programming language, you're sufficiently in control of your actions to [...] not be rude while doing so [...]

That's a lovely thought, but no. When I've had bad times, my social skills and emotional cope would sometimes go to shit and leave my technical skills intact.

Re: “Python's batteries are leaking”

#195

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…

What functionality would you like to have on PyPI, in addition to curation?

Re: “Python's batteries are leaking”

#196
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 wi…

ElementTree is in the stdlib. It isn't slow and has incremental parsing and so on.

It's also a nice API for dealing with XML.

Re: “Python's batteries are leaking”

#197
post #68
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 use cpan constantly, though indirectly via carton. I used to use the OS for Perl libs but this starts to fail hard when you have multiple projects that all demand different versions of stuff.

Re: “Python's batteries are leaking”

#198
post #173

Earlier quoted context omitted.

> More people would rather roll with an MVP as the final product than build something from scratch that's more robust, resilient, and efficient. Well, yeah, of course. It's expensive to reinvent the wheel.

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

Re: “Python's batteries are leaking”

#199

The story of Python 2 to Python 3 migration, in a nutshell: > Van Rossum argued instead that if the Twisted team wants the ecosystem to evolve, they should stop supporting older Python versions and force users to upgrade. Brown acknowledged this point, but said half of Twisted users are still on Python 2 and it is difficult to abandon them. The debate at this point became personal for Van Rossum, and he left angrily.

Hopefully the “python foundation” will declare python 2 deprecated soon so that it can be handed over to responsible maintainers.

Re: “Python's batteries are leaking”

#200

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.
Post reply on HN