[Python-3000] Draft PEP: Module Initialization and finalization
thomas at python.org
Wed Apr 12 11:31:38 CEST 2006
On 4/12/06, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> Thomas Wouters wrote:
> > In fact... perhaps module functions should then get the module object as
> > the first argument (currently unused but always defined)?
> That wouldn't work: the first argument currently *is* used, atleast
> if you pass a non-NULL value for self to Py_InitModule4. Of course,
> we could drop that in Py3k, and declare that you always get the module
Right, forgot about that. I've never seen anyone use it, though.
However, that still wouldn't fully work, since you might need access
> to module objects in a method of a type you implemented, where self
> is the object. So I think you need some way to go through the current
Well, I said that, it just wasn't part of what you quoted: "Then we just
need conceptually-new magic to fetch the right module object when dealing
with methods of types defined in the module (which, I believe, should be
pretty rare.)" Your point about importing a module the second time in the
same interpreter (by removing it from sys.modules, or by using reload())
also requires this. We'd need a convenient way to do that (I'm not sure I
consider casting the result of PyObject_GetAttrString(self, "__module__")
'convenient'), and we'd need to educate all extension writers (including the
ones working on CPython proper) when to use the module object instead of
direct C variable access. Using a C global instead of a module object
attribute would lead to subtle bugs in subtle cases, like when multiple
interpreters are involved. Maybe, when we're done, we should be running
regrtest in multiple interpreters concurrently, too. ;P
I do think it's worth it, though.
Thomas Wouters <thomas at python.org>
Hi! I'm a .signature virus! copy me into your .signature file to help me
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-3000