[issue41133] Insufficient description of cyclic garbage collector for C API

Pablo Galindo Salgado added the comment: I agree with what Tim said. We also cannot foresee every possible bug of someone misusing the C API, and the garbage collector interacts with many systems of the VM, and having gigantic documentation has shown to be always detrimental. > I think it

[issue41133] Insufficient description of cyclic garbage collector for C API

Change by Joannah Nanjekye : -- nosy: +nanjekyejoannah, pablogsal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue41133] Insufficient description of cyclic garbage collector for C API

Daniel Barkalow added the comment: I think it would be helpful to have something as troubleshooting information on the garbage collector. If you've got a bug in your C module, it's obvious that you shouldn't be doing something egregiously wrong, but it's not obvious what you might have done

[issue41133] Insufficient description of cyclic garbage collector for C API

Tim Peters added the comment: I don't see real value in the docs noting that Bad Things can happen if code lies about true refcounts. If a container points to an object, _of course_ the container should own that reference. Cheating on that isn't intended to be supported in any way, so there'

[issue41133] Insufficient description of cyclic garbage collector for C API

New submission from Daniel Barkalow : Nothing in the documentation gives you enough information to find what you're doing wrong if you have the following bug for an object tracked by the GC: (a) you store a borrowed reference to an object whose lifetime is always longer that the buggy object