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

391–400 of 420 posts

Re: “Python's batteries are leaking”

#391

Post by rafacm »

jMyles wrote: post #242
ma2rten wrote: post #213

Earlier quoted context omitted.

Actually I feel like asyncio is the one thing that should be part of the standard library. It even introduces special syntax. To be honest, I think she might be biased here given that she maintains a competing package.

> To be honest, I think she might be biased here given that she maintains a competing package. I hope that you take time to reconsider this view. We're not talking about competition in the same sense as in a capitalist system, between two companies. Prior to asyncio, Twisted maintained the only viable flow control for serious asynchrony in python. Put another way, python had no standard flow control for serious async…

> cue Gary Bernhardt's Pretzel Colon

Could you provide a reference/explanation for this? Thanks in advance!

Re: “Python's batteries are leaking”

#392

Post by HelloNurse »

hn_throwaway_99 wrote: post #211
bsder wrote: post #207

Earlier quoted context omitted.

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…

> 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. Can you explain this more? What kind of place do you work? I've had some experience with large, bureaucratic companies, but nothing ever so far as "you can't install any other libraries."

If you must work with one hand tied behind your back you are fucked, and your company is even more fucked. Your priority should be supporting your managers who want to get things done in the struggle against centralized IT managers who want to repress aspirations to work.

I'm afraid the standard library has to be aligned with the needs of more normal users who, as already discussed, want to allow libraries to have their own release cycles and to be more "opinionated" and specialized than the standard library would permit.

Re: “Python's batteries are leaking”

#393

Post by pornel »

rmtech wrote: post #368
pornel wrote: 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?

There is no technical distinction. The community is working on a WoT/review tool (cargo-crev), but in the meantime you can see who has published the crate and who uses it. The de-facto standard crates are maintained by Rust team members or well-known authors.

Re: “Python's batteries are leaking”

#394

Post by pornel »

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

But then you have six versions to have security fixes, how do you do that?

You release fixes for older versions according to semver.

Re: “Python's batteries are leaking”

#395

Post by pornel »

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

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

When a crate is part of a public interface, that's harder, indeed. Crates solve it in a few ways:

• crates that expect to be used for interoperability are often split into smaller crates (like API and back-end, or low-level API and high-level API), so that they can evolve some parts without breaking others.

• sometimes breaking changes are technically breaking, but easy to upgrade (e.g. methods renamed, args reordered). In that case most users catch up quickly.

• in desperate cases, a new version can import its own old version and re-export old structs and interfaces that haven't changed, so they're compatible across major versions.

• proper sharing and composition should be done via traits, so that you can implement a trait for any number generator, not just one version of one implementation.

Re: “Python's batteries are leaking”

#396

Post by sametmax »

anderspitman wrote: post #387
sametmax wrote: post #371

Earlier quoted context omitted.

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.

I'm not sure if I'd agree. Python was pretty lucky to have numpy/pandas when "data science" started taking off a few years ago. It easily could have been another language.

Numpy arrived in python because the language allowed mathematicians who were not programmers to get their job done and then do stuff that were not math related as well.

They don't have the desire to learn what a monad is, they don't want to type variables when exploring a badly formated heterogenous data dump, and they do want to be able to read the code of their intern freshly out of school once he leave without writing down any doc.

Re: “Python's batteries are leaking”

#397

Post by sametmax »

newen wrote: post #390
mruts wrote: post #376

Earlier quoted context omitted.

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.

Agreed. Most people who like Python seem to never have had experience with functional languages.

Of course we do. We just happen to value things you don't. When you don't work with 10x programmers and experience the corporate world, you suddently see purity in a very different light.

Re: “Python's batteries are leaking”

#398

Post by pornel »

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

This is interesting. Go seems to have the complete opposite stance. The stdlib are some of the most useful and well written packages you can use in the Go ecosystem, and then you have the "extended" standard lib which isn't 100% in the language yet, and even further sometimes concepts from useful community packages make it into the std lib. As to why this is the case, I think maybe this is enabled by Go's backward's…

No doubt Go's stdlib is useful, and there's plenty of things it got right. However, it's not immune to making some mistakes and having to freeze them forever. The more functionality you add, the harder it gets to get it perfect on the first (and only) try. Search for "deprecated site:https://golang.org/pkg/" finds various issues ranging from cosmetic mistakes to entire packages being deprecated.

    CompressedSize     uint32 // Deprecated: Use CompressedSize64 instead.
    CompressedSize64   uint64 // Go 1.1

    // Deprecated: HeaderMap exists for historical compatibility
    // and should not be used.
Requirements may change over time, so even getting something perfect now is not a guarantee it will last (e.g. pre-UTF-8 languages froze byte-oriented or UCS-2 strings, even though these were good decisions at the time).

Sometimes improvements are not worth the cost of deprecation and replacement, so things are just left as they are. For example, an HTTP interface designed for request-response HTTP/1 works for stream-oriented HTTP/2, but support for push, prioritization and custom frames is bolted on. Packet-oriented HTTP/3 will add even more stuff that will have to be retrofitted somehow to the old model. Libraries can come and go, but std can't just throw away an old interface and start over.

Re: “Python's batteries are leaking”

#399

Post by Havoc »

Maxious wrote: post #237
Havoc wrote: post #227

Earlier quoted context omitted.

>What kind of place do you work? Not OP but same. I'm currently debating with myself whether I should attempt to install PUTTY. Given that port 22 is blocked and it's not needed for my core role it'll be dicey if I get challenged. Pulling executable code off some repo...no way that is ever officially passing muster. People might do it anyway, but on a personal risk basis. >Can you explain this more? Place that are he…

I'm glad Windows 10 has OpenSSH now: > Microsoft Windows [Version 10.0.17763.437] > (c) 2018 Microsoft Corporation. All rights reserved. > > ssh -V > OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5

I've been checking but I can't add the module. Either it's slow to get to Enterprise version or it's blocked. Not sure.

Found a work-around though - Google cloud shell being *nix works fine for SSHing about the place. Gets me around the port fw too

Re: “Python's batteries are leaking”

#400

Post by mos_basik »

rafacm wrote: post #391
jMyles wrote: post #242

Earlier quoted context omitted.

> To be honest, I think she might be biased here given that she maintains a competing package. I hope that you take time to reconsider this view. We're not talking about competition in the same sense as in a capitalist system, between two companies. Prior to asyncio, Twisted maintained the only viable flow control for serious asynchrony in python. Put another way, python had no standard flow control for serious async…

> cue Gary Bernhardt's Pretzel Colon Could you provide a reference/explanation for this? Thanks in advance!

Not GP, but Gary Bernhardt is the guy who gave the classic "Wat" [0] and "Birth and Death of JavaScript" [1] talks, and some searching turns up "pretzel colon" as the "&:" operator in Ruby [2]. I assume he's mentioned it in a screencast or something, but I wasn't able to find it.

[0] https://www.destroyallsoftware.com/talks/wat

[1] https://www.destroyallsoftware.com/talks/the-birth-and-death...

[2] https://technology.customink.com/blog/2015/06/08/ruby-pretze...

Post reply on HN