(original) (raw)

> It's my contention that this API is simply untenable under the Gilectomy

Yeah, I agree with your contention. The only circumstance PyWeakref\_GetObject would still be valid without a GIL is if you happened to know you had a reference elsewhere that was keeping it alive. But if you did, you probably wouldn't need to use the weakref. If you don't, then with GILectomy you have no thread-safe options.

Trivial bikeshedding: rather than change the existing API, wouldn't it be better to add a new API, and not support the old one in GILectomized CPython? Introducing memory leaks would be a little unfortunate, and it's hard to audit C code for correct use of refcounted pointers even \*before\* you change the ownership of returned pointers across versions.

w.r.t. the exact question:

> whose reference is it borrowing?

I think this is a red herring sort of question. "borrowed" only means "unowned". But anyway, we borrowed from the weakref. (Borrowing from somebody doesn't imply they own a reference -- we can borrow from a borrowed reference, for example, and this is common.)

The term "borrowed" is supposed to imply a sensible scope during which you're free to use the object, and weakrefs don't have that (except for what is granted by the GIL), so this does sound wacky. I bet it was for performance.

-- Devin