Skip to content
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

Merged
merged 11 commits into from
Mar 11, 2024

Conversation

getzze
Copy link
Contributor

@getzze getzze commented Mar 6, 2024

To be implemented _build_dataclass_signal_group cannot be cached with lru_cache, so the result is cached in the SignalGroupDescriptor instead.

PR extracted from #265

Copy link

codspeed-hq bot commented Mar 6, 2024

CodSpeed Performance Report

Merging #291 will not alter performance

Comparing getzze:collect_fields (7db13a7) with main (f37c26f)

Summary

✅ 66 untouched benchmarks

Copy link

codecov bot commented Mar 6, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (f37c26f) to head (7db13a7).
Report is 2 commits behind head on main.

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.
📢 Have feedback on the report? Share it here.

Copy link
Member

@tlambert03 tlambert03 left a 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

src/psygnal/_group_descriptor.py Outdated Show resolved Hide resolved
@getzze
Copy link
Contributor Author

getzze commented Mar 11, 2024

The PR changes the previous default behavior when a subclass of SignalGroup is provided (now it collects the fields). But this default behavior was not clearly documented so I believe it's fine.

Also, signal_group_class=SignalGroup and collect_fields=False fails without a proper error message and only when accessing foo.events. I was not sure what was best, or raising an error at SignalGroupDescriptor.__init__ or fallback to collect_fields=True with a warning.

@tlambert03
Copy link
Member

But this default behavior was not clearly documented so I believe it's fine.

i agree. and i think it's a good improvement thanks.

Also, signal_group_class=SignalGroup and collect_fields=False fails without a proper error message and only when accessing foo.events. I was not sure what was best, or raising an error at SignalGroupDescriptor.init or fallback to collect_fields=True with a warning.

ah yeah, that's probably a pretty easy error to run into, since it only requires setting collect_fields=False (as the other is the default). So I agree, add an exception in the __init__ if collect_fields is False and signal_group_class is SignalGroup

one more thing:

let's make SignalGroupDescriptor a generic now: SignalGroupDescriptor(Generic[GroupType])

I'll make some comments inline

@tlambert03
Copy link
Member

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

@getzze
Copy link
Contributor Author

getzze commented Mar 11, 2024

ok, I will add the early error then.

@tlambert03
Copy link
Member

hang on just a minute... PR incoming

@tlambert03
Copy link
Member

getzze#1

make generic, misc suggestions
@tlambert03
Copy link
Member

(sorry if that gave merge conflicts) :)

@tlambert03
Copy link
Member

ah whoops, looks like I forgot to add from __future__ import annotations in test_group_descriptor

@getzze
Copy link
Contributor Author

getzze commented Mar 11, 2024

It should be fine now :)

@tlambert03
Copy link
Member

tlambert03 commented Mar 11, 2024

arggg... pydantic errors in the test_group_descriptor. I had you add __future__.annotations thinking there wasn't any runtime typing used in that test module, but it looks like there was after all. So i guess we'll need to remove that import at the top, and use Optional[Type[SignalGroup]] instead of type[SignalGroup] | None

@getzze
Copy link
Contributor Author

getzze commented Mar 11, 2024

ok, I'll make the changes.

@getzze
Copy link
Contributor Author

getzze commented Mar 11, 2024

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.

@tlambert03
Copy link
Member

other problems with types and coverage. Maybe I'll let you deal with them :)

will do! was just noticing that. Going to add a # pragma: no cover and be done with it

@tlambert03
Copy link
Member

tlambert03 commented Mar 11, 2024

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 __get__ method of the descriptor returns a subclass of SignalGroup:

@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()

@tlambert03 tlambert03 merged commit 2143681 into pyapp-kit:main Mar 11, 2024
54 checks passed
@tlambert03 tlambert03 changed the title SignalGroupDescriptor collects fields with a SignalGroup subclass feat: add collect_fields option to SignalGroupDescriptor, and accept a SignalGroup subclass Mar 11, 2024
@tlambert03 tlambert03 added the enhancement New feature or request label Mar 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

Successfully merging this pull request may close these issues.

2 participants