-
-
Notifications
You must be signed in to change notification settings - Fork 8.6k
py/modbuiltins: Keep class locals ordered as per their definition. #6130
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
base: master
Are you sure you want to change the base?
Conversation
|
I actually don't know how to test this without #5324 so perhaps once it's cleaned up this will be ready for some tests |
3dd07c6 to
888129c
Compare
|
I've just added a second commit that allows controlling the attribute order when creating a new class dynamically with |
888129c to
67e98e3
Compare
|
Thanks for accepting my I've enabled the included feature in the coverage build to run the test, let me know if this isn't the best / most appropriate way to add a coverage-only unit test. |
67e98e3 to
aaa3746
Compare
This is good, it allows to selectively create classes with ordered dicts for the locals. I would prefer to just merge that and not the commit that adds the Would it work for your use-case to just use |
py/objtype.c
Outdated
| mp_obj_dict_t *locals = MP_OBJ_TO_PTR(locals_dict); | ||
| locals->base.type = &mp_type_dict; | ||
| } | ||
| #endif |
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.
Instead of making a copy of the dict, I think it'd be much simpler and more efficient to just replace all checks in this file for locals_dict being an mp_type_dict to test for either mp_type_dict or mp_type_ordereddict. It looks like there are only 3 such checks, 2 of which are just assertions. Probably just add a macro in this file like IS_LOCALS_COMPATIBLE_DICT(locals_dict).
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.
I initially thought of this, however at a quick search I thought it looked like other parts of the codebase also expect locals to be a mp_type_dict. I'm not sure where I was looking now though, I guess I could try it out and test if it seems to work.
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.
I think it'll work... one way to test is to change all dicts that come in here to mp_type_ordereddict and then run the test suite.
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.
I tested this out, by forcing locals_dict->base.type = &mp_type_ordereddict in the code here, and all tests pass on unix coverage build. So I'd say go for this approach (I can make a PR for this part, just let me know either way).
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.
See #6176
No this only helps in a very small use case of ours. The class attribute ordering is required by The dynamic class ordering is needed for serialise/deserialise feature of structured_config where structures can be sent down the wire as json and re-created in the same order at the other end. |
|
Ok, thanks for the explanation. It could be that metaclasses would help here (to force the inherited class to have ordered members), but that's out of scope for now. |
aaa3746 to
1843734
Compare
1843734 to
0bf559f
Compare
0bf559f to
622c45a
Compare
| mp_obj_dict_t *old_locals = mp_locals_get(); | ||
| mp_obj_t class_locals = mp_obj_new_dict(0); | ||
| #if MICROPY_PY_CLASS_ORDERED_LOCALS | ||
| // keep the locals ordered |
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.
Nitpick, but this looks superfluous: it's in a block 'class ordered locals' and sets the is_ordered flag
622c45a to
29b358b
Compare
29b358b to
358bca6
Compare
c49e937 to
92795eb
Compare
92795eb to
d9f84fd
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #6130 +/- ##
=======================================
Coverage 98.38% 98.38%
=======================================
Files 171 171
Lines 22297 22299 +2
=======================================
+ Hits 21936 21938 +2
Misses 361 361 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
3dc396c to
2ca633a
Compare
425e292 to
cab3a1f
Compare
cab3a1f to
d116e1e
Compare
d116e1e to
8327b60
Compare
8327b60 to
36ce2f4
Compare
When
MICROPY_PY_CLASS_ORDERED_LOCALSbuild/board define is set this will keep all class attributes ordered as per their python definition.As discussed in #5322 (comment)