On 4/12/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Right, forgot about that. I've never seen anyone use it, though.
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 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
object.
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
interpreter.
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 <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
_______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
