+1 for initial proposition. On Tue, Apr 17, 2012 at 6:59 PM, Brett Cannon <br...@python.org> wrote: > Anyone other than Eric have something to say on this proposal? Obviously the > discussion went tangential before I saw a clear consensus that what I was > proposing was fine with people. > > > On Sat, Apr 14, 2012 at 16:56, Brett Cannon <br...@python.org> wrote: >> >> An open issue in PEP 302 is whether to require __loader__ attributes on >> modules. The claimed worry is memory consumption, but considering importlib >> and zipimport are already doing this that seems like a red herring. >> Requiring it, though, opens the door to people relying on its existence and >> thus starting to do things like loading assets with >> ``__loader__.get_data(path_to_internal_package_file)`` which allows code to >> not care how modules are stored (e.g. zip file, sqlite database, etc.). >> >> What I would like to do is update the PEP to state that loaders are >> expected to set __loader__. Now importlib will get updated to do that >> implicitly so external code can expect it post-import, but requiring loaders >> to set it would mean that code executed during import can rely on it as >> well. >> >> As for __package__, PEP 366 states that modules should set it but it isn't >> referenced by PEP 302. What I want to do is add a reference and make it >> required like __loader__. Importlib already sets it implicitly post-import, >> but once again it would be nice to do this pre-import. >> >> To help facilitate both new requirements, I would update the >> importlib.util.module_for_loader decorator to set both on a module that >> doesn't have them before passing the module down to the decorated method. >> That way people already using the decorator don't have to worry about >> anything and it is one less detail to have to worry about. I would also >> update the docs on importlib.util.set_package and importlib.util.set_loader >> to suggest people use importlib.util.module_for_loader and only use the >> other two decorators for backwards-compatibility. > > > > _______________________________________________ > 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/andrew.svetlov%40gmail.com >
-- Thanks, Andrew Svetlov _______________________________________________ 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