On 11 October 2016 at 08:49, Guido van Rossum <gu...@python.org> wrote: > On Mon, Oct 10, 2016 at 1:57 PM, Larry Hastings <la...@hastings.org> wrote: >> For now I'm going to leave the names as-is and just change the semantics >> everywhere. If this approach really works, and if we decide we want to >> merge it back into trunk--and those are both still big if's--we can revisit >> this decision. > > Changing something as subtle as this to an API sounds really bad even > in an experimental branch. But it's your branch and you can do what > you want (then again, why did you bring it up here? :-).
I'm guessing Larry was hoping someone else would see a possible solution that he'd missed. On that front, while I don't see an alternative to making borrowed references real references in a GIL-free Python, I do think we may need to keep the borrowed/new distinction for the sake of folks writing cross-version compatible code. To explain why, consider these scenarios: * CPython with a GIL: - new references MUST be decref'ed - borrowed references MUST NOT be decref'ed * CPython without a GIL: - new references MUST be decref'ed - borrowed references MUST be decref'ed Assuming that the GILectomy does end up needing to implicitly treat all borrowed references as new references, that suggests we're going to need APIs like "PyBorrowed_DECREF" to provide the "only decref when built without the GIL" semantics, and the rules for GIL-independent source code would become: - new references must be decref'ed using the normal APIs - borrowed references must be decref'ed using the PyBorrowed* APIs (with a no-op compatibility shim for older GIL-only CPython versions) Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com