[Python-Dev] A Subtle Bug in Class Initializations
steve.dower at python.org
Thu Aug 9 13:21:47 EDT 2018
On 09Aug2018 0818, Erik Bray wrote:
> On Mon, Aug 6, 2018 at 8:11 PM Eddie Elizondo <eelizondo at fb.com> wrote:
>> 3) Special case the initialization of PyType_Type and PyBaseObject_Type within PyType_Ready to now make all calls to PyVarObject_HEAD_INIT use NULL. To enable this a small change within PyType_Ready is needed to initialize PyType_Type PyBaseObject:
> Coincidentally, I just wrote a long-ish blog post explaining in
> technical details why PyVarObject_HEAD_INIT(&PyType_Type) pretty much
> cannot work, at least for extension modules (it is not a problem in
> the core library), on Windows (my post was focused on Cygwin but it is
> a problem for Windows in general):
> The TL;DR is that it's not possible on Windows to initialize a struct
> with a pointer to some other data that's found in another DLL (i.e.
> &PyType_Type), unless it happens to be a function, as a special case.
> But &PyType_Type obviously is not, so thinks break.
Great write-up! I think logically it should make sense that you cannot
initialize a static value from a dynamically-linked library, but you've
conclusively shown why that's the case. I'm not clear whether it's also
the case on other OS's, but I don't see why it wouldn't be (unless they
compile magic load-time resolution).
> So I'm +1 for requiring passing NULL to PyVarObject_HEAD_INIT,
> requiring PyType_Ready with an explicit base type argument, and maybe
> (eventually) making PyVarObject_HEAD_INIT argumentless.
Since PyVarObject_HEAD_INIT currently requires PyType_Ready() in
extension modules already, then don't we just need to fix the built-in
As far as the "eventually" case, I'd hope that eventually extension
modules are all using PyType_FromSpec() :)
More information about the Python-Dev