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/archive%40mail-archive.com

Reply via email to