Skip to content

Conversation

@zooba
Copy link
Owner

@zooba zooba commented Sep 16, 2025

This is very high-level, speculative, having a look at how an implementation of capi-workgroup/api-revolution#4 might look.

Don't take this too seriously (yet) ;)

@encukou
Copy link

encukou commented Sep 18, 2025

Thank you for implementing it!
My biggest worry/confusion is the same as in the revolution issue: how does this work with subclassing & inheritance, and how that would interact with third-patry extensions.

@zooba
Copy link
Owner Author

zooba commented Sep 18, 2025

Great questions, I haven't gone through enough real examples of that to be certain, but my gut feel would be:

  • when subclassing a native type with a pure-Python type, you can't override the tp_getinterface slot anyway
  • when subclassing with another native type, you have to know what your base class is, and so can look up its tp_getinterface and delegate explicitly
  • as with all other native slot implementations, they will only support subclassing if they are written to do so, and can reject subclassing by testing their own type
  • also, native type inheritance is a nightmare and you'll sleep better if you just don't do it :)

I'm not sure whether we should be adding guidance to recommend actively rejecting subclasses in tp_getinterface implementations, though it probably makes more sense to do that than to try and make every interface implementation go through slow paths in order to support it. Let fast be fast, and let the fallbacks handle subclasses.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants