Re: On singleton modules, heap types, and subinterpreters
Eric Snow <[email protected]> Wed, 29 Jul 2015 12:57:21 -0600
| Newsgroups | gmane.comp.python.import |
|---|---|
| Message-ID | <CALFfu7D0yL-_Lmae-AJsEWJf=vK98F-JkVjOJTER_JE4_BUYHw@mail.gmail.com> |
On Jul 29, 2015 12:05 PM, "Petr Viktorin" <[email protected]> wrote: > > On Wed, Jul 29, 2015 at 7:53 PM, Eric Snow <[email protected]> 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