Re: [Python-Dev] C API changes
Hi Stefan, On Sat, 24 Nov 2018 at 22:17, Stefan Behnel wrote: > Couldn't this also be achieved via reference counting? Count only in C > space, and delete the "open object" when the refcount goes to 0? The point is to remove the need to return the same handle to C code if the object is the same one. This saves one of the largest costs of the C API emulation, which is looking up the object in a big dictionary to know if there is already a ``PyObject *`` that corresponds to it or not---for *all* objects that go from Python to C. Once we do that, then there is no need for a refcount any more. Yes, you could add your custom refcount code in C, but in practice it is rarely done. For example, with POSIX file descriptors, when you would need to "incref" a file descriptor, you instead use dup(). This gives you a different file descriptor which can be closed independently of the original one, but they both refer to the same file. A bientôt, Armin. ___ 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
Re: [Python-Dev] C API changes
Armin Rigo schrieb am 23.11.18 um 14:15: > In PyPy we'd have a global table of > "open objects", and a handle would be an index in that table; closing > a handle means writing NULL into that table entry. No emulated > reference counting needed: we simply use the existing GC to keep alive > objects that are referenced from one or more table entries. The cost > is limited to a single indirection. Couldn't this also be achieved via reference counting? Count only in C space, and delete the "open object" when the refcount goes to 0? Stefan ___ 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
[Python-Dev] Usage of tafile.copyfileobj
Hi, I’m working on the tarfile module to add support for file objects whose size is not know beforehand (https://bugs.python.org/issue35227). In doing so, I need to adapt `tarfile.copyfileobj` to return the length of the file after it has been copied. Calling this function with `length=None` currently leads to data being copied but without adding the necessary padding. This seems weird to me, I do not understand why this would be needed and this behaviour is currently not used. This function is not documented in Python documentation so nobody is probably using it. Can I safely change `tarfile.copyfileobj` to make it write the padding when `length=None`? Thanks, Rémi ___ 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
Re: [Python-Dev] C API changes
On Fri, 23 Nov 2018 at 23:24, Armin Rigo wrote (regarding opaque "handles" in the C API): > The C API would change a lot, so it's not reasonable to do that in the > CPython repo. But it could be a third-party project, attempting to > define an API like this and implement it well on top of both CPython > and PyPy. IMHO this might be a better idea than just changing the API > of functions defined long ago to make them more regular (e.g. stop > returning borrowed references); by now this would mostly mean creating > more work for the PyPy team to track and adapt to the changes, with no > real benefits. And the nice thing about doing it as a shim is that it can be applied to *existing* versions of CPython, rather than having to wait for new ones. Node.js started switching over to doing things this way last year, and its a good way to go about it: https://medium.com/the-node-js-collection/n-api-next-generation-node-js-apis-for-native-modules-169af5235b06 While this would still be a difficult project to pursue, and would suffer from many of the same barriers to adoption as CPython's native stable ABI, it does offer a concrete benefit to 3rd party module authors: being able to create single wheel files that can be shared across multiple Python versions, rather than needing to be built separately for each one. Cheers, 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
