Re-enable recursive class attributes#995
Conversation
davidhewitt
left a comment
davidhewitt
left a comment
There was a problem hiding this comment.
Very comprehensive solution, looks great to me! Thanks!
| /// 3) if f() does not release the GIL and does not panic, it is guaranteed to be called | ||
| /// exactly once, even if multiple threads attempt to call `get_or_init` | ||
| /// 4) if f() can panic but still does not release the GIL, it may be called multiple times, | ||
| /// but it is guaranteed that f() will never be called concurrently |
| }); | ||
|
|
||
| if let Err(err) = result { | ||
| err.clone_ref(py).print(py); |
There was a problem hiding this comment.
We only have a &Result<(), PyErr>, and it seems that PyErr::print takes self as an argument, not &self. So I used clone_ref (we are in an unlikely error path anyway), but if there is a better way I can change that.
There was a problem hiding this comment.
Ah, I see, thanks. Then I think we need clone_ref.
|
@scalexm could you also please remove the CHANGELOG entry which I'd previously written about disabling class attributes (as that's now incorrect):
|
Use some kind of two-stage initialization as described in PyO3#975, by being very cautious about when to allow the GIL to be released.
|
Thank you for the update.
Are you going to push the change to this branch? |
|
You can merge it, we can do that other change in another PR as it’s not a bug fix but rather a technical improvement. |
3 participants
Builds on #994 (it's actually the call to
PyType_Modifythrough a shared reference which made me realize the problem!).Last thing to do will be to replace
value: GILOnceCell<*mut ffi::PyTypeObject>withUnsafeCell<ffi::PyTypeObject>+GILOnceCell<()>as suggested by @kngwyu.