Cluegen – Python Data Classes From Type Clues
github.com
github.com
Making imports fast for data classes may solve some of the problems. Old big projects like Plone/Zope have solved this problem by making more generic lazy import system that it extensively being used.
Use zope.deferredimport package for this:
https://zopedeferredimport.readthedocs.io/en/latest/narrativ...
Though I am not sure if zope.deferredimport has been updated to play nicely with the modern typing tools like editors and MyPy.
What kloc is moderate and large? I have not run into a project where import took that long.
>I believe JS/TypeScript folks try to avoid this trap.
Have you ever had to run a node project? I haven't benched it but I think it would be faster to compile a rust project and start that up than use node. But I can't web so maybe there's special ways to make node start quickly that I just don't know about. (I think there's a law where you can get answers more quickly by declaring something impossible to trigger people into flooding you with great suggestions :-) ).
One tool I used was https://github.com/mnmelo/lazy_import but I'm not sure it's updated for Python 3.7/3.8.
> You should pronounce it as "kludg-in" as in "runnin" or "trippin". So, if someone asks "what are you doing?", you don't say "I'm using cluegen." No, you'd say "I'm kludgin up some classes." The latter is more accurate as it describes both the tool and the thing that you're actually doing. Accuracy matters.
The writing in the README reminds me of people like Derek Lowe (author of the In The Pipeline pharma/bio/whatever blog) and John D. Clark (author of Ignition!) who can create exceptional things and deliver knowledge in a humorous and engaging way.
This is probably the first library of it's kind that is unpackaged and claims that it doesn't need packaging.
He is interested in providing PoC (like with curio), but not doing what comes after.
Every ingredient in the rack is spice. There is a "proper" amount to use for the recipe. Let good taste be the guide. Never go Full [language I like to drag].
And,true to his physicist roots, he’s very good at gedankenexperimenten.
I’m unlikely to actually use this and can’t really think why I would, but that’s hardly the point.
Is he waiting patiently for the right moment to strike? Does he pretend to be dumb but is actually incredibly smart?
:-)
there’s a lot to admire in that, frankly.
(self.x, self.y) == (other.x, other.y)
but i think this would be more efficient: self.x == other.x and self.y == other.y
because you avoid creating a tuple (possibly heap-allocated) and if `.x` differs, you avoid a dictionary lookup¹ for `.y` thanks to short-circuiting. i think i benchmarked it at some point, but that was a while ago (on CPython 3.5)---
btw, i went with a similar approach (i.e everything is codegened) in my sum type library: http://github.com/lubieowoce/sumtype
i never got around to generating the methods lazily, maybe i should!
for correctness reasons i switched from interpolating raw strings to <array of (line, indent-level)> and a bunch of wrappers – generating if-elif-else chains via raw strings gets scary. but they work well enough here
---
1. iirc even though it's using slots, it still has to look up the descriptors for `.x` and `.y` in the class dictionary. another possible optimization would be to trade off memory (and extensibility) for time and "cache" those. something in the vein of
def generate(...):
...
get_x = MyClass.x.__get__
get_y = MyClass.y.__get__
...
def eq(self, other):
return (get_x(self), get_y(self)) == (get_x(other), get_y(other))
MyClass.__eq__ = eq
here, `get_x` and `get_y` would be closed-over in `eq`, so they shouldn't incur a dictionary lookup.
which of course adds significant complexity, but that may be a sensible trade-offAt first I thought: there's no way someone is this categorical about some obscure aspect of python's internals, then I noticed it's from dabeaz. What a man :)
>>> A: If you're using it, you do. You maintain cluegen.
while I know and respect dabeaz for all his work, I still prefer to rely on the "official" dataclasses module.
https://twitter.com/honnibal/status/1260544951638732801?s=20
https://github.com/dabeaz/cluegen/pull/4/commits/b506ed86697...