Re: Proposed design for importlib.resources()

--===============1378743933446688671==
Content-Type: multipart/signed; micalg=pgp-sha256;
 boundary="Sig_/4B+rBzrIC9+sk/y+CHpyk8h"; protocol="application/pgp-signature"

--Sig_/4B+rBzrIC9+sk/y+CHpyk8h
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Nov 24, 2015, at 08:21 PM, Brett Cannon wrote:

>> Module API vs package API.  Doesn't pkg_resources actually support
>> something similar to both, with the module function providing a convenie=
nce
>> API?
>
>Yes, but that doesn't sway me. This isn't a "pkg_resources++" but a "make
>reading data from a package make sense in a modern import world". IOW I'm
>purposefully not using pkg_resources as a template but simply as a
>motivating factor.

You're not taking into account a migration path for existing users of
pkg_resources.  If you make it difficult to convert, then people are much l=
ess
likely to do it for existing code, despite the ability to remove a dependen=
cy.

If my existing code already has

    from pkg_resources import resource_string as resource_bytes

all I'd need to do is change this one line to

    from importlib.resource import read_bytes as resource_bytes

and I'm done.  If I need to support multiple versions of Python, I can even
do:

    try:
        from importlib.resource import read_bytes as resource_bytes
    except ImportError:
        from pkg_resources import resource_string as resource_bytes

Without this API, it's much more difficult for me to convert my existing co=
de,
either incrementally or whole-hog, because now I have to either add that
convenience function myself (and import it everywhere) or rewrite all my ca=
ll
sites.  Why bother?

>Unfortunately for you the poll liked the other approach and TOOWTDI. So
>either convince me that resources.read_bytes(pkg, path) is better than
>resources(pkg).read_bytes(path) or consider the bike shed painted. :)

It's not better or worse, it's just different.  As pkg_resources has shown,=
 it
doesn't have to be either-or.

I never saw the poll since I don't pay attention to Google+.  How
representative are those 59 votes of the current pkg_resource users and
potential future users of this API?  If I had seen the poll I would have
complained that it didn't give me a chance to choose both APIs <wink>.

>I'm not convinced it's necessary to provide an equivalent open() yet;

Right, I'm not necessarily advocating for it, just describing what it would
have to do if it were there.  It's something I occasionally wish I had, but
all the building blocks are there to invent it when needed.

>> I do have one use of resource_listdir() which is used to find importable
>> plugin modules at runtime.  It's handy.
>
>I'm going to punt on this for as long as possible because it's asking for
>trouble to get right. For example, if I do resources(pkg).listdir(), then I
>will end up returning relative paths, but if you disassociate those paths
>from pkg then you have lost proper context. You could return tuples of
>(pkg, relative_path), but that just doesn't seem satisfactory either. I'm
>just not convinced yet it is needed enough to support (at least initially).

It's a tougher API to recreate from the building blocks, so it would be nice
not to have to reinvent the wheel everywhere, but it's also a much less com=
mon
API.  I'm not at all worried about the disassociation problem, since
os.listdir() gives you relative paths anyway so it's a familiar behavior.

Cheers,
-Barry

--Sig_/4B+rBzrIC9+sk/y+CHpyk8h
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWVND/AAoJEBJutWOnSwa/X/UQALaKnxq1cxKXSCgtbjFGesgY
w0MY95Nreme0m2OcrGlNOpOgp39z3pIgoSfVAqFd4eeMgcHYhVvDSar6jwi6qTIO
JAzs186zFu3O8o10274W7P+zMxs+Auxe5pgi4eQfmXgqDtVirWBGtJ4yZ88JRrqu
gqJ9PmiRGXlCH2g+6o+HfblVXDXGvOvCw0InbtpQO5lJbgWZQUxQLfs1uml8B1Vw
+9lOUSh0oVbzWXMJfJjvRCd2nDk7rLXyPvtq3oCKNeGv4OHcoRx5gEFnmnlCe03F
tq3TH3/M3SYWAmUxyWW9nn5d/fAYttBfXr39MbUQpvRyOM6uIU5xn7xW7iHgltRG
KaWtED/bpLN2RoNYGd5CaII+0Mvh6NvNxVAfgOXlmS32VieKVn5s5clJZGAi/Njy
GbiNAl4EAjG4YQdovdxNcSA6p7xkbl7wldlxZsJul/Bio88aq+r6qUGe6ZK7iKJj
YLP3scBrwe2sKPciXVI9gADYxRSn5hKgzQPSMJ5YZFdIgmG8gzg8pD3jfKV60Iqe
ZEB/Vm/b7lNSqSgkUxy+Hn6Ut7nUcq9datgva12ilD/enb/vLeVphcHMTm7EO0ps
ztFQf+j5uy8WVExXNUu1UXK7uwcYTObSYAPnKtq3eKAmVREl9ljtMO2zYMcZKafd
/GbT0W0IIt7+z9q1uBFD
=jBqs
-----END PGP SIGNATURE-----

--Sig_/4B+rBzrIC9+sk/y+CHpyk8h--

--===============1378743933446688671==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Import-SIG mailing list
[email protected]
https://mail.python.org/mailman/listinfo/import-sig

--===============1378743933446688671==--