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

gh-90763: Modernise xx template module initialisation #93078

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

erlend-aasland
Copy link
Contributor

@erlend-aasland erlend-aasland commented May 22, 2022

xxmodule:

  • remove incorrect decref of module object if module init fails
  • modernise API usage; use PyModule_AddType iso. PyModule_AddObject

xxlimited_35:

  • remove incorrect decref of module object if module init fails
  • check return of PyModule_AddObject
  • fix module name in type objects

Use C APIs such as PyModule_AddType instead of PyModule_AddObject.
Also remove incorrect module decrefs if module fails to initialise.
@erlend-aasland
Copy link
Contributor Author

@erlend-aasland erlend-aasland commented May 22, 2022

@corona10, would you mind reviewing this? It's been a while since I've done the module init ref count dances :)

I note that xxlimited_35 creates two objects from the same type spec. I'm not sure if there's a point in doing that.

@erlend-aasland erlend-aasland requested a review from encukou May 22, 2022
@erlend-aasland erlend-aasland linked an issue May 22, 2022 that may be closed by this pull request
Copy link
Member

@corona10 corona10 left a comment

Overall looks good to me with nit comment.

Modules/xxlimited_35.c Outdated Show resolved Hide resolved
Modules/xxlimited_35.c Outdated Show resolved Hide resolved
@erlend-aasland erlend-aasland requested a review from corona10 May 23, 2022
Copy link
Member

@corona10 corona10 left a comment

lgtm

@erlend-aasland
Copy link
Contributor Author

@erlend-aasland erlend-aasland commented May 23, 2022

Thanks, Dong-hee! I'll hold the merge a couple of days to give Petr (or Victor) a chance to review.

@encukou
Copy link
Member

@encukou encukou commented May 23, 2022

Looks good, thanks!
If it was me, instead of create_and_add_type I'd write out the two calls each time: it's a historical module so I'd keep changes to minimal bugfixes. It's OK to showcase how clunky the old API is :)
But that's a minor nit, feel free to merge as is.

@erlend-aasland
Copy link
Contributor Author

@erlend-aasland erlend-aasland commented May 23, 2022

Looks good, thanks!
If it was me, instead of create_and_add_type I'd write out the two calls each time: it's a historical module so I'd keep changes to minimal bugfixes. It's OK to showcase how clunky the old API is :)
But that's a minor nit, feel free to merge as is.

I had to ponder a little bit about this; I agree that it's worth it keeping the changes minimal for these modules :)

Modules/xxlimited_35.c Show resolved Hide resolved
Modules/xxlimited_35.c Show resolved Hide resolved
Modules/xxmodule.c Show resolved Hide resolved
Modules/xxmodule.c Show resolved Hide resolved
@vstinner
Copy link
Member

@vstinner vstinner commented May 23, 2022

The point of this module is to show that static types and global variables still work.

The file starts with:

Use this file as a template to start implementing a module that also declares object types.

IMO it should be a show case of the best practice to write a C extension in 2022. Otherwise, people will continue to copy/paste this old code and will propagate static types and other legacy code to their project :-(

@vstinner
Copy link
Member

@vstinner vstinner commented May 23, 2022

If you want to test that the old way to write a C extension, with static types and global variables, still work, IMO it should be another module than this "template".

@erlend-aasland
Copy link
Contributor Author

@erlend-aasland erlend-aasland commented May 23, 2022

If you want to test that the old way to write a C extension, with static types and global variables, still work, IMO it should be another module than this "template".

We could adjust the wording in the top of the file, and also rename it to something like xxlegacy.c. But I think this warrants a broader discussion :)

IMO it should be a show case of the best practice to write a C extension in 2022. Otherwise, people will continue to copy/paste this old code and will propagate static types and other legacy code to their project :-(

That's what the xxlimited.c module is :)

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

Successfully merging this pull request may close these issues.

5 participants