On 09Aug2018 0818, Erik Bray wrote:
On Mon, Aug 6, 2018 at 8:11 PM Eddie Elizondo <eelizo...@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):
http://iguananaut.net/blog/programming/windows-data-import.html
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
types?
As far as the "eventually" case, I'd hope that eventually extension
modules are all using PyType_FromSpec() :)
Cheers,
Steve
_______________________________________________
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
