Hacker News Reader

Comment by andrewmcwatters | Hacker News Reader

I've noticed that instead of defining requires at the top of Lua files, if you can know your own program well enough, defining them right before the dependency is actually used makes large Lua programs much, much quicker. Generally speaking, startup times can be a sped up by a meaningful factor.

I suspect this change in Python will dramatically improve the performance of such large programs as well.

View on HN

> I suspect this change in Python will dramatically improve the performance of such large programs as well.

Makes packaging super fun too, where you need to hit every possible path so you don't miss anything imported in 1% of the execution paths :)

Can't you do some kind of static analysis instead?

Yes. It is much more clear to be explicit though.

Safer too.

Depends if your code has horrors like this lurking in it:

m = importlib.import_module(requests.get("http://localhost:8000/package_name").content.strip().decode("ASCII"))

If you want even better nightmares, you can make localhost:8000 forward to a container running claude code with --dangerously-skip-permissions which uses an unkindness of mcp servers to control that endpoint on the fly based (amongst other sources) on 4chan's /b/.

Better to let the viewers on a twitch stream vote for it.

> which uses an unkindness of mcp servers

I guess you meant "a feature of MCP servers which is unkind", but I couldn't help but interpret "unkindness" as the collective noun for a group of MCP servers.

That was indeed the intent. I first considered "a conspiracy" like with lemurs, but eventually felt that "unkindness" was more appropriate.

Since this should be a rare thing I don't think it's unreasonable to require users of patterns like this to put some kind of special annotation for that static analysis tool saying "it may not look like it but I'm doing an import here".

I can't even express how negatively I feel about build/packaging systems that process dependencies based on code-level imports instead of some explicit build manifest separate to the code.

You and me both, but life as a consultant/freelancer requires you to drag yourself through dirt sometimes to make it out on the other side.

Not to mention the potential for runtime errors long after the code has started up.

Or, you could just use a project-level specification file to list dependencies rather than looking for imports in the code, trying to figure out what they resolve to, and trying to package the results.

You have always been able to do the same thing in Python. This PEP isn't needed for that functionality.

Yeah, I'm aware the same behavior is available, but this proposal creates a call trigger on the dependency which requires far less analysis on larger projects to understand where the import needs to be moved to.

You have to create wrappers in languages like JavaScript, Lua, Python, etc. to create the same behavior.

You can declare imports at the beginning of a program that don’t load until they are used?

"defining them right before the dependency is actually used"

Reply on news.ycombinator.com