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

171–180 of 420 posts

Re: “Python's batteries are leaking”

#171

Post by rightbyte »

icegreentea2 wrote: post #39
rightbyte wrote: post #31

Earlier quoted context omitted.

When I first touched Python I had only used C. Is your story similair? Had I been using Java or Visual Basic or even C++ proirly maybe I wouldn't be so impressed as I were. I think the mistake Python is doing is messing with it's simplicity with decorations, halfass lambdas and stuff. As a newbie you could understand Python code, while eg. C++ templates were magic. You need to know more Python to understand Python co…

Decorators added were in in 2004, I think lambdas were an original language feature (like... before 2004). There are other new stuff that might be confusing to beginners (like our mighty walrus operator), but those two examples have been there for effectively forever.

Ok it's maybe just my random perception of the language evolving in unsync with my (moderate) skills in it.

I just had the feeling there's more "stuff" that you need to know.

Re: “Python's batteries are leaking”

#172

Post by nerdwaller »

notatoad wrote: post #120
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.

Perhaps my wording is incorrect, but you’re 100% capturing what I was trying to get at. Thanks for the clarification!

Re: “Python's batteries are leaking”

#173

Post by tomrod »

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…

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

Re: “Python's batteries are leaking”

#174

Post by simonh »

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…

Requests depends on urllib3 which would also have to go into the stdlib. It also contains a CA bundle which the core devs don’t want to do. It also likely the internal implementation doesn’t follow core dev standards and practices, a common problem with integrating external libs. Finally there’s a risk it would slow or discourage new feature development by tying it to the core release cycle.

A better approach might be to add a core of basic requests-like features built from the stdlib’s existing resources. That would be beneficial to many users and if they need more then there’s always Requests.

Re: “Python's batteries are leaking”

#175

Post by adontz »

cameronbrown wrote: post #138
nnq wrote: post #128

Earlier quoted context omitted.

> but breaking compatibility with previous versions is a bug That's how you get an inconsistent mess that never evolves. There's something called semver , increase the version number and do the fix / refactors / radical redesign / whatever. People will see that you've went from version 1.0 to 87.3 in one year and they may choose not to use your thing because you're moving too fast for them, but that's life...

Better than breaking software. Linux is far more important when it comes to ABI stability here than Python though.

Linux has no stable ABI :-)

Re: “Python's batteries are leaking”

#176

Post by _hardwaregeek »

Jach wrote: post #125
_hardwaregeek wrote: post #53

I've wondered about standard libraries for a while now. What happens if you discover a security vulnerability in your stdlib? Presumably you'd have to bump the language version, deploy it out and beg users to upgrade. Except, users don't upgrade stuff. While if you version the standard library, every new project will get the newer version of the standard library. Sure, there's space tradeoffs, though you could offer…

> What happens if you discover a security vulnerability in your stdlib? As the user of the stdlib, it really depends on what the security issue is. For most users, if they can verify they're not using module X, then there's no problem and no rush for them to upgrade. In a language like Python that's very dynamic, you also might be able to download a hotfix .py file provided by the language maintainers (or any other p…

> Actually users do. Not all users, but your sweeping statement isn't true of all users either. Experience and reading reports tell me that many if not most users actually upgrade, especially when there's a significant security issue and especially when upgrading is easy. 2.7.14 to 2.7.15 was a problem for no one.

Sure, some people definitely upgrade. But there's a big difference between requiring someone to actively hear and heed your warning and having them automatically upgrade whenever they create a newer project. Or even just prompting them to upgrade like NPM does for package vulnerabilities.

> For the users who don't upgrade, they're not likely to upgrade a third party / split off thing any more than the core language.

That's not the point. If your standard library is a package, any new project will automatically download the latest version of the standard library. If I have a vulnerability in an npm package, I simply push a new version and people will automatically download that new version when they create a new project. If there is a vulnerability in the Python standard library, users will continue to have that vulnerability until they actively patch it.

> Sucks for whom? I've been out of the Node ecosystem for several years, is there a pfs module that uses promises (either built-in or as an external lib)? If so users can use that if they want. Does it suck for the maintainer? I don't see how if those functions are small and don't really need any maintenance.

Not a canonical one. They're starting to add a new promise based API, but now we have two different APIs doing the same thing. What if we come up with a newer way to do async? Do we add yet another API?

> What would suck is if all the existing programs that wrote some fs-using code a long time ago and haven't had to touch it now suddenly need to go update it to satisfy people's fashions.

That's a bit of a straw man. With packages, you can still support multiple versions. It's just that fs would no longer be tied to Node. You could make a newer fs package, fs 2.0 or whatever, that uses promises. The older one would still be supported, of course, but it wouldn't be stuck in Node.

Re: “Python's batteries are leaking”

#177

Post by dataflow »

dataflow wrote: post #116
jteppinette wrote: post #101

Earlier quoted context omitted.

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

Re: “Python's batteries are leaking”

#178

Post by hermanradtke »

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

Rust is good at many things, but it's not as attractive for Python for the sort of program you write when a shell script gets a bit too complicated and you want to write it in a proper language. So Rust can get away more easily without having support for things like command line parsing in the standard library, because it isn't really trying to support situations where it would be inconvenient to give your program it…

This is a pretty niche case imo. If you really want a stand-alone dole, you can forego the use of Cargo.toml and instead use std::env::args to get command line arguments.

If it really matters, then do it right (in whatever language makes the most sense).

Re: “Python's batteries are leaking”

#179

Post by twblalock »

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.

Re: “Python's batteries are leaking”

#180

Post by maximente »

imiric wrote: post #156
jzl wrote: post #60

Earlier quoted context omitted.

The idea of "distros" for python is interesting, and to a certain extent has already happened: just look at Anaconda. I've been using built-in environment isolation tools such as virtualenv for ages but have recently switched over to using miniconda for all things python. Among other things it has amazing support across all three major OS's, and I happen to be dealing with all three at any given time. Whether one use…

As a non-scientific user of pyenv[0], would I benefit from switching to Anaconda/miniconda? [0]: https://github.com/pyenv/pyenv

not likely IMO. i've found conda - which is their environment management tool - to be a hassle unless one needs specific numpy/scipy/GPU libs. i'm using pipsi and pew, although i'll look into pyenv.
Post reply on HN