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

bpo-38823: Add a private _PyModule_StealObject API. #17298

Closed

Conversation

brandtbucher
Copy link
Member

@brandtbucher brandtbucher commented Nov 20, 2019

This will be helpful for the refactoring I'm doing in bpo-38823, and keep the diffs small. It's also just nice to have around, since it (not PyModule_AddObject) is actually what we want in most cases.

https://bugs.python.org/issue38823

@brandtbucher brandtbucher added the type-feature A feature request or enhancement label Nov 20, 2019
@brandtbucher
Copy link
Member Author

It would be nice to have this backported to 3.8 and 3.7, so that fixes using it may be backported as well. I'm not sure if that's appropriate though, so maybe somebody else can make the call.

@brandtbucher
Copy link
Member Author

brandtbucher commented Nov 21, 2019

@vstinner Do you mind taking a peek at this when you have a free minute?

@ncoghlan
Copy link
Contributor

ncoghlan commented Dec 5, 2019

Pre-emptively backporting wouldn't be OK, but it could be considered if there was a bug fix backport that depended on it.

@ncoghlan
Copy link
Contributor

ncoghlan commented Dec 5, 2019

Do you still need this, though? It looks like most of the cleanup PRs have already been merged.

Copy link
Member

@vstinner vstinner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really dislike C functions "stealing" references. I prefer functions doing Py_INCREF() themselves. For example, PyList_Append(list, item) does Py_INCREF(item) as expected.

@bedevere-bot
Copy link

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@brandtbucher brandtbucher requested review from rhettinger and a team as code owners January 28, 2020 01:46
@brandtbucher
Copy link
Member Author

@ncoghlan I've edited the PR to include a few of the many modules that still need to be refactored. The linked PRs on the issue were only the ones that would not benefit from this addition. I estimate that there are several dozen more. Hopefully it's clear that this function would make the bugfixes much more straightforward, enough to backport the function itself for their use.

@vstinner I too prefer it when functions don't steal references. If I were designing a brand new API, I would definitely not do it this way. The issue is that there are dozens of modules with complicated (broken) initialization code that relies on the stealing behavior of PyModule_AddObject (but doesn't properly handle errors). See _ctypes for a good example of code that is much easier to fix if we keep the stealing behvior.

If you still disagree, I can change it to never steal. It's just my impression from looking at the mountain of complex, broken code ahead of me that this is probably the easier route to take, especially since this API is just meant to be a "band-aid" for another broken API.

@brandtbucher
Copy link
Member Author

I didn't expect the Spanish Inquisition!

@bedevere-bot
Copy link

Nobody expects the Spanish Inquisition!

@vstinner: please review the changes made to this pull request.

@shihai1991
Copy link
Member

Looks like this PR can be closed after victor merged this PR: #23122 @brandtbucher

@vstinner
Copy link
Member

@brandtbucher:

@vstinner I too prefer it when functions don't steal references. If I were designing a brand new API, I would definitely not do it this way. The issue is that there are dozens of modules with complicated (broken) initialization code that relies on the stealing behavior of PyModule_AddObject (but doesn't properly handle errors). See _ctypes for a good example of code that is much easier to fix if we keep the stealing behvior.

If you still disagree, I can change it to never steal. It's just my impression from looking at the mountain of complex, broken code ahead of me that this is probably the easier route to take, especially since this API is just meant to be a "band-aid" for another broken API.

I added PyModule_AddObjectRef() which uses strong references, rather than only stealing a reference on success.

I also enhanced the documentation to show concrete examples:
https://docs.python.org/dev/c-api/module.html#c.PyModule_AddObjectRef

I modified a few extension to use PyModule_AddObjectRef(). Sometimes, PyModule_AddObject() is more appropriate. Sometimes, PyModule_AddObjectRef() is more appropriate. Both functions are relevant, and I don't see a clear winner.

I agree than fixing existing code is painful, but I hope that new code using mostly PyModule_AddObjectRef() would be simpler to review. I'm not sure that it's simpler to write new code using PyModule_AddObjectRef(), since you might need more Py_DECREF() calls.

My intent is to have more "regular" code about reference counting. See also: https://bugs.python.org/issue42294

Since you wrote that this API is a band aid on a broken API, I consider that you are fine with rejecting it and move on to the new PyModule_AddObjectRef().

Anyway, thanks for you attempt to make the C API less broken :-)

@vstinner vstinner closed this Nov 12, 2020
@brandtbucher brandtbucher deleted the _PyModule_StealObject branch July 21, 2022 20:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting change review type-feature A feature request or enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants