Hi everyone,
Sorry for the delay - I finally sent out a patch:
https://bugs.python.org/issue34522.
Also, I'm +1 for modifying all extension modules to use PyType_FromSpec! I
might lend a hand to start moving them :)
- Eddie
On 8/13/18, 6:02 AM, "Erik Bray" wrote:
On Fri, Aug 10, 2018 at 6:49 PM Steve Dower wrote:
>
> 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.
Ah, that's not exactly what *I* meant, but you are also right: In
principle it shouldn't have anything to do with the binary formation.
You could stuff a more sophisticated dynamic relocation section into a
PE/COFF binary too but Windows wouldn't know what to do with it.
So you're right that this kind of problem could affect other OSes, I
just have no idea if it does.
> >>> 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?
Both! I think we should fix the built-in types, but it would be nice
if more extension modules used PyType_FromSpec, if nothing else
because I find it much more readable, and (I'm guessing) it's better
from the perspective of Victor's C-API work. But I admit I'm not
fully versed in the downsides (if there are any).
___
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
