Hacker News Reader

Comment by nirushiv | Hacker News Reader

> `import shopify` makes an API request.

Especially for a company that prides itself on great API design, this is head scratching.

‘shopify.Init()’ seems like such an obvious solution

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

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

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

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

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