Counting references to Py_None
Hello! I'm seeing that our code increases the reference counting to Py_None, and I find this a little strange: isn't Py_None eternal and will never die? What's the point of counting its references? Thanks! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ Twitter: @facundobatista
On Sun, Mar 20, 2016 at 01:43:27PM -0300, Facundo Batista wrote:
Hello!
I'm seeing that our code increases the reference counting to Py_None, and I find this a little strange: isn't Py_None eternal and will never die?
What's the point of counting its references?
Avoiding a branch on every single Py_DECREF / Py_INCREF?
Thanks!
-- . Facundo
Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ Twitter: @facundobatista _______________________________________________ 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/dw%2Bpython-dev%40hmmz.or...
[Facundo Batista
I'm seeing that our code increases the reference counting to Py_None, and I find this a little strange: isn't Py_None eternal and will never die?
Yes, but it's immortal in CPython because its reference count never falls to 0 (it's created with a reference count of 1 to begin with). That's the only thing that makes it immortal.
What's the point of counting its references?
Uniformity and simplicity: code using a PyObject* increments and decrements reference counts appropriately with no concern for what _kind_ of object is being pointed at. All objects (including None) are treated exactly the same way for refcount purposes.
On Sun, 20 Mar 2016 at 09:44 Facundo Batista
Hello!
I'm seeing that our code increases the reference counting to Py_None, and I find this a little strange: isn't Py_None eternal and will never die?
Semantically yes, but we have to technically make that happen. :)
What's the point of counting its references?
It's just another Python object, so if you return it then the code that receives it may very well decref it because it always DECREFs the object returned. And if we didn't keep its count accurately it would eventually hit zero and constantly have its dealloc function checked for. We could add a magical "never dies" value for the refcount, but that adds another `if` branch in all the code instead of simply treating Py_None like any other object and properly tracking its reference.
Hi,
On 20 March 2016 at 18:10, Brett Cannon
And if we didn't keep its count accurately it would eventually hit zero and constantly have its dealloc function checked for.
I think the idea is really consistency. If we wanted to avoid all "Py_INCREF(Py_None);", it would be possible: we could let the refcount of None decrement to zero, at which point its deallocator is called; but this deallocator can simply bumps the refcount to a large value again. The deallocator would end up being called very rarely. A bientôt, Armin.
Brett Cannon
And if we didn't keep its count accurately it would eventually hit zero and constantly have its dealloc function checked for.
[Armin Rigo] [> I think the idea is really consistency. If we wanted to avoid all
"Py_INCREF(Py_None);", it would be possible: we could let the refcount of None decrement to zero, at which point its deallocator is called; but this deallocator can simply bumps the refcount to a large value again. The deallocator would end up being called very rarely.
It could, but it does something else now ;-) I've seen this trigger, from C code that had no idea it was playing with None, but just had general refcounting errors. So this does serve a debugging purpose, although rarely: static void none_dealloc(PyObject* ignore) { /* This should never get called, but we also don't want to SEGV if * we accidentally decref None out of existence. */ Py_FatalError("deallocating None"); } (that's in object.c)
On Mon, Mar 21, 2016 at 5:56 PM, Tim Peters
I've seen this trigger, from C code that had no idea it was playing with None, but just had general refcounting errors. So this does serve a debugging purpose, although rarely
You probably have a better refcounting sense that I do, but I see this quite often when I hack C code and I find this behavior quite useful when debugging.
participants (6)
-
Alexander Belopolsky -
Armin Rigo -
Brett Cannon -
David Wilson -
Facundo Batista -
Tim Peters