-
Notifications
You must be signed in to change notification settings - Fork 782
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
Remove static mut from PyTypeInfo implementation #751
Conversation
the |
👍 for this change. So... I think this PR is good but the problem is our pair of I'm sorry but I'm going to merge this PR after understanding the problem clearer. |
No rush. 👍 I spent some time thinking about |
9e64270
to
579fbde
Compare
I had some ideas to take this a little further:
|
579fbde
to
7531b9f
Compare
Sorry for the delay with the review..., but now I'm considering |
Please do experiment with better designs! I'd rather we make these changes once and get them right than break stuff again and again :) Let me know if you come up with something you prefer and want me to change this PR. |
I tried to remove I also tried |
5d13505
to
7531b9f
Compare
force-push is my failure... don't mind it. |
Thank you! |
Fixes #699 .
I looked at using
lazy_static!
and a couple other options, in the end I went foronce_cell
.I modified the signature of
PyTypeInfo::type_object()
to return*mut
instead of&mut
. It's a minor thing but handing out&mut
in this way is definitely breaking Rust's aliasing rules.Also removed
unsafe
from the function because there's nothing unsafe about calling it - the user is responsible for using the returned*mut ffi::PyTypeInfo
pointer safely.Might need a changelog entry because the trait signature changed?
(As a note, I plan to follow up this PR with a second one which removes the need for
init_type()
. Let's start with this to keep the PR smaller and simpler.)