<br><br><div class="gmail_quote">On Sat, Apr 14, 2012 at 18:41, Christian Heimes <span dir="ltr"><<a href="mailto:lists@cheimes.de">lists@cheimes.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am 15.04.2012 00:32, schrieb Guido van Rossum:<br>
<div class="im">> 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?<br>
<br>
</div>pkg_resources has a similar API [1] that supports dotted names.<br>
pkg_resources also does some caching for files that aren't stored on a<br>
local file system (database, ZIP file, you name it). It should be<br>
trivial to support both dotted names and module instances.<br>
<br></blockquote><div><br></div><div>But that begs the question of whether this API should conflate module hierarchies with file directories. Are we trying to support reading files from within packages w/o caring about storage details but still fundamentally working with files, or are we trying to abstract away the concept of files and deal more with stored bytes inside packages? For the former you would essentially want the root package and then simply specify some file path. But for the latter you would want the module or package that is next to or containing the data and grab it from there.</div>
<div><br></div><div>And I just realized that we would have to be quite clear that for namespace packages it is what is in __file__ that people care about, else people might expect some search to be performed on their behalf. Namespace packages also dictate that you would want the module closest to the data in the hierarchy to make sure you went down the right directory (e.g. if you had the namespace package monty with modules spam and bacon but from different directories, you really want to make sure you grab the right module). I would argue that you can only go next to/within modules/packages; going up would just cause confusion on where you were grabbing from and going down could be done but makes things a little messier.</div>
<div><br></div><div>-Brett</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Christian<br>
<br>
[1]<br>
<a href="http://packages.python.org/distribute/pkg_resources.html#resourcemanager-api" target="_blank">http://packages.python.org/distribute/pkg_resources.html#resourcemanager-api</a><br>
<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" target="_blank">http://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/brett%40python.org" target="_blank">http://mail.python.org/mailman/options/python-dev/brett%40python.org</a><br>
</blockquote></div><br>