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

351–360 of 420 posts

Re: “Python's batteries are leaking”

#351

Post by falcor84 »

kilburn wrote: post #187
falcor84 wrote: post #159

Earlier quoted context omitted.

What is your argument here? Standard library module development is also extremely slow.

There is one major difference: an abandoned external package may break with newer python versions, whereas you can always count on stdlib packages being updated for new versions.

Can you provide an example?

To the best of my knowledge, minor version updates in Python 3 have been entirely backwards so far and shouldn't have broken any library code. And as for incompatible changes sick as the transition to 3, then these of course had interface changes in the standard library.

Re: “Python's batteries are leaking”

#352

Post by d0mine »

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…

As I understand, the Ruby model -- that is suggested for Python above -- is to include the libraries by default but to keep them as separate pypi packages.

In this case, even If you can't upgrade, you still get the same libraries but perhaps older versions.

Re: “Python's batteries are leaking”

#353

Post by cwyers »

edoceo wrote: post #279
loeg wrote: post #278

Earlier quoted context omitted.

If your risk assessment says that the exact same tkinter outside of Python stdlib is riskier than in Python stdlib, maybe your risk evaluation process needs reevaluation.

I hear this sentiment frequently. Come on, one software engineer cannot steer the huge ship that is BigCo Risk Assessment. Well, they couldn't do that and the original task. It might me more helpful to think of these types of external factors as fixed points that cannot be moved and just engineer around them. You'll burn out if you try to boil the ocean on every business process that doesn't seem "logical" from your…

On one hand, this is true. On the other hand, this is being put forth as a reason to not make a change in the entire Python ecosystem, and it's not really Python's job to bend over backwards for shops that have bad risk assessment either.

Re: “Python's batteries are leaking”

#354

Post by zbentley »

petre wrote: post #257
Aeolun wrote: post #222

Earlier quoted context omitted.

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.

> Node doesn't even have a stdlib.

Yes it does. Perhaps you're thinking of browser JS, which does not.

Re: “Python's batteries are leaking”

#355

Post by dralley »

schlenk wrote: post #308
loeg wrote: post #278

Earlier quoted context omitted.

If your risk assessment says that the exact same tkinter outside of Python stdlib is riskier than in Python stdlib, maybe your risk evaluation process needs reevaluation.

As long as you cannot even prove that due to a lacking python code signing infrastructure for packages (wheels can do it, but it is far from wide spread). And setup.py is a trainwreck, e.g. some packages compile download and compile huge dependencies (e.g. a full Apache httpd...), the default compiler flags may lack all the mandatory security flags (e.g. for using ASLR on python 2.x), or ship their own copy of openss…

And since setup.py is a Python file, you can't express build time dependencies properly. Pyproject.toml let's you do that, but it's new, nobody knows about it, and older pip clients don't support it.

Re: “Python's batteries are leaking”

#356

Post by gmueckl »

pornel wrote: post #323
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…

This is close to what Rust is doing, and it's working pretty well, apart from shocking newcomers who expect libstd to be useful on its own. In Rust, libstd is mainly for interfacing with the compiler and providing interoperability between packages (crates). The wider crate ecosystem is the real standard library, since external crates are as easy to use as the standard library. For example, the libstd doesn't even hav…

Having incompatible libraries solving the same basic problems is absolutely not fine. Over time, this will become a huge issue for composability. C++, for instance, already is in this kind of mess with things like STL containers versus Qt comstainers vs. homegrown special case (optimized containers) and heaps of additional libraries building upon each. There are other good examples in other programming languages as well, mostly older ones.

The example of random number generators is a good one, too. There are a lot of applications that require (reproducable!) PRNG sequences and sometimes you have to share PRNGs between modules. Now, looking at the rand crate, I see that the prng part of it was recently mucked around with. If I have two 3rd party modules that I require to share a PRNG that I control (say, noise generators for procedural textures), I cannot compose them if one of them uses the old and one of them uses the new version of the library.

Re: “Python's batteries are leaking”

#357

Post by zbentley »

liability wrote: post #151
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...

If Tkinter goes, then Python is dead to me. I use Python for small dep-free single file GUIs for small projects meant to be used by people who have Python installed but can't be bothered to go through an installation checklist. Tkinter is great for that and is the only reason I bother using Python for anything.

"pip install --user -r requirements.txt" is not a terribly odious "installation checklist", and I don't think it's the start of a slippery slope towards one either.

If you're worried about people not RTFM when using your projects, you could always start your scripts with the standard try/import/except wrapper around the required package, and tell them to run pip install when it's not found--or (and this is a terrible idea) run it in a subprocess for them.

Re: “Python's batteries are leaking”

#358

Post by zbentley »

bjourne wrote: post #337
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...

Tkinter is used by matplotlib's show() function. Without tkinter, you would somehow need to replace it with some other platform independent gui library.

If it weren't in the stdlib, could it not be installed as a depdencency when you install matplotlib?

Re: “Python's batteries are leaking”

#359

Post by mgkimsal »

dataflow wrote: post #177
dataflow wrote: post #116

Earlier quoted context omitted.

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

Also, I think the facilities are lacking for case-insensitive comparisons in Python 2, so I guess this is one thing they improved. Still don't know how to do it "correctly" when writing Python 2-compatible code.

> Still don't know how to do it "correctly" when writing Python 2-compatible code.

Does writing python 2 code stop being 'worth it' at some point? If so, where is that point? It sort of sounds like you're already there. There's still people using P2 at least in part because of all the hoops people are jumping through to keep supporting it, no?

I'm not a professional python dev, so it doesn't impact me as much as some of my colleagues, but 'backwards compatible' issues crop up in other platforms/langauges as well. Wordpress might be the biggest example in PHP. They've kept a minimum target language which is far behing 'current' or even 'currently supported', and it's been a catch 22. Hosts keep supporting PHP 5.4, for example, far later than they 'should' have, because people kept writing new stuff targeting PHP 5.4. WP 5 was, alas, a missed opportunity to target PHP7 as a minimum. :/

Re: “Python's batteries are leaking”

#360

Post by tptacek »

ddebernardy wrote: post #271
tptacek wrote: post #18

Earlier quoted context omitted.

You want pyca/cryptography. The last thing in the world you want is a standard crypto library that no experts are enthusiastic about maintaining. Golang had an unfair advantage here, because the language team included cryptography engineers. It would be weird if most languages had the same kind of crypto in their stdlibs. I think there is in general nothing wrong with a language ecosystem where key parts of the whole…

Sure, but in Python's case, what's wrong with bundling a light wrapper around a well maintained C library?

That it would be inferior to pyca/cryptography?
Post reply on HN