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): > 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4