[Import-SIG] Proposed design for importlib.resources()

[Barry Warsaw]

On Nov 25, 2015, at 12:28 AM, Brett Cannon wrote:

>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.

I hope it works out.

I want a lot of people to use the stdlib API as soon as possible.  That not
only reduces an external dependency, but helps to exercise the stdlib code
much more quickly, exposing any bugs, corner cases, or missing features
early.  If there's an easy migration path, it's much more likely to be adopted
sooner.  Case in point: the enum module, which was compatible enough with
existing third party APIs that a simple conditional import statement allowed
for an early opt-in.

A third party shim module has several disadvantages.  You're trading one
external dependency for another, and on some platform you might even be
trading a distro-packaged one for a non-distro-packaged one.  You're certainly
trading a tried-and-true dependency for a brand new one.  Plus, you have to
commit to supporting that new PyPI package for a long time, and make it
compatible across multiple versions of Python.  If you're going to go through
all that trouble, why not include the batteries in the first place?

It's not like the simple pkg_resources API is a bad API.

Since I think you understand where I'm coming from by now, I'll stop
belaboring the point.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/import-sig/attachments/20151125/f56f77b9/attachment.sig>