On 10Aug2018 0354, Erik Bray wrote:
Thanks! I'm not sure what you mean by "on other OS's" though. Do you
mean other OS's that happen to use Windows-style PE/COFF binaries?
Because other than Windows I'm not sure what we care about there.
For ELF binaries, at least on Linux (and probably elsewhere) it the
runtime loader can perform more sophisticated relocations when loading
a binary into memory, including relocating pointers in the binary's
.data section. This allows it to initialize data in one executable
"A" with pointers to data in another library "B" *before* "A" is
considered fully loaded and executable.
So this problem never arises, at least on Linux.
That's exactly what I meant. I simply didn't know how/whether other
loaders handled this case :) I recognise it's nothing to do with the
binary format and everything to do with whether the loader knows what to
do or not.
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() :)
+1 :)
Is that just a +1 for PyType_FromSpec(), or are you agreeing that we
only need to fix the built-in types?
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
