Consideration of __assignment_to_self__, __meta__ dunders, meta() magic-method, pureread(), purewrite(), purefunc() builtins
This is one of the broken out pieces from a previous discussion
Impetus and Introduction
I tried writing a ProxyType class, and an implementation using it which had the goal of fully transparently having an on-disk and in memory representation of a data structure as .yaml. I found a number of stumbling blocks which I believe can be used to explore ways to improve the language. I’m first going to establish the technical basis for these. Afterwards, I’ll attempt to sufficiently prove their merit by covering the value which they could bring. Lastly, I will propose concepts for how they could be implemented.
Technical Basis
The __meta__ dunder, meta() builtin, and the Frequent Need of Higher-Level Programmatic Communication
My current work with Django and thinking on the ProxyType has made me realize that there is frequently a critical, but unfortunately abstract, use-case for types to describe themselves or augment the way the object behaves. For Django’s need, I’ll defer to the Model types use of _meta. For a ProxyType, there needs to be a standard and regular way to augment at runtime how to proxy. I am reserving the justification for the next session. This section only establishes that there is a strong pattern which ought to be more formalized.
Value and Merits
This section attempts to establish sufficient value for each of these changes through high-level use-case examples. It is not meant to be comprehensive and is surely going to be the most critical section for debate. Rather than be thorough to an extreme degree, I intent to expand on this through follow-up discussion. I believe doing so is more efficient and robust.
Use-case example for __meta__ dunder and meta() builtin
The Django Model type is an easy example for handling metas in a standard way. Similarly with the aforementioned grid compute example utilizing a ProxyType which would need to handle updates in network configuration. There are doubtless other major examples. There is an already established need and similar usage. I believe it is time to consolidate and standardize.
Conceptual Implementation
This section proposes a way to go about implementing these proposals conceptually. These proposals are not sacred. They are merely a way.
An implementation for __meta__ dunder and meta() builtin
In order to allow for operating on objects and types with respect to __mro__, an implementation utilizing .meta(*args, **kwargs) on a variable is not viable. This is similar to how we think about and use getattr() and setattr(). To follow with those methods, I propose type.meta(subject, *args, **kwargs) for using alternate implementations (presumably implementations in __mro__) and meta(subject, *args, **kwargs). The former will call the specified type’s __meta__ while the latter uses the subject’s __meta__.