Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Defining types is messy #49

Open
encukou opened this issue Jun 12, 2023 · 3 comments
Open

Defining types is messy #49

encukou opened this issue Jun 12, 2023 · 3 comments

Comments

@encukou
Copy link
Contributor

encukou commented Jun 12, 2023

I had several false starts on this issue and always got too deep in describing the current implementation. So I'll post a half-baked list to get something down faster.

  • How are/should fields handled, esp. special ones like type, dict, and superclass ones:
    • What should tp_traverse visit?
    • What code is in charge of initializing them? Zeroing them before initialization? Clearing them?
  • Can an object outlive tp_clear?
  • Can I rely on tp_clear being called?
  • Which initialization/finalization APIs call a type's slots, and which ones bypass them?

etc.

@encukou encukou changed the title Defining types is a mess Defining types is messy Jun 12, 2023
@iritkatriel iritkatriel removed the v label Oct 23, 2023
@gvanrossum
Copy link

See for example python/cpython#111339

@encukou
Copy link
Contributor Author

encukou commented Oct 30, 2023

That one is about defining internal static types, which are quite special (shareable across subinterpreters, deep-freezeable). Defining those isn't (yet) part of the public API; extensions need to either use heap types or stick to a single interpreter.

@encukou
Copy link
Contributor Author

encukou commented Oct 30, 2023

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

No branches or pull requests

3 participants