> On 28 Aug 2018, at 22:09, Eddie Elizondo wrote:
>
> Hi everyone,
>
> Sorry for the delay - I finally sent out a patch:
> https://bugs.python.org/issue34522.
As I mentioned on the tracker this patch is incorrect because it redefines
PyVarObject_HEAD_INIT in a way that changes the semantic
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
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 abou
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 elsewh
On Thu, Aug 9, 2018 at 7:21 PM Steve Dower wrote:
>
> On 09Aug2018 0818, Erik Bray wrote:
> > On Mon, Aug 6, 2018 at 8:11 PM Eddie Elizondo wrote:
> >> 3) Special case the initialization of PyType_Type and PyBaseObject_Type
> >> within PyType_Ready to now make all calls to PyVarObject_HEAD_INIT
On 09Aug2018 0818, Erik Bray wrote:
On Mon, Aug 6, 2018 at 8:11 PM Eddie Elizondo 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 ne
On Mon, Aug 6, 2018 at 8:11 PM Eddie Elizondo wrote:
>
> Background:
>
> Through the implementation of an alternate runtime I've been poking around
> some of the class initialization routines and I found out that there was a
> subtle bug with PyType_Ready and the header initializer PyVarObject_H
This would be a good thing to fix. The only hard part is dealing with
thirdparty extensions.
Note we also have been working around this problem by putting PyType_Ready
calls in various generic code paths of the interpreter when an uninitialized
type passes through.
On Mon, Aug 6, 2018, at 11:0
Background:
Through the implementation of an alternate runtime I've been poking around some
of the class initialization routines and I found out that there was a subtle
bug with PyType_Ready and the header initializer PyVarObject_HEAD_INIT.
Looking through the codebase, I couldn't really find an
