Hacker News Reader

Untrue, you could literally replace `__import__` in python and achieve the same thing: https://docs.python.org/3.8/library/functions.html#__import_...

Unless something has changed or there's a detail involving builtins I'm not aware of, I don't think this would work, for the same reason as the most common pitfall when mocking functions in python: You have to replace it where it's used, not where it's defined. To do that on a module, you have to first import that module - and then all the imports at the top of it would've already run.

> To do that on a module, you have to first import that module - and then all the imports at the top of it would've already run.

Why not just replace the `__import__` function at program startup, when you haven't imported anything? Monkey patching `__import__` at any other time seems like a bad idea.

Sorry, I think you're right. I think the actual problem I was trying to get at is that Python makes it easy to both import from a module and bind the imported functions/values to local names at the same time. This means the values get bound privately in the module, instead of always being late bound by accessing the module as a dictionary. And because the code in libraries uses this way if importing things, you can't get at the old names if you try to hotload a module.

The docs for Python's importlib say as much:

> If a module imports objects from another module using from … import …, calling reload() for the other module does not redefine the objects imported from it — one way around this is to re-execute the from statement, another is to use import and qualified names (module.name) instead.

But Lua isn't actually different here since you can still bind the members of an imported module to local names manually, it's just that there is no "from" keyword that does this for you. My personal theory is because of the lack of something like "import * from" in Lua, it became more common for library authors to use late binding and access the returned module by indexing into it. However this is just my personal theory.

Also, now that I think about it you still have to make adjustments to your code in order to have hotloading be feasible, even in Lua. I deliberately chose to use late binding in the code I wrote with "qualified names" (really just table indexing). And all the third party dependencies are versioned in the project's repository, and don't have dependencies on other external modules, so there was no need to worry about a dependency breaking hot reloading because it uses imports differently. I think this might be a cultural thing. A lot of Lua libraries are written in a single-file, no-dependency manner which makes them much easier to integrate in the ways I want. Python seems to have a much larger ecosystem with many external dependencies depending on others.

So yes, I think it makes sense that Python could have module reloading, but the problem is that the language encourages the use of local binding from imports which is incompatible with it, and there is already a lot of code that imports things like that, so it's not as practical if you're using libraries from pip or use "import <...> from" anywhere in your codebase.

I think you have problems if you just write local foo = require ("foo") in two different files and you want to replace the module object in both of them at once.

Edit: the below is probably wrong about what you're doing. It sounds like your require-replacement merges the new return value of a module into the old one, so code that accesses stuff through the module's top level table will get the right result.

Wrong stuff: Maybe the hot reloading system you use relies on modules mutating the module object rather than making a new one. This is pretty unusual among Lua modules though. I usually see people unconditionally make a table and return it.

Yes, the table merging is what mine actually does. It clears the old table reference and inserts the contents of the new module into it. It seems to work well enough for my use-case.

    from importlib import reload

What sort of things can't be accomplished using import hooks?

https://docs.python.org/3/library/importlib.html#module-impo...

I recently wrote a hot reloader for Lua[0]. It's actually a port of something I had done a decade ago in Python! Last time Python hot reloading came up on HN, I asked the author about this approach, and the only problem seemed to be that it was not so great if one was accessing the values one wanted replaced from multiple threads. Lua avoids this problem only by not having a multithreaded interpreter.

[0] https://github.com/sharpobject/reload

IIRC Lua has the same issue as Python btw, it includes the current directory in the import path list by default.

mpv was the latest victim: https://github.com/mpv-player/mpv/commit/cce7062a8a6b6a3b

`require` is even better than you've indicated: it simply calls the contents of `package.loaders`, in order, on any new string it's given.

So in many instances, there's no need to replace the require builtin: one may simply add a new function to `package.loader`, anywhere in that order that's useful.

I've done this, and draw most (basically all) modules out of a SQLite database. It works like a charm.

If one has need to invalidate the cache for a given module, as comes up in live coding environments, simply set the require string in `package.loaded` to `nil`. Small caveat: the `package.loaded` table is 'special', in that the C which `require` is written in hard-codes a reference to it: one may not simply replace `package.loaded` in the global namespace and expect the new one to be referenced.

> `require` is even better than you've indicated: it simply calls the contents of `package.loaders`, in order, on any new string it's given.

Python’s import goes through the configured finders (sys.meta_path) and invokes them in-order with the name of the package being imported until one of them returns an import spec. Sound ‘bout the same to me?

I’ve written loaders which created “virtual” modules on-demand in the past.

I don't recall saying anything about python at any point in the post you're replying to.

The discussion is about python and the comment you’re replying to specifically (and largely incorrectly) trying to contrast lua’s require with python’s import?

Nodejs has require too

Odd that Perl isn't on that list since it was the basis of yaxu's first live-coding performances before he developed Tidal.