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

PyList: remove get_parked_item, use macros for speed on !abi3 #1664

Merged
merged 1 commit into from
Jun 6, 2021

Conversation

birkenfeld
Copy link
Member

I assume that the get_parked_item API is a remnant from long ago? I don't see any other reference to "parked" in the whole codebase, and for users this is just confusing.

BTW, why are the PyListObject struct and the fast "macros" defined in ffi::cpython::listobject, but in ffi::tupleobject for PyTuple?

@davidhewitt
Copy link
Member

Fully agree get_parked_item should go; do you think we should give it one release version deprecation cycle just in case anyone is using it?

BTW, why are the PyListObject struct and the fast "macros" defined in ffi::cpython::listobject, but in ffi::tupleobject for PyTuple?

I think that's just because the "ffi cleanup" #1289 hasn't made it to tupleobject yet (it's mostly been done alphabetically).

Copy link
Member

@davidhewitt davidhewitt left a comment

Choose a reason for hiding this comment

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

Regarding the macro changes: these make about 30% speedup to list get_item and iteration for me, which is awesome 🚀

@birkenfeld
Copy link
Member Author

At least I'm not seeing any uses searching on GitHub. I think this is fine without deprecation cycle, considering the various other changes that might have to be made when updating.

@davidhewitt
Copy link
Member

👍 I'm persuaded! Thanks for making all these nice optimizations 🚀

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.

None yet

2 participants