[Import-SIG] PEP 489: Multi-phase extension module initialization; version 5
ncoghlan at gmail.com
Mon May 18 17:55:19 CEST 2015
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>
> > 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>
> >> >
> >> > 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
> >> >> 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
> >> > 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Import-SIG