[issue15653] PEP 3121, 384 refactoring applied to hashopenssl module

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 std

[issue15653] PEP 3121, 384 refactoring applied to hashopenssl module

Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue15653] PEP 3121, 384 refactoring applied to hashopenssl module

Changes by Greg Stein : -- nosy: -gstein ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue15653] PEP 3121, 384 refactoring applied to hashopenssl module

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 sub

[issue15653] PEP 3121, 384 refactoring applied to hashopenssl module

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 quirk

[issue15653] PEP 3121, 384 refactoring applied to hashopenssl module

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 stati

[issue15653] PEP 3121, 384 refactoring applied to hashopenssl module

Changes by Andrew Svetlov : -- nosy: +asvetlov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue15653] PEP 3121, 384 refactoring applied to hashopenssl module

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

[issue15653] PEP 3121, 384 refactoring applied to hashopenssl module

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

[issue15653] PEP 3121, 384 refactoring applied to hashopenssl module

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 tp

[issue15653] PEP 3121, 384 refactoring applied to hashopenssl module

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 c

[issue15653] PEP 3121, 384 refactoring applied to hashopenssl module

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 > typ

[issue15653] PEP 3121, 384 refactoring applied to hashopenssl module

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

[issue15653] PEP 3121, 384 refactoring applied to hashopenssl module

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). --

[issue15653] PEP 3121, 384 refactoring applied to hashopenssl module

Changes by Antoine Pitrou : -- stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue15653] PEP 3121, 384 refactoring applied to hashopenssl module

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 *)

[issue15653] PEP 3121, 384 refactoring applied to hashopenssl module

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 severity