-
Notifications
You must be signed in to change notification settings - Fork 779
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
fix: make PyType::name consistent with __name__ and add PyType::module #4056
Conversation
I am not particularly keen on the additional complexity and would be prefer to limit to fixing inconsistencies between builds with and without |
As well as efficiency, it looks like PEP 737 makes it clear that exposing However I agree with the complexity concern here. Given that PEP 737 adds a new That way we have a set of functions which match Python well, and should be relatively simple to implement:
What do you both think of this? |
I prefer to be aligned with Python dunder attributes, I find this more intuitive. |
@adamreichold as you already raised a complexity concern, what do you think of what I suggest above? |
Ping @adamreichold (and other maintainers), what do you think of this? I still believe we errored in the design for 0.21 and this correction is worthwhile despite the churn. |
Yes, I agree that PEP compliance is preferable and outweighs the perceived performance benefits of borrowing |
No problem, I am happy to also try to implement (or maybe @wyfo is willing to rework this PR). Mostly just wanted to make sure the design blocker was removed! |
Superseded by #4196. I will close this one. |
fixes #4055