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

331–340 of 420 posts

Re: “Python's batteries are leaking”

#331

Post by sametmax »

gautamdivgi wrote: post #325
sametmax wrote: post #285

Earlier quoted context omitted.

Yes but it won't get it. And at the end if the day, people need to be able to get work done. The corporate world is full of stupid things that will never not change, or take years to change.

Where I work the solution was to use a proxy to pypi. Basically an internal pip repo (and docker, npm, maven, everything else...). All internal apps go through the internal repository that creates a local version of the package from pypi. That gives the security / compliance folks a way to block packages with security issues, etc. and at the same time provide the developers flexibility to get most of what is needed.…

Many technical solutiins exist, but the problem is political or organisational.

Re: “Python's batteries are leaking”

#332

Post by [deleted] »

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.

[deleted]

Re: “Python's batteries are leaking”

#333

Post by DonHopkins »

analognoise wrote: post #144
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 awesome, I hope it isn't jettisoned. I haven't found anything that easy to use with a similar Canvas. Being able to add items to a canvas, attach callbacks to them - without tracking them yourself, setting up the infrastructure for indexes, bounding boxes, all that stuff - I haven't found anything else as easy as Tkinter's Canvas. If there is something better, I'd love to hear about it.

Come over to the PyCairo side of The Force! It will drawn you in and fill your path with beautiful pixels.

https://cairographics.org/pycairo/

You do have a good point about Tk's canvas easy input handling though, which is something Cairo doesn't do. It's just an immediate mode drawing api like PostScript's rendering model or html canvas 2d context.

You can pass a pycairo context into C++ Python extensions, and they can go to town with it quite efficiently.

https://github.com/SimHacker/micropolis/tree/master/Micropol...

https://github.com/SimHacker/micropolis/blob/master/Micropol...

Re: “Python's batteries are leaking”

#334

Post by gautamdivgi »

sametmax wrote: post #331
gautamdivgi wrote: post #325

Earlier quoted context omitted.

Where I work the solution was to use a proxy to pypi. Basically an internal pip repo (and docker, npm, maven, everything else...). All internal apps go through the internal repository that creates a local version of the package from pypi. That gives the security / compliance folks a way to block packages with security issues, etc. and at the same time provide the developers flexibility to get most of what is needed.…

Many technical solutiins exist, but the problem is political or organisational.

Agree. At this point it was more a case of executives saying they wanted internal dev teams to use and contribute to open source and supporting orgs to come up with solutions on how that can be possible with a 0-touch approach. That’s what tipped the balance.

Re: “Python's batteries are leaking”

#335

Post by icxa »

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…

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 compatibility focus and encouragement to upgrade early and often, and the community's focus to utilize small interfaces sometimes from the stdlib itself, like io.Reader and io.Writer, or http.Handler. Added to that w.r.t. using the latest and greatest, most Go users frequently are using the latest version of Go even in production (per the go experience surveys).

I am sure it also helps that Google pays people to develop, maintain, and improve the stdlib.

Re: “Python's batteries are leaking”

#336

Post by rbanffy »

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…

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

Re: “Python's batteries are leaking”

#337

Post by bjourne »

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.

Re: “Python's batteries are leaking”

#338

Post by cosmodisk »

postgeographic wrote: post #314
hn_throwaway_99 wrote: post #211

Earlier quoted context omitted.

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

Not who you asked, but I work for a large international company, a big 4 professional services firm. I wanted to install anaconda and Jupyter on my machine (data science is not a part of my 'official' job description, but I wanted to see how much of my data exploration workflow I could speed up or automate). I had to go up three separate hierarchy ladders to get sign off. First, my own team, then IT, then our risk an…

I can't imagine myself working in a place like this..I understand there should be a level of checks, however this is just crazy...

Re: “Python's batteries are leaking”

#339

Post by icxa »

rbanffy wrote: post #336
icxa wrote: post #335

Earlier quoted context omitted.

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…

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 thing in of itself? What if the interface does a really good job describing the thing, whatever it may be? For example, Go's io.Reader/io.Writer interfaces.

I agree sometimes an interface being frozen is bad, but for example when Go standardized the context package, it simply added "Context" to the existing functions that now take a context (e.g. in the database/sql package, you have the old, Exec, Query, QueryRow functions, and after 1.8 you have ExecContext, QueryContext, QueryRowContext, which some people may view as a reason to have method overloading, but I view as adding better clarity.

Re: “Python's batteries are leaking”

#340

Post by RayDonnelly »

civility wrote: post #73
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…

> Having run up against limits of the Python standard library several times in years of writing production software in it and not just learning it, I find the batteries-not-includes-but-easy-to-install approach better on the whole. Obviously it doesn't apply to everyone, and it certainly doesn't apply to most startups or open source developers, but I spent most of the last 20 years working in environments where you h…

You can use `conda install rust_osx-64` on macOS and `conda install rust_linux-64` to use `cargo` with the Anaconda Distribution libraries and tools (including its compilers).
Post reply on HN