<div class="im">On Sat, Apr 14, 2012 at 3:50 PM, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
> On Sat, Apr 14, 2012 at 18:32, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
</div><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>
> IOW go one level lower than get_data() and return the stream and then just<br>
> have helper functions which I guess just exhaust the stream for you to<br>
> return bytes or str? Or are you thinking that somehow providing a function<br>
> that can get an explicit bytes or str object will be more optimized than<br>
> doing something with the stream? Either way you will need new methods on<br>
> loaders to make it work more efficiently since loaders only have get_data()<br>
> which returns bytes and not a stream object. Plus there is currently no API<br>
> for listing the contents of a directory.<br>
<br>
</div>Well, if it's a real file, and you need a stream, that's efficient,<br>
and if you need the data, you can read it. But if it comes from a<br>
loader, and you need a stream, you'd have to wrap it in a StringIO<br>
instance. So having two APIs, one to get a stream, and one to get the<br>
data, allows the implementation to be more optimal -- it would be bad<br>
to wrap a StringIO instance around data only so you can read the data<br>
from the stream again...<br></blockquote><div><br></div><div>Right, so you would need to grow, which is fine and can be done in a backwards-compatible way using io.BytesIO and StringIO.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> As for what to call such functions, I really don't know since they are<br>
> essentially abstract functions above the OS which work on whatever storage<br>
> backend a module uses.<br>
><br>
> For where they should live, it depends if you are viewing this as more of a<br>
> file abstraction or something that ties into modules. For the former it<br>
> seems like shutil or something that dealt with higher order file<br>
> manipulation. If it's the latter I would say importlib.util.<br>
<br>
</div>if pkg_resources is in the stdlib that would be a fine place to put it.<br></blockquote><div><br></div><div>It's not.</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">