This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author seberg
Recipients petr.viktorin, seberg
Date 2021-12-16.17:20:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1639675202.53.0.0394249266258.issue45383@roundup.psfhosted.org>
In-reply-to
Content
It is probably early, but I am starting to like the idea of a "C MetaClass factory" helper/indicator.

It seems to me that yes, at least `tp_new` cannot be called reasonable for a class that is created in C, it is just too confusing/awkward to try to push the C stuff _through_ the Python API.  (And the Python API is the typical one that should not be inconvenienced)

Which gives two possibilities if I want this capability?:
1. Force use of a custom class factory in Python (i.e. not through `__new__`).  But that seems hard, since I need to refuse `__new__()`!).
2. Use a class factor in C which never calls `__new__` and knows that this is OK.

This is not my turf, so I like unholy, but maybe pragmatic things :).  Would a slot/flag indicating `Py_using_metaclass_cinit_pretty_promise_please` "solve" these issues?

I mean, we have two ways to create classes (C and Python), I am not sure it is plausible to untangle this on the MetaClass level, so maybe the only way forward is to embrace it: Some Python MetaClasses just can't be instantiated from C, because we don't know it will work.  If we want to allow instantiating the MetaClass from C, we need some way to set this up.  And either we cannot use `PyType_FromSpec` then, or we need to tell it that we know what we are doing.
History
Date User Action Args
2021-12-16 17:20:02sebergsetrecipients: + seberg, petr.viktorin
2021-12-16 17:20:02sebergsetmessageid: <1639675202.53.0.0394249266258.issue45383@roundup.psfhosted.org>
2021-12-16 17:20:02seberglinkissue45383 messages
2021-12-16 17:20:02sebergcreate