Sebastian Berg <[email protected]> added the comment:
Sorry, I need some time to dive back into this, so some things might be garbled
:). Yes, I do agree supporting a custom `tp_new` here seems incredibly tricky.
I have not thought about the implications of this, though.
> guess the safest option is to fail when the metaclass has a custom tp_new
That would seem OK, but I can't quite judge it. It may mean that I have to do
a custom factory to create new metaclass instances from Python, but that is
probably for the better anyway.
Now, calling `tp_new` is a bit useless, since from C we don't have a dict
anyway (at least not really). So yeah, this does not make sense at all for
most Python defined metaclasses... (they may want to inspect/mutate the dict)
> But at that point, this is duplicating a lot of existing functionality, and
> I'm starting to wonder if this wouldn't all be better with calling the
> metaclass instead.
I do not think I am following :(. My worry is that I want people to create a
MetaClass instance through C (but not be locked into static types forever).
My current thought is that I would like it be possible to do something like:
/* Create a new type object */
type_spec = {stuff};
newtype = PyType_FromSpec(&type_spec);
/* Finalize the MetaClass */
metatype_spec = {more_stuff};
PyArray_InitDTypeFromSpec(newtype, &metatype_spec);
Of course I can move this into a single function and create the class for the
user. But I am uncertain that piping everything through `tp_new` will help?
At some point I thought that the user should create a subclass, and I create
another class inheriting it. But it also seems convoluted and complicated.
I have no idea right now, but maybe there could also be a way to make creating
a metaclass-factory in C easier, rather than supporting `PyType_FromSpec` for
metaclasses.
(I.e. an `PType_InitFromSpec()` doing most of what `PyType_FromSpec` does, but
really meant to be only used be such metaclass factories.)
> - basicsize/itemsize could be allowed with __basicsize__/__itemsize__ in the
> dict.
Do we need this? I need the basicsize of the metaclass, but that of the class
seems fixed/OK?
> - flags: we could add mechanisms to set individual flags after the type is
> created, as needed.
Seems fine, yeah.
> - slots can usually be applied after the class is created; maybe there should
> be a public function for this.
> - members could theoretically be copied to individual descriptors; there
> doesn't seem much need for keeping tp_members around.
But a Python MetaClass (that the author may not even realize about) might need
access to these to work properly?
A bit far fetched, but...
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue45383>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
