<p dir="ltr"><br>
On 25 Aug 2013 05:19, "Benjamin Peterson" <<a href="mailto:benjamin@python.org">benjamin@python.org</a>> wrote:<br>
><br>
> 2013/8/24 Terry Reedy <<a href="mailto:tjreedy@udel.edu">tjreedy@udel.edu</a>>:<br>
> > On 8/24/2013 8:51 AM, Stefan Behnel wrote:<br>
> >><br>
> >> Antoine Pitrou, 24.08.2013 13:53:<br>
> >>><br>
> >>> This would also imply extension module have to be subclasses of the<br>
> >>> built-in module type. They can't be arbitrary objects like Stefan<br>
> >>> proposed. I'm not sure what the latter enables, but it would probably<br>
> >>> make things more difficult internally.<br>
> >><br>
> >><br>
> >> My line of thought was more like: if Python code can stick anything into<br>
> >> sys.modules and the runtime doesn't care, why can't extension modules<br>
> >> stick<br>
> >> anything into sys.modules as well?<br>
> ><br>
> ><br>
> > Being able to stick anything in sys.modules in CPython is an implementation<br>
> > artifact rather than language feature.<br>
><br>
> This is not really true. Many people use this feature to replace<br>
> modules as they are being imported with other things.</p>
<p dir="ltr">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.</p>

<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> --<br>
> Regards,<br>
> Benjamin<br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/python-dev">http://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com">http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com</a><br>
</p>