[Import-SIG] PEP 489: Multi-phase extension module initialization; version 5

[Nick Coghlan]

On 19 May 2015 01:32, "Petr Viktorin" <encukou at gmail.com> wrote:
>
> On Mon, May 18, 2015 at 5:15 PM, Antoine Pitrou <solipsis at pitrou.net>
wrote:
> > On Mon, 18 May 2015 17:07:20 +0200
> > Petr Viktorin <encukou at gmail.com> wrote:
> >> On Mon, May 18, 2015 at 4:51 PM, Antoine Pitrou <solipsis at pitrou.net>
wrote:
> >> >
> >> > Hi,
> >> >
> >> > On Mon, 18 May 2015 16:02:37 +0200
> >> > Petr Viktorin <encukou at gmail.com> 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.

I thought you talked me out of that somewhere along the line? My
recollection at this point is that I was originally wanting the use of the
Create slot to be compatible with runpy, but didn't actually have a
compelling reason for why we should accept that as a design constraint.

> > 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.

Right, I think there's still a problem worth solving there, but I don't
think this specific PEP needs to solve it directly.

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/import-sig/attachments/20150519/16f5cc89/attachment.html>