Class metadata, static type checkers, intellisense

[wpbonelli]

This being a consciously minimal (read: heinous) hack job at the moment, little of a decorated class' metadata survives the transformation. Tab complete doesn't work, nothing useful shown on hover, etc.

(Note I am talking about Python class metadata, not attrs field metadata.)

We want all the original metadata, modified with some new attributes: name, parent, etc.

I think we don't need to wrap/replace the class init method as is done now. Better to build on attrs as much as possible*. @xattree can wrap @attrs.define(), use field_transformer to add the new fields, and use a post-init hook to create the datatree? With that (plus maybe functools.wrap?) I think attrs will do the rest, and metadata will work.

*To guarantee metadata, attrs rewrites the classes by hand, compiles them, and registers them globally. Trickery best left to experts.

[wpbonelli]

This is working now. No init wrapping necessary.

[wpbonelli]

Not entirely working yet.

For some reason the xattree-managed fields aren't showing up in hover, tab complete, etc. Only the user-defined fields. I figured field_transformer would make this work. Maybe the mypy plugin hack is necessary too? But the VSCode python extensions runs on pyright which should be covered by dataclass_transform?

[wpbonelli]

For some reason the new fields aren't showing up in hover, tab complete, etc. Only the old fields.

I am starting to wonder if this is a feature not a bug. It's in keeping with the whole we don't change any appearance or behavior of your class, just parasitize/augment it theme.

But I would still like to know how to make it work / what I did wrong with the mypy plugin

[wpbonelli]

What follows should have been more obvious, but I am dull. Mypy and pyright can't see fields added by a field transformer (even if we update __annotations__) because they are static type checkers. They don't run the code, they just look at it.

So, there is nothing to be done for pyright, hence #29. I am trying to hack up a mypy plugin based on the attrs mypy plugin in #30 with limited progress but no cigar yet. If eventually successful, that should at least provide mypy support.

I'm still not convinced this situation is bad. That the class should look the same, you don't know anything's different unless you look closely, is kind of the point? Consumers can forward the xattree-managed fields with proper type-hinting if they want to?

I might just be coping for failure to understand why #30 doesn't work