[Import-SIG] On singleton modules, heap types, and subinterpreters

[Eric Snow]

On Jul 29, 2015 12:05 PM, "Petr Viktorin" <encukou at gmail.com> wrote:
>
> On Wed, Jul 29, 2015 at 7:53 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> > An alternative, could the module intra-dependencies be bound where needed?
> > For example, with _csv could Error be added to reader.__dict__ (i.e. bound
> > to reader)?
>
> Putting a reference to the module on *classes* is not a problem.
> Getting a reference to the module from normal methods should also not
> be that hard.
>
> The hard part is special methods, like tp_iter, which only get "self"
> as an argument, at the C level. There's no information about which
> (super)class the method is defined in.

The slot methods would have to do `type(self).<"global">`, which is
what any other method would do.  So in the relevant _csv.reader
methods we would use the equivalent "type(self).Error" where needed.

Let me make sure I understand the problem before I say anything more.
:)  In Python each function has __globals__ and __closure__ that
provide externally scoped objects for use within the function.  In C
extension functions neither exists.  Is that right?  (Or is that sort
of what PyState_FindModule is supposed to facilitate?)

If so then that's similar to how, in Python, objects in class
definitions are not exposed to other objects in the same definition.
The following result in NameErrors:

    class Spam:
        class Ham:
            OKAY = True
        class Eggs:
            OKAY = Ham.OKAY

    class Counter:
        DEFAULT = 0
        def next(self):
            try: return self.count
            except AttributeError: DEFAULT

    Counter().next()

The current solution for both Python class definition scope and C
extension functions is basically the same then, right?  Since you
can't rely on a lookup mechanism you must explicitly bind the objects
to places where they can be accessed.  In the case of methods
(including type slots), the module-scoped ("global") objects would
have to be bound to the class (where the methods will have access to
them through self).  Sure, subclasses could override the class attrs,
but that shouldn't be a problem.

However, it sounds like you're suggesting that PyState_FindModule
should be fixed, replaced, or supplemented, assuming I've understood
correctly that it's part of the problem here.  I'd say it depends on
the actual impact of the lack of implicit Python-level scoping/lookup
in C extension functions/methods.

-eric