Should it maybe be &'static Py<PyType> ? Just cause then there's less indirection. Though that's probably another round of bulk editing

Maybe PyStatic<T>? then PyStrInterned can be simply alias of PyStatic<PyStr>

IMO if PyStatic is just a wrapper around &'static Py<T> I don't think that'd be necessary

PyStatic will be a wrapper of Py<T> but always intended to be used like &'static PyStatic<T>. It is not very different but overriding eq and Debug

https://github.com/RustPython/RustPython/blob/main/vm/src/intern.rs#L170-L197

Even if we are going to use PyStatic, finishing #3700 first and working on top of it will be better.

@coolreader18 changing to &Py<PyType> is not easy for now. This is related to PyPayload::class() -> &PyTypeRef and casting &'static Py<PyType> to PyTypeRef without a wrapper type like PyStatic will be messy.

idk why but performance drops a lot by this change

casting &'static Py<PyType> to PyTypeRef without a wrapper type like PyStatic will be messy.

Why? And I don't think that cast is sound, unless it does a check like is_leaked() and return Option<PyRef>

let pyref = ...;
let static_ref: &'static _ = PyStatic::leak(pyref);
let uaf = static_ref.cast_to_pyref();
let uaf2 = static_ref.cast_to_pyref();

And like, can't the current fn class() -> &PyTypeRef just turn to fn class() -> &'static Py<PyType> by deref-coercing it? just let x: &'static Py<PyType> = /* &'static PyTypeRef */

I was misunderstanding something. When we have &Py<T>, it means it is always referring a valid PyRef<T>, right? So &Py<T> can have to_owned as it is. PyStatic is useless and it is just same to Py. Maybe this is what you meant.

What will be the problem of the example code? It doesn't seem any uaf happen there. If PyRef<T> is &Py<T>, getting &PyRef<T> is free by &&Py<T>

I didn't get which function do you want to refer by fn class() -> &PyTypeRef. more hint?