Hacker News Reader

Comment by sigmoid10 | Hacker News Reader

I think this is just a natural consequence of an easy-to-use package system. The exact same story as with node. If you don't want lots of imports, don't make it so damn easy to pile them into projects. I'm frankly surprised we still see so few supply chain attacks, even though they picked up their cadence dramatically.

View on HN

This seems a lot more due to an import running arbitrary code because stuff can happen in the top-level of a module rather than only happening in functions. From what I can tell, it seems pretty common for dynamically typed languages and pretty much entirely absent from statically typed ones, which tend to have a main function that everything else happens inside transitively. I guess this makes it easy if what you're writing is something that runs with no dependencies, but it's a pretty terrible experience as soon as you try to introduce the concept of a library.

> it seems pretty common for dynamically typed languages and pretty much entirely absent from statically typed ones

Counter-example is Go and init() function.

Interesting, I had no idea that existed! I still think there's a a difference between "here's a hook you can use to run stuff earlier" and "importing any module is fundamentally the same as running it as a script unless the module happens to use a special conditional to wrap stuff inside of" though (and I say this as someone who doesn't go out of his way to defend Go design decisions)

Also C++/Java static initialization, C# static constructors, or Rust global variable initialization, ...

Most languages have this feature Afaik

Rust doesn't have this behavior (sometimes called "life before main"). Code to initialize a static variable runs either at compile time, or lazily on first access, depending on which mechanism you use.

Yeah, I don't think that "precompute something at compile-time" is really comparable to "every import literally executes code as a script". Rust imports are actually about as far from this as I can imagine, because modules can circularly reference each other, which unless I'm misunderstanding would be an infinite loop in Python without manually breaking the chain with some form of conditional.

I'm actually kind of surprised to see comments like that one, because compile-time logic feels like the opposite end of the spectrum from what Python imports do, with "regular" code being compiled without any precomputation sitting somewhere in the middle. It seems like I didn't articulate my thoughts clearly enough though, since several people seemed to read what I was saying as being comparable.

Interesting, thanks

Static initializers in C++ - sometime ago I saw savings of some 400 ms (?) startup cost of initializing static strings from constants by moving it to some compile time thing.

Right; the issue is that this isn't happening at compile time in Python, because it's not getting compiled ahead-of-time. The equivalent would be if header files had imperative code that got executed at runtime in places where they're included.

(To preempt potential pedantry: yes, I know that you can compile Python to bytecode ahead of time, but that's not really relevant to what's being discussed here because it doesn't mean "the stuff happening in modules I import isn't happening at runtime anymore")

> the issue is that this isn't happening at compile time in Python, because it's not getting compiled ahead-of-time

What are those .pyc files for?

That was the pedantry that they were trying to preempt.

IIUC the organizations that most strongly pushed for this feature are big companies with large codebases. These tend not to be the kinds of orgs that just casually pull in dependencies from PyPI on a whim; I think it more likely that the quantity of first-party code was so large that importing all of it on startup was causing problems.

I worked in a codebase like this. The load time was insane.

We would also constantly need to put imports in function heads to effectively lazy import due to the massive risk of circular imports. We also had dynamic imports so tracking the cycles was very difficult at times.

What would your alternative look like?

Reply on news.ycombinator.com