Hacker News Reader

Comment by yen223 | Hacker News Reader

The fact that you can have side effects on imports, and that a lot of libraries relied on side effects on import, was one of my biggest sources of frustration with Python

View on HN

What other packages have you seen abusing import side effects?

Shopify is the first one I've seen, so I don't think it's quite as common as you are implying, but I'm curious to know what other bad behavior you have found

Sometimes libraries do a switcheroo where they run interpreted code on startup to locate the "real" implementation in a shared object, and then load that and replace themselves with it. I'm not sure this is really idomatic, but here's an example of what it looks like from OpenCV:

https://github.com/opencv/opencv/blob/master/modules/python/...

Not GP but I've been bitten by plenty of first-party implicit side-effects, both intended (by not me not now) and not (by me or otherwise).

LaunchDarkly does. It does some querying behind the scenes and added a significant delay to the coldstarts of our lambda apis

Their PHP one had a similar shell_exec after-affect (c2017), caused some odd things in our logs but we backed away from that solution

SKiDL (circuit design library) does this to a very large extent...

https://github.com/xesscorp/skidl

An example in the standard library is the antigravity package. While it is an inside joke it still requires a HTTP transaction similar to the shopify package import.

Can’t you do this with any interpreted language? On ruby your import could redefine anything.

Is there any real way around that? The import keyword might as well be renamed to exec.

I think this depends on how brutal the workarounds you will accept are

Reply on news.ycombinator.com