On 4/11/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
[ Bold out-of-the-box thinking on modules by Martin ]
I wonder if standardization of the struct layout of 'struct state', and the naming scheme of 'struct state', 'module_slot' and 'STATE' would be desireable. The state and module_slot structs would be c-file-static, so naming conflicts shouldn't exist, and it would improve readability the way Py_VISIT does (IMHO.) In fact, maybe the struct state should just be the module object, as a C-subclass of the module type? It means a bit more work, like defining a module struct and a list of members Python classes get direct access to, but it does close the gap between modules and normal objects a bit. (At least from C; Python code still has to replace modules by lookalikes in sys.modules.)
In fact... perhaps module functions should then get the module object as the first argument (currently unused but always defined)? 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.)
I think, for Py3K, we should bite the bullet and not check init<module>. Extension writers will have to update their init-functions anyway, because PyImport_InitModule* all changes (I hope!) While we're at it, should generate the init<module> name (and maybe prototype) by macro instead of relying on the user to get the naming right? It'd allow easier changing of the naming and such in the future, but I don't know if that outweighs the discomfort of hiding function prototypes. Probably not.
[ Bold out-of-the-box thinking on modules by Martin ]
#define STATE PyModule_STATE(module_slot, struct state)
I wonder if standardization of the struct layout of 'struct state', and the naming scheme of 'struct state', 'module_slot' and 'STATE' would be desireable. The state and module_slot structs would be c-file-static, so naming conflicts shouldn't exist, and it would improve readability the way Py_VISIT does (IMHO.) In fact, maybe the struct state should just be the module object, as a C-subclass of the module type? It means a bit more work, like defining a module struct and a list of members Python classes get direct access to, but it does close the gap between modules and normal objects a bit. (At least from C; Python code still has to replace modules by lookalikes in sys.modules.)
In fact... perhaps module functions should then get the module object as the first argument (currently unused but always defined)? 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.)
It would be possible to support the existing init<module>
functions if that is desirable; in that case, nothing
would change.
I think, for Py3K, we should bite the bullet and not check init<module>. Extension writers will have to update their init-functions anyway, because PyImport_InitModule* all changes (I hope!) While we're at it, should generate the init<module> name (and maybe prototype) by macro instead of relying on the user to get the naming right? It'd allow easier changing of the naming and such in the future, but I don't know if that outweighs the discomfort of hiding function prototypes. Probably not.
--
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
