-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Add slots to dataclasses with Python 3.10+ #9413
Conversation
|
3.x already has slots |
Codecov ReportAll modified and coverable lines are covered by tests ✅
✅ All tests successful. No failed tests found. Additional details and impacted files@@ Coverage Diff @@
## master #9413 +/- ##
==========================================
- Coverage 98.73% 98.73% -0.01%
==========================================
Files 121 121
Lines 36730 36728 -2
Branches 4383 4384 +1
==========================================
- Hits 36264 36262 -2
Misses 314 314
Partials 152 152
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ 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.
Let's roll it out.
When we drop py3.9, we can replace all affected code by a single find+sed command.
CodSpeed Performance ReportMerging #9413 will not alter performanceComparing Summary
|
I'm 50/50 on if we should move this forward as I'm not sure 4.x will be out by the time we drop python 3.9 support and once we do we can add
slots=Trueto all the dataclasses anyways (if we don't forget)What do these changes do?
Add slots to
dataclasseswith Python 3.10+. No need to backport as 3.x usesattrsand already has slots here.This idea comes from https://github.com/esphome/aioesphomeapi/blob/main/aioesphomeapi/model.py where we have a lot of small data classes generated from protobuf messages but still need to support older python.
related issue #4618 (comment)
Are there changes in behavior for the user?
no
Is it a substantial burden for the maintainers to support this?
no