On 25 Aug 2013 05:19, "Benjamin Peterson" <[email protected]> wrote: > > 2013/8/24 Terry Reedy <[email protected]>: > > On 8/24/2013 8:51 AM, Stefan Behnel wrote: > >> > >> Antoine Pitrou, 24.08.2013 13:53: > >>> > >>> This would also imply extension module have to be subclasses of the > >>> built-in module type. They can't be arbitrary objects like Stefan > >>> proposed. I'm not sure what the latter enables, but it would probably > >>> make things more difficult internally. > >> > >> > >> My line of thought was more like: if Python code can stick anything into > >> sys.modules and the runtime doesn't care, why can't extension modules > >> stick > >> anything into sys.modules as well? > > > > > > Being able to stick anything in sys.modules in CPython is an implementation > > artifact rather than language feature. > > This is not really true. Many people use this feature to replace > modules as they are being imported with other things.
Right - arbitrary objects in sys.modules is definitely a supported feature (e.g. most lazy import mechanisms rely on that). However, such objects should really provide the module level attributes the import system expects for ducktyping purposes, which is why I suggest the import system should automatically take care of setting those. Cheers, Nick. > > -- > Regards, > Benjamin > _______________________________________________ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
_______________________________________________ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
