<p dir="ltr">If we make it e.g., __loader__.resources().read_bytes(path) then I may be more amenable to creating a importlib.resources module with the bastardized pkg_resources API. Going to have to think about it, though.</p>
<br><div class="gmail_quote"><div dir="ltr">On Tue, 24 Nov 2015, 16:25Â Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, 24 Nov 2015 at 14:13 Barry Warsaw <<a href="mailto:barry@python.org" target="_blank">barry@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Nov 24, 2015, at 08:21 PM, Brett Cannon wrote:<br>
<br>
>> Module API vs package API. Doesn't pkg_resources actually support<br>
>> something similar to both, with the module function providing a convenience<br>
>> API?<br>
><br>
>Yes, but that doesn't sway me. This isn't a "pkg_resources++" but a "make<br>
>reading data from a package make sense in a modern import world". IOW I'm<br>
>purposefully not using pkg_resources as a template but simply as a<br>
>motivating factor.<br>
<br>
You're not taking into account a migration path for existing users of<br>
pkg_resources. If you make it difficult to convert, then people are much less<br>
likely to do it for existing code, despite the ability to remove a dependency.<br></blockquote><div><br></div></div></div><p dir="ltr">It's one of those situations where it's balancing future code with migrating old code. I'm doing this to solve the problem of importlib lacking any standardized way to get at resources in a package, not to migrate pkg_resources users who want to eliminate that dependency (although that would be a perk).</p>
<div dir="ltr"><div class="gmail_quote"><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If my existing code already has<br>
<br>
  from pkg_resources import resource_string as resource_bytes<br>
<br>
all I'd need to do is change this one line to<br>
<br>
  from importlib.resource import read_bytes as resource_bytes<br>
<br>
and I'm done. If I need to support multiple versions of Python, I can even<br>
do:<br>
<br>
  try:<br>
    from importlib.resource import read_bytes as resource_bytes<br>
  except ImportError:<br>
    from pkg_resources import resource_string as resource_bytes<br>
<br>
Without this API, it's much more difficult for me to convert my existing code,<br>
either incrementally or whole-hog, because now I have to either add that<br>
convenience function myself (and import it everywhere) or rewrite all my call<br>
sites. Why bother?<br></blockquote><div><br></div></div></div><p dir="ltr">Nothing is stopping people from writing their own pkg_resources compatibility layer. Hell, I will promise to create shim_resources or something and put it on PyPI for those that want a really simple migration path. But the base API that goes into the stdlib and will need to be supported forever doesn't need to go the way of compatibility if its going to feel out of place in importlib (which the pkg_resources API will, especially if we put a method on loaders to get a resource loader).</p>
<div dir="ltr"><div class="gmail_quote"><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
>Unfortunately for you the poll liked the other approach and TOOWTDI. So<br>
>either convince me that resources.read_bytes(pkg, path) is better than<br>
>resources(pkg).read_bytes(path) or consider the bike shed painted. :)<br>
<br>
It's not better or worse, it's just different. As pkg_resources has shown, it<br>
doesn't have to be either-or.<br>
<br>
I never saw the poll since I don't pay attention to Google+.</blockquote><div><br></div></div></div><p dir="ltr">Which is why I also linked to it on Twitter. :) I actually tried to do it on twitter initially but guess whose poll support restricts option lengths so much you can't type a method call out. :p</p>
<p dir="ltr">Â </p>
<blockquote><p dir="ltr">Â How<br>
representative are those 59 votes of the current pkg_resource users and<br>
potential future users of this API? If I had seen the poll I would have<br>
complained that it didn't give me a chance to choose both APIs <wink>.</p>
<p dir="ltr">>I'm not convinced it's necessary to provide an equivalent open() yet;</p>
<p dir="ltr">Right, I'm not necessarily advocating for it, just describing what it would<br>
have to do if it were there. It's something I occasionally wish I had, but<br>
all the building blocks are there to invent it when needed.</p>
<p dir="ltr">>> I do have one use of resource_listdir() which is used to find importable<br>
>> plugin modules at runtime. It's handy.<br>
><br>
>I'm going to punt on this for as long as possible because it's asking for<br>
>trouble to get right. For example, if I do resources(pkg).listdir(), then I<br>
>will end up returning relative paths, but if you disassociate those paths<br>
>from pkg then you have lost proper context. You could return tuples of<br>
>(pkg, relative_path), but that just doesn't seem satisfactory either. I'm<br>
>just not convinced yet it is needed enough to support (at least initially).</p>
<p dir="ltr">It's a tougher API to recreate from the building blocks, so it would be nice<br>
not to have to reinvent the wheel everywhere, but it's also a much less common<br>
API. I'm not at all worried about the disassociation problem, since<br>
os.listdir() gives you relative paths anyway so it's a familiar behavior.</p>
</blockquote>
<p dir="ltr"></p>
<p dir="ltr">Yeah, I realize it's something you can't make from scratch, but I'm still going to avoid it while I can because as soon as this goes in then people are going to want a similar API for discovering modules in a package and would abuse this API if they don't get the other API.</p>
<p dir="ltr">-brett<br>
</p>
<blockquote><p dir="ltr"></p>
<p dir="ltr">Cheers,<br>
-Barry<br>
_______________________________________________<br>
Import-SIG mailing list<br>
<a href="mailto:Import-SIG@python.org" target="_blank">Import-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/import-sig" target="_blank">https</a><a href="https://mail.python.org/mailman/listinfo/import-sig" target="_blank">://</a><a href="https://mail.python.org/mailman/listinfo/import-sig" target="_blank">mail.python.org</a><a href="https://mail.python.org/mailman/listinfo/import-sig" target="_blank">/mailman/</a><a href="https://mail.python.org/mailman/listinfo/import-sig" target="_blank">listinfo</a><a href="https://mail.python.org/mailman/listinfo/import-sig" target="_blank">/</a><a href="https://mail.python.org/mailman/listinfo/import-sig" target="_blank">import-sig</a><br>
</p>
</blockquote>
<p dir="ltr"><br>
</p>
</blockquote></div>