Implementing PEP487 -- Simpler customisation of class creation AKA "metaclasses-lite" #16796
Unanswered
AJMansfield
asked this question in
Core Development
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
- 7BE3
Uh oh!
There was an error while loading. Please reload this page.
-
I'm creating this post to centralize other discussions and invite comments around my efforts to implement PEP 487 in micropython, and help me step back into the ring again to continue where I left off with this 5 months ago.
To summarize the development history so far, though:
Micropython does not, at the moment, support PEP 3115 metaclasses, and one should be reasonably skeptical about the idea that it ever even will or should try to. However, the much lighter-weight mechanism in PEP 487 feels like a much more plausible fit, and still offers a lot of the same expressive power that full PEP 3115 would to library developers and users of their libraries.
There are two main halves to PEP 487:
__set_name__, and__init_subclass__.As documented in issue #15501,
__set_name__is closely associated with the python descriptor protocol, which micropython implements behind theMICROPYTHON_PY_DESCRIPTORSfeature flag.I have an active pull request, #15503, that implements this feature. At the time, there was some uncertainty about corner cases involving how modifications to a class's namespace made in a
__set_name__should affect other aspects of class initialization, a request for CPython to document or specify this behavior, and at minimum a desire to at least have cpydiffs that would document any differences here.I also showed off a preliminary implementation of the
__init_subclass__half of PEP 487 in #15511. Some of the things this patch worked around are no longer relevant, and this will need to be reworked.This effort then went dormant as I needed to move on with workarounds in order to deliver the software I was developing at the time.
Now that my time has freed up somewhat I'm able to spend time on this again. As part of my efforts to re-acquaint myself with the codebase and signal my intentions to resume pushing for this, I've proposed alternative PRs #16786 and #16787 that docum 8000 ent each feature's current absence with cpydiff tests, while I work on acquainting myself with the past 5 months of other changes in order to continue development.
Beta Was this translation helpful? Give feedback.
All reactions