Same with people who try to act generously but then surprisingly throw a large bill your direction. I’ve been victim to this behavior a few times and I’ve cut those people out after every offense. No surprise, these people don’t tend to have friends for long.
Everybody understands that it's an opinion, it's a social convention, no need to spell it out. Just like people saying "broccoli are bad" doesn't need to be subtitled with "it's a matter of taste" or this dress looks ugly implies that it's a subjective take on aesthetics.
That's one of the selling point of the tool: you don't need a project, you don't need activate anything, you don't even need to keep code around.
Yesterday I wanted to mess around with logoru in ipython. I just ran `uvx --with loguru ipython` and I was ready to go.
Not even a code file to open. Nothing to explicitly install nor to clean up.
For a tool that is that fantastic and create such enthusiasm, I'm always surprise of how little of its feature people know about. It can do crazy stuff.
I've had mixed success with Claude. It keeps adding too much display_names to everything for example which is annoying.
In theory we could put that up, but I don't particularly want to maintain such a live example app and pay for hosting and all that, only to have it instantly crash under the load of HN :P
I've thought about extracting it, but I think it's a lot of work unless you want to support only Django and rST which is what we're using. At least the iframe part is very specific to the web framework.
A E Van Vogt can hardly be called unheard of, the null A series is quite a cult classic. But yeah, the Space Beagle is not his most well-known work.
It always surprises me (although it shouldn't) how many underrated gems there are still in the world. And new ones are produced every day.
E.G: I still think QTMN will deserve a place as a classic sci-fi author among the great ones, for "there is no antimemetics division" alone. And yet despite a solid fan following, it has never exploded in popularity. It is 10 times better than the 3 body problems, which comparatively had stratospheric success.
In movies, "Amelie" has been a planetary success, but from the same author, the excellent "The city of the lost children" is practically unknown.
Even last month, a tv show named "Nero" came out on Netflix, and while not revolutionary, is clearly above most of the crap that regularly comes out. Yet, nobody talks about it.
City Of the Lost Children is an absolute classic, good point.
However, I think there’s something to be said - sci-fi people of the 70’s all knew AE Van Vogt. This list was, for me delightful, because it reminded me of books I once owned, long ago, indeed many in this list .. back when books were how you encountered these materials. Real books were how we read, back then.
The need to know things has been radically compartmentalized by the mega-computer we’ve allowed to take over our planet, meanwhile, apropos cruel mistresses ..
Monkey patching an object attribute, such as a method or a function of a module, may affect 3rd party libraries code that use said object.
This solution is interesting, as it provides the patched code as if it were a new package, indendant of the existing one you have installed, like vendoring, but without the burden of it.
In case you want to be the only one seing your patch, this is great. It also makes the whole maintenance easier, as you don't have to wonder if you patch it at the right time or in the right way. MK can fail in many subtle edge cases.
Inheritance, particularly, is a great Mk pitfall I expect this method to transparently work with.
If you only want your own code to see the patch, then why not just wrap it?
I mean if you really need super strong isolation, you can always create a copy of the library object; metaprogramming, dynamic classes, etc, all make it really easy to even, say, create a duplicate class object with references to the original method implementations. Or decorated ones. Or countless other approaches.
My point isn't that I don't see problems that could be solved by this; my point is that I can't think of any problems that this solves, that wouldn't be better solved by things that don't do any innards-fiddling in what is arguably the most sharply-edged part of python: packaging and imports.
And speaking from experience... if you think patching can fail in subtle edge cases, then I've got some bad news for you re: import hooks.
At the end of the day, people who might use this library are looking for a solution to a particular problem. When documenting things, it's really important to be explicit about the pros and cons of your solution, from the perspective of someone with a particular problem, and not from the perspective of someone who's built a particular solution. If I need to drive a nail, and you're selling wrenches, I don't want to hear about all of the features of your wrenches; I want to know if your wrench can drive my nail, and why I would ever want to choose it instead of a hammer.
I can think of a lot of differently-shaped metaphorical nails that fall under the broad umbrella of "I need to change some upstream code but don't want to maintain a fork". And I can think of a whole lot of python-specific specialty hammers that can accomplish that task. But I still can't think of a signle situation where using import hooks to solve the problem is doing anything other than throwing a wrench into a very delicate gearbox. That is the explanation I would need, if I were in the market for such a solution, to evaluate modshim as a potential approach.
> I mean if you really need super strong isolation, you can always create a copy of the library object; metaprogramming, dynamic classes, etc, all make it really easy to even, say, create a duplicate class object with references to the original method implementations. Or decorated ones. Or countless other approaches.
> My point isn't that I don't see problems that could be solved by this; my point is that I can't think of any problems that this solves, that wouldn't be better solved by things that don't do any innards-fiddling in what is arguably the most sharply-edged part of python: packaging and imports.
All these examples have the dependency order wrong, and you're right on those - it's simpler to wrap them somehow. But this is doing something different, that is either much harder or outright impossible with those methods: Tweaking something internal to the module while leaving its interface alone. This is shown in both their examples where they modify the TextWrapper object but then use it through the library's wrap() function, and modify the Session object but then just use the standard get() interface to requests.
In that case I'd opt for dynamic module creation using metaprogramming instead of an import hook. And I personally would argue that grabbing the code objects from module members and re-execing them into a new module object to re-bind their globals is simpler than an AST transformation.
But regardless of the transformation methodology: the import hook itself is just a delivery mechanism for the modified code. There's nothing stopping the library from using the same transformation mechanism but accessing it with dynamic programming techniques instead of an import hook. And there's nothing you can't do that way.
