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

161–170 of 420 posts

Re: “Python's batteries are leaking”

#161

Post by sitkack »

debatem1 wrote: post #153
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…

The quote about the stdlib being "where packages go to die" was, for a long time, considered a feature and not a bug. The theory was that once a package is in the stdlib its development should slow to prioritize stability over new features. This may somewhat explain why lots of successful packages are not in the stdlib: putting them in effectively killed future development until a few years ago. But today that argume…

That phrase never had a good connotation. I believe someone skilled in PR respun that meaning.

Re: “Python's batteries are leaking”

#163

Post by icegreentea2 »

rlayton2 wrote: post #148
jonnycomputer wrote: post #131

Earlier quoted context omitted.

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

It does, but it's hardly an egregious amount (my 3.7 install on Win10 has it at 800Kb... though I guess tcl takes up 10MiB =P). For reference, the built in venv module (which I never use cause I'm all about that virtualenv life) is 1MB. The python tests are 20MB, and that ships by default on every python installation.

Like if you were in a resource constrained situation, you would be customizing your python install anyways (if nothing else, getting rid of the docs, the tests, maybe stripping out all but the compiled code...).

Re: “Python's batteries are leaking”

#164

Post by nbAYT »

I think it is important to notice here that a lot of the tension here is also Twisted vs. asyncio.

I've never liked asyncio, while Twisted felt natural to me. So I would agree that an inferior solution has been pushed heavily in the stdlib and also to the syntax level.

Moving the entire stdlib to PyPI is of course entirely foolish and would destroy Python.

Re: “Python's batteries are leaking”

#165

Post by hermanradtke »

> Brown went further adding that because few Python core developers are also major library maintainers, library authors’ complaints are devalued or ignored.

PHP has a similar issue to this. The people writing C were not using the language. The best example is PDO. A lot of C was written, but it was essentially abandonware because the PHP users could not make any changes without getting the C maintainers to both agree and have the time.

Re: “Python's batteries are leaking”

#166

Post by tachyonbeam »

rogerbinns wrote: post #133
mjw1007 wrote: 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…

I think the biggest problem is going from zero third-party dependencies to one and more. Adding that very first one is a huge pain since there are many ways of doing it with many different trade offs. It is also time consuming and tedious. The various tools like you mention are best at adding even more dependencies, but are hurdles for the very first one.

Not true. The more external dependencies you add, the more likely it is that one of them will break. I try to have as few external dependencies as possible, and to pick dependencies that are robust and reliably maintained. There is so much Python code on GitHub that is just broken out of the box. When people try your software and it fails to install because your nth dependency is broken or won't build on their system, you're lucky if they open an issue. Most potential users will just end up looking for an alternative and not even report the problem.

Re: “Python's batteries are leaking”

#167

Post by CodiePetersen »

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 down the road. More people would rather roll with an MVP as the final product than build something from scratch that's more robust, resilient, and efficient. Then after a while you have this huge mess of old broken code that can't be fixed anymore and just needs to be redone from scratch.

Sure you are going to need to redo code anyways from scratch eventually. But, programmers like I mentioned, which is surprisingly a huge chunk, make problems worse for themselves throughout the lifetime of the code by being short sighted and stamping their approval on code their too lazy to rewrite because their boss doesn't know any better.

Re: “Python's batteries are leaking”

#168

Post by detaro »

will4274 wrote: post #121

What's the point of saying that a standard library feature was not added soon enough? Nobody can go back in time and add it earlier. I can complain to death about features missing from C++11 or I can start using C++14.

If that happens regularly, it makes stdlib less useful for other libraries to build upon, forcing them into (sometimes awkward) workarounds, and is a sign of the stdlib not getting enough maintenance.

Re: “Python's batteries are leaking”

#169

Post by aasasd »

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 occasional typical proprietary behavior, Gitlab doesn't help in this case.

Re: “Python's batteries are leaking”

#170

Post by dataflow »

deathanatos wrote: post #140
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…

For the most part, when you do I/O to some external system, if it's text, you encode/decode at the border to that system. Interally, all text data is `str` (or `unicode` in 2) and all binary data is `bytes` (in both). In some cases of common OS-induced pain, I'd say "do whatever 3 does" in 2, since that'll make migration easier in the long run. (But I understand that can be hard, and I think my responses to your exam…

>> Unicode stdio?

> Mostly, `io` should handle this in both 3/2. You might need to help it get the right encoding in 2.

Does io handle stdio? I was referring to standard input and standard error/output. How do you read/write Unicode in a cross-2/3 way from/to standard input/output/error without adding your own translation layer?

>> Unicode file paths

> This is going to be a mess in any language, because file paths really aren't text.

Sorry I need to be more clear. That general mess is not the aspect of it I was referring to. I'm specifically referring to a 2/3 compatibility mess.

I meant that, for example, to have any semblance of Unicode handling, in Python 2 you do os.listdir(u"."), whereas in Python 3 you do os.listdir(b"."). I know how to handle it in both Python 2 and Python 3 in a way that's Good Enough (TM), but how do I even get that with cross-compatible code? I'd need to write a translation layer of sorts for every single I/O function I might use.

>> Unicode sys.argv

> I think I'd say "do whatever 3 does".

Hmm okay thanks, I'll need to try to see what the implications are again. I think the problems I recalled from this may have been just been a result of the other issues, not sure.

I can't "forget about 2" though, it's still on Ubuntu LTS systems and there are still packages in 2 that haven't been ported to 3.

>> I feel like Python 3 completely wrecked strings instead of making them better.

> A clear separation of text and binary is needed in the long run, and makes other operations much clearer and saner. The pain you're feeling is introduced from the OS not having the same clarity.

Again, I think this is "cleaner" in theory, not in practice. What happened to the string_escape/unicode_escape nonsense I pointed out with the new system? Any rebuttal to that one? ;-)

Post reply on HN