-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add collect_fields option to SignalGroupDescriptor, and accept a SignalGroup subclass #291
Conversation
CodSpeed Performance ReportMerging #291 will not alter performanceComparing Summary
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #291 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 22 22
Lines 1973 1986 +13
=========================================
+ Hits 1973 1986 +13 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
very nice. Good to go by me, one very minor comment on camel case naming of the created group class
The PR changes the previous default behavior when a subclass of Also, |
i agree. and i think it's a good improvement thanks.
ah yeah, that's probably a pretty easy error to run into, since it only requires setting one more thing: let's make I'll make some comments inline |
actually, it's a bit hard to do inline since you haven't touched all the lines needed here. i'll make a PR to your PR |
ok, I will add the early error then. |
hang on just a minute... PR incoming |
make generic, misc suggestions
(sorry if that gave merge conflicts) :) |
ah whoops, looks like I forgot to add |
It should be fine now :) |
arggg... pydantic errors in the test_group_descriptor. I had you add |
ok, I'll make the changes. |
mmmh there are other problems with types and coverage. Maybe I'll let you deal with them :), you can modify this PR directly if you don't mind. |
will do! was just noticing that. Going to add a |
I reverted the generic stuff, and will deal with it in another PR. The reason is that, as implemented, it makes it unnecessarily ugly to know that the @dataclass
class T:
x: int = 0
e: ClassVar[SignalGroupDescriptor] = SignalGroupDescriptor()
t = T()
reveal_type(T.e) # N: Revealed type is "psygnal._group_descriptor.SignalGroupDescriptor[Any]" ... fine
reveal_type(t.e) # N: Revealed type is "Any" .... BAD this would work ... but I think it's unnecessarily ugly @dataclass
class T:
x: int = 0
e: ClassVar[SignalGroupDescriptor[SignalGroup]] = SignalGroupDescriptor() |
To be implemented
_build_dataclass_signal_group
cannot be cached withlru_cache
, so the result is cached in theSignalGroupDescriptor
instead.PR extracted from #265