<br><br><div class="gmail_quote">On Sat, Apr 14, 2012 at 18:32, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Sat, Apr 14, 2012 at 2:15 PM, Eric Snow <<a href="mailto:ericsnowcurrently@gmail.com">ericsnowcurrently@gmail.com</a>> wrote:<br>
> On Sat, Apr 14, 2012 at 2:56 PM, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
>> An open issue in PEP 302 is whether to require __loader__ attributes on<br>
>> modules. The claimed worry is memory consumption, but considering importlib<br>
>> and zipimport are already doing this that seems like a red herring.<br>
>> Requiring it, though, opens the door to people relying on its existence and<br>
>> thus starting to do things like loading assets with<br>
>> ``__loader__.get_data(path_to_internal_package_file)`` which allows code to<br>
>> not care how modules are stored (e.g. zip file, sqlite database, etc.).<br>
>><br>
>> What I would like to do is update the PEP to state that loaders are expected<br>
>> to set __loader__. Now importlib will get updated to do that implicitly so<br>
>> external code can expect it post-import, but requiring loaders to set it<br>
>> would mean that code executed during import can rely on it as well.<br>
>><br>
>> As for __package__, PEP 366 states that modules should set it but it isn't<br>
>> referenced by PEP 302. What I want to do is add a reference and make it<br>
>> required like __loader__. Importlib already sets it implicitly post-import,<br>
>> but once again it would be nice to do this pre-import.<br>
>><br>
>> To help facilitate both new requirements, I would update the<br>
>> importlib.util.module_for_loader decorator to set both on a module that<br>
>> doesn't have them before passing the module down to the decorated method.<br>
>> That way people already using the decorator don't have to worry about<br>
>> anything and it is one less detail to have to worry about. I would also<br>
>> update the docs on importlib.util.set_package and importlib.util.set_loader<br>
>> to suggest people use importlib.util.module_for_loader and only use the<br>
>> other two decorators for backwards-compatibility.<br>
><br>
> +1<br>
<br>
</div></div>Funny, I was just thinking about having a simple standard API that<br>
will let you open files (and list directories) relative to a given<br>
module or package regardless of how the thing is loaded. If we<br>
guarantee that there's always a __loader__ that's a first step, though<br>
I think we may need to do a little more to get people who currently do<br>
things like open(os.path.join(os.path.basename(__file__),<br>
'some_file_name') to switch. I was thinking of having a stdlib<br>
function that you give a module/package object, a relative filename,<br>
and optionally a mode ('b' or 't') and returns a stream -- and sibling<br>
functions that return a string or bytes object (depending on what API<br>
the user is using either the stream or the data can be more useful).<br>
What would we call thos functions and where would the live?</blockquote><div><br></div><div>IOW go one level lower than get_data() and return the stream and then just have helper functions which I guess just exhaust the stream for you to return bytes or str? Or are you thinking that somehow providing a function that can get an explicit bytes or str object will be more optimized than doing something with the stream? Either way you will need new methods on loaders to make it work more efficiently since loaders only have get_data() which returns bytes and not a stream object. Plus there is currently no API for listing the contents of a directory.</div>
<div><br></div><div>As for what to call such functions, I really don't know since they are essentially abstract functions above the OS which work on whatever storage backend a module uses.</div><div><br></div><div>For where they should live, it depends if you are viewing this as more of a file abstraction or something that ties into modules. For the former it seems like shutil or something that dealt with higher order file manipulation. If it's the latter I would say importlib.util.</div>
</div>