On 25 Aug 2013 05:19, "Benjamin Peterson" <benja...@python.org> wrote: > > 2013/8/24 Terry Reedy <tjre...@udel.edu>: > > 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 > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
