Hi,
coming back to PEP 489 [1], the multi-phase extension module
initialization. We originally designed it as an "all or nothing" feature,
but as it turns out, the "all" part is so difficult to achieve that most
potential users end up with "nothing". So, my question is: could we split
it up so tha
On 08/10/18 11:21, Stefan Behnel wrote:
Hi,
coming back to PEP 489 [1], the multi-phase extension module
initialization. We originally designed it as an "all or nothing" feature,
but as it turns out, the "all" part is so difficult to achieve that most
potential users end up with "nothing". So, m
Petr Viktorin schrieb am 10.08.2018 um 11:51:
> On 08/10/18 11:21, Stefan Behnel wrote:
>> coming back to PEP 489 [1], the multi-phase extension module
>> initialization. We originally designed it as an "all or nothing" feature,
>> but as it turns out, the "all" part is so difficult to achieve that
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 08/10/18 12:21, Stefan Behnel wrote:
Petr Viktorin schrieb am 10.08.2018 um 11:51:
On 08/10/18 11:21, Stefan Behnel wrote:
coming back to PEP 489 [1], the multi-phase extension module
initialization. We originally designed it as an "all or nothing" feature,
but as it turns out, the "all" par
ACTIVITY SUMMARY (2018-08-03 - 2018-08-10)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open6756 ( -3)
closed 39367 (+44)
total 46123 (+41)
Open issues w
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
Hi,
On 31 July 2018 at 13:55, Antoine Pitrou wrote:
> It's just that I disagree that removing the C API will make CPython 2x
> faster.
>
> Actually, important modern optimizations for dynamic languages (such as
> inlining, type specialization, inline caches, object unboxing) don't
> seem to depen
