STINNER Victor added the comment:
commit 46f59ebd01e22cc6a56fd0691217318c1d801a49
Author: Christian Heimes
Date: Wed Nov 18 16:12:13 2020 +0100
bpo-1635741: Port _hashlib to multiphase initialization (GH-23358)
Signed-off-by: Christian Heimes
See bpo-4 "Convert a few
Changes by Robin Schreiber robin.schrei...@me.com:
--
keywords: +pep3121 -patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15653
___
___
Antoine Pitrou added the comment:
So I'd propose that it is actually the leaf subtype which decrefs
ob_type. The check whether you are the leaf type is then done by
checking whether tp_dealloc is the one you are in right now.
By leaf, you mean the derived subtype? That sounds a bit quirky
Martin v. Löwis added the comment:
By leaf, you mean the derived subtype? That sounds a bit quirky (you
need the aforementioned if), how about the base heap type instead?
I think this fails (currently) because a subtype defined in Python using
a class statement will automatically get
Changes by Greg Stein gst...@gmail.com:
--
nosy: -gstein
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15653
___
___
Python-bugs-list mailing
Changes by Andrew Svetlov andrew.svet...@gmail.com:
--
nosy: +asvetlov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15653
___
___
Martin v. Löwis added the comment:
Antoine: Py_DECREF calls tp_dealloc directly, so the type needs to be DECREFed
in the course of tp_dealloc. I don't think there is any alternative to that.
One may wonder why regular extension types don't do that: this is because of a
hack that excludes
New submission from Robin Schreiber:
Changes proposed in PEP3121 and PEP384 have now been applied to the hashopenssl
module!
--
components: Extension Modules
files: _hashopenssl_pep3121-384_v0.patch
keywords: patch
messages: 168220
nosy: Robin.Schreiber, gstein
priority: normal
Antoine Pitrou added the comment:
+m = PyState_FindModule(_hashlibmodule);
+if(!m){
+m = PyModule_Create(_hashlibmodule);
+if (m == NULL)
+return NULL;
+} else {
+Py_INCREF(m);
+return m;
+}
Why is this dance needed?
+if((void
Changes by Antoine Pitrou pit...@free.fr:
--
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15653
___
___
Python-bugs-list
Antoine Pitrou added the comment:
Something else:
+#define _hashlibstate(o) ((_hashlibstate *)PyModule_GetState(o))
It is really bad style to #define a symbol that shadows another symbol.
Since it's a #define, I would expect to be named something like STATE(o).
--
Robin Schreiber added the comment:
Regarding the macro definition, I would be fine with changing it to
_hashlib_state.
The dance you have found inside the Init, makes shure that the very same module
is returned if Init is called twice or multiple times, before the Module is
unloaded. A month
Antoine Pitrou added the comment:
The last code snipped verifies, that we only dereference the type if
the dealloc function is not being called from inside the
subtype_dealloc function. This is necessary because the
subtype_dealloc function itself contains a decref of the respective
type
Robin Schreiber added the comment:
Well, as I have changed the static type to a HeapType (as I am now using the
stable ABI from PEP 384 for this type), we have to start perfoming proper
reference counting with this object. This includes increfing the type in case a
new object of that type is
Antoine Pitrou added the comment:
Le mardi 14 août 2012 à 19:55 +, Robin Schreiber a écrit :
As of now, I do not know of HeapTypes being excluded from refcounting.
No, but see http://bugs.python.org/issue15142
It's not obvious to me that the type should be explicitly decref'ed from the
Robin Schreiber added the comment:
As subtype_dealloc decref'ed the HeapType I thought the dealloc method was the
most appropriate place to decrement the refcount of the type.
However you still agree that these types need to be recounted properly, don't
you? In that case, where would you place
Antoine Pitrou added the comment:
Le mardi 14 août 2012 à 20:16 +, Robin Schreiber a écrit :
However you still agree that these types need to be recounted
properly, don't you?
Yes, of course.
In that case, where would you place the decref of the type?
That's a good question. Perhaps
17 matches
Mail list logo
