Remove static mut from PyTypeInfo implementation

[davidhewitt]

Fixes #699 .

I looked at using lazy_static! and a couple other options, in the end I went for once_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.)

[programmerjake]

the PyTypeInfo trait should be unsafe, because otherwise a user can cause UB by mis-implementing it.

[kngwyu]

I modified the signature of PyTypeInfo::type_object() to return *mut instead of &mut.

👍 for this change.

So... I think this PR is good but the problem is our pair of PyTypeInfo::type_object and PyTypeObject has really complex semantics(I don't remember correctly... but maybe to avoid specialization?).

I'm sorry but I'm going to merge this PR after understanding the problem clearer.

[davidhewitt]

No rush. 👍

I spent some time thinking about PyTypeObject this morning. I experimented with merging PyTypeInfo and PyTypeObject, but it leads to refactorings across the codebase. Probably too big to land in a single PR. I'll share notes about it sometime.

[davidhewitt]

I had some ideas to take this a little further:

• Now type_object() always returns an initialized PyTypeObject.
• type_object() now returns NonNull instead of *mut.
• Removed PyTypeObject::init_type() - it's no longer needed.
• Removed initialize_type<T>() - it's no longer possible to initialize the type object manually other than by calling type_object().
• PyTypeInfo is now unsafe trait
• Also removed use of static mut in all the exceptions.rs macros.

[kngwyu]

Sorry for the delay with the review..., but now I'm considering fn type_object() -> Pin<&'static ffi::PyTypeObject for this purpose and experimenting it.

[davidhewitt]

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.

[kngwyu]

I tried to remove Box::new in create_type_object but this attempt just told me that ffi::PyType_Ready requires type object has a static address 🙄
So now I think the currently implementation is sufficiently good, except some minor things.

I also tried Pin<&'static ffi::PyTypeObject>, but finally I didn't like it since it requires too many pointer conversion.

[kngwyu]

force-push is my failure... don't mind it.

[kngwyu]

Thank you!