[Python-ideas] A way out of Meta-hell (was: A (meta)class algebra) (original) (raw)
Martin Teichmann lkb.teichmann at gmail.com
Tue Feb 17 14:06:56 CET 2015
- Previous message: [Python-ideas] A way out of Meta-hell (was: A (meta)class algebra)
- Next message: [Python-ideas] A way out of Meta-hell (was: A (meta)class algebra)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
You're asking us to assume covariant metaclasses in a subset of cases, while retaining the assumption of contravariance otherwise. That isn't going to happen - we expect type designers to declare metaclass covariance by creating an explicit subclass and using it where appropriate..
How do you solve my example with ABCs? That means if a QObject (from PyQt) tries to implement an ABC by inheritance, then one first has to create a new metaclass inheriting from ABCMeta and whatever the PyQt metaclass is.
Sure, one could register the class to the ABC, but then you loose the option of inheriting stuff from the ABC. One could also write an adaptor - so using composition. But to me that defeats the point of the concept of ABCs: that you can make anything fit appropriately. In general, that smells to me like a lot of boilerplate code.
PEP 422 bypasses the default assumption of metaclass contravariance by operating directly on type instances, without touching any other part of the metaclass machinery.
So there is a problem with the metaclass machinery, and we solve that by making one certain special case work? When is the next special case going to show up? Will it also be included into type?
Greetings
Martin
- Previous message: [Python-ideas] A way out of Meta-hell (was: A (meta)class algebra)
- Next message: [Python-ideas] A way out of Meta-hell (was: A (meta)class algebra)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]