[nirushiv]

> `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

[yen223]

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

[hn_acc_2]

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

[mikepurvis]

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

[OJFord]

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

[xeromal]

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

[edoceo]

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

[jbay808]

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

https://github.com/xesscorp/skidl

[ilovetux]

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.

[PurpleFoxy]

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

[throwaway53453]

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

[JanisL]

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