Re: PEP 489: Multi-phase extension module initialization; version 5

On Mon, May 18, 2015 at 5:15 PM, Antoine Pitrou <[email protected]> wrote:
> On Mon, 18 May 2015 17:07:20 +0200
> Petr Viktorin <[email protected]> wrote:
>> On Mon, May 18, 2015 at 4:51 PM, Antoine Pitrou <[email protected]> wrote:
>> >
>> > Hi,
>> >
>> > On Mon, 18 May 2015 16:02:37 +0200
>> > Petr Viktorin <[email protected]> wrote:
>> >>
>> >> I've sent the latest update of PEP 489 to the editors. I am quite happy
>> >> with how it turned out, and I don't expect too many further changes.
>> >
>> > I'm surprised the PEP still mentions PyModule_GetState. Shouldn't it be
>> > discouraged in favour of custom module object fields?
>>
>> No, it's the other way around -- we want to discourage using custom
>> module subclasses; most modules should just customize the exec phase.
>
> Can you explain why? The module state mechanism has turned out to be
> cumbersome and inefficient, and is the main reason why PEP 3121
> conversions of many stdlib modules have been deferred or abandoned.

One reason against custom module subclasses is that it won't be easy
to support "python -m" for them (see
https://mail.python.org/pipermail/import-sig/2015-March/000923.html)
Nick, can you give some others? Preferring real module objects is
something I remember from our early discussions.

> A fast, easy way to access module "state" without defining global
> variables at the C level is required.

You can have a custom subclass, or you can use per-module state, or
put a capsule in the module dict.
This PEP doesn't add a fourth better way, but I don't think that's
really in its scope ("The goal is [...] bringing extension modules
closer to the way Python modules behave"). What it does do, with
slots, is provide a mechanism to add such a better way in the future,
relatively painlessly.