IMO, your other proposal is more valuable since it also solves other problems (like the one I presented in my last post there). But these proposals are technically orthogonal, and I think this one (i.e. adding Abstract as a separate class) has a better chance of succeeding.
1 Like
Yeah, I’m rooting for @ruro’s idea also because it looks the most likely to be accepted despite it being a solution to only a specific (but again, the biggest) use case of multiple metaclasses.
Would be nice if my other, more general solution gets accepted but the sheer simplicity and elegance of @ruro’s idea makes it more likely to succeed.
This is already (mostly) the case. Virtual just uses metaclass=VirtualMeta and sets __slots__ = () just like ABC uses metaclass=ABCMeta and sets __slots__ = ().
The only extra complication in the original version of my proposal is that ABCMeta also automatically added Virtual to the list of base classes. My intention for this was to make it slightly easier to check whether something is virtual via isintance(obj, Virtual) instead of having to check the metaclasses of obj for VirtualMeta.
But now that you’ve mentioned it, I think that I was overcomplicating things a bit. I’ve removed this detail and now ABCMeta just inherits from VirtualMeta and adds Abstract to the end of bases.
Unfortunately, I don’t currently have enough free time to write a proper PEP or to truly polish the implementation with the proper documentation and thorough testing. But you (or anybody else) is free to take my idea and/or implementation and do whatever they want with it. Just let me know, if you do, I’d definitely want to follow any further developments)))
2 Likes
I absolutely love your proposal. I once created something like Abstract because of serious problems with unnecessary metaclasses.
I’d like to follow this too.