Live data from Hacker News

“Python's batteries are leaking”

pyfound.blogspot.com

371–380 of 420 posts

Re: “Python's batteries are leaking”

#371
post #369

Earlier quoted context omitted.

He is not. He has been working on it for 25 years and he is just fed up to having to explain again and again the same things. He doesn't want to see the careful and long work he did being dragged to a standard he considers lower. There is always a new person coming with a new idea. It's exhausting, because it's required to make the language evolve, but it's also a new opportunity to screw things up evertime. And if h…

I dunno, Python is the epitome of a "meh" language. Guido has help Python back with his antiquated "get off my lawn" attitude since he created it. The language itself is inferior in expressiveness and performance to almost any other modern language. The only reason anyone uses it anymore is the network effects of the library are very strong, especially is fields relating to ML and data science.

Those libs did not come out of nowhere, and the language did not rise from 1991 to the today without inherent qualities that draw people to it.

Python didn't have any specialty like PHP, or an accidental monopoly like JS. It didn't come with a killer app like Ruby. It hasn't been made by a giant company like Go.

It's pretty much a self-made language.

Re: “Python's batteries are leaking”

#372
post #269

Earlier quoted context omitted.

Pardon me, but why wouldnt you be able to just run an old python if tkinter came out of the stdlib, or even just package it with whatever you are distributing?

The point was that it’s much easier to distribute a single file app than it is to “correctly” distribute a full app with dependencies bundled.

Could you use cython to accomplish this? I personally haven’t used it, but looking at some examples it looks really straightforward.

Re: “Python's batteries are leaking”

#373

Earlier quoted context omitted.

Oof, I wasted a good hour+ trying to convert from one to the other. Maybe there's an easy way to do this, but not many people on IRC knew (or were available at the time).

Assuming the keys are Hash + Ord, wouldn't that just be: for (k,v) in &src { dst.insert(k,v); } ?

Yes, that's what I ended up doing, but the error confused me and I ended up looking for a less hacky way for more than an hour until I said "fuck it" and just did that.

Re: “Python's batteries are leaking”

#374
post #368
post #323

Earlier quoted context omitted.

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…

I've never coded Rust - is there any distinction between a really important crate used by millions of people and something really obscure with 3 users? Are all the crates subject to security audit?

Anyone can upload to crates.io without review.

Re: “Python's batteries are leaking”

#375
post #339

Earlier quoted context omitted.

This approach is useful for a while, but once something is in a stdlib, its interface is frozen forever.

(I am trying to tie the two concepts together from your reply, so I am not saying this to come off as combative but understand your objection) - What would you define as a while? I think Go has done well with it, given that it is almost 10 years old now at this point, and in reality, was in development internally at Google years before that. - Do you feel like an interface being frozen forever is particularly a bad t…

Go was and is by design a "boring" language. The core designers didn't have much trouble looking at decades of prior art and getting it mostly right.

Rust libraries should be expected to take a few tries to get right, especially earlier in its lifecycle. There's more possibilities and less experience in the language.

You can see a similar effect in Haskell, which has iterated many basic bits of functionality many times over.

Re: “Python's batteries are leaking”

#376
post #369

Earlier quoted context omitted.

I dunno, Python is the epitome of a "meh" language. Guido has help Python back with his antiquated "get off my lawn" attitude since he created it. The language itself is inferior in expressiveness and performance to almost any other modern language. The only reason anyone uses it anymore is the network effects of the library are very strong, especially is fields relating to ML and data science.

Those libs did not come out of nowhere, and the language did not rise from 1991 to the today without inherent qualities that draw people to it. Python didn't have any specialty like PHP, or an accidental monopoly like JS. It didn't come with a killer app like Ruby. It hasn't been made by a giant company like Go. It's pretty much a self-made language.

There’s other languages that fit the same criteria that are much better: Scala, OCaml, Racket, or Haskell.

The inherent qualities that draw people to Python are that it’s so inexpressive and crippled that you can learn it in 30 minutes.

Re: “Python's batteries are leaking”

#377
post #307

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…

From a different perspective, servers usually have a maintenance cycle to update system package where the standard library could be updated, user package on the other hand have to be updated by the user themselves ( and they could stick with the obsolete version if they want too, and could have a per project package version ) there is no convenient way for the user to update all the versions.

> there is no convenient way for the user to update all the versions.

Perhaps I'm misreading this, but isn't that the purpose of package managers? I can run an `npm install foo` and update it at will.

Re: “Python's batteries are leaking”

#378

Earlier quoted context omitted.

> Where shall we draw the line and how do we decide? Why does there need to be a line? As long as the package manager is part of the core distribution (even if it is itself an upgradable package) why not moving everything into packages, even if some are maintained by the core team and have the stable version at time of distribution release included with the core distribution—but perhaps installed only on demand?

How would you get standards like unittest? pip install unitest? Oops I spelled it wrong wonder what I just installed?

> How would you get standards like unittest?

“have the stable version at time of distribution release included with the core distribution”

Ruby, for instance has both “default” and “bundled” gems with the core distribution.

https://stdgems.org/

Re: “Python's batteries are leaking”

#379
post #207

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…

> The problem is that I cannot count on being able to install new software in many environments.

The approach Ruby is taking with gemification and default and bundled gems for standard libraries is equivalent to the traditional standard library if you can't install updates, but superior in other cases.

Re: “Python's batteries are leaking”

#380

A lot of this is side effects of the Python 2 vs 3 schism imo. If it weren't for that situation, practically everyone would on be 3.x, and supporting older versions wouldn't be important, so package maintainership wouldn't be as difficult. Put another way, the whole Python universe from my point of view has become a cautionary tale about breaking changes. Given Python's popularity, this might be an unpopular opinion,…

Yep, Python is just a plain, boring interpreted language from the 80s that was designed as a reaction to Perl's syntax, and is unfortunate enough to contain a lot of dynamic properties that designing a JIT compiler for it is a massive amount of work. It can be seen in context with interpreted languages during that time such as Perl, Tcl, awk, sed, etc. It became popular because it was baby's first language taught in universities to both CS and non-CS majors. Python is simply not competitive in terms of language features with modern programming languages. I tend to assume most of the people praising Python are amateur or new programmers.
Post reply on HN