Re: Proposed design for importlib.resources()

--===============0155057439569206482==
Content-Type: multipart/signed; boundary="Apple-Mail=_3E2D1A81-DEA1-4868-AFAF-1356C09F3A8C"; protocol="application/pgp-signature"; micalg=pgp-sha512


--Apple-Mail=_3E2D1A81-DEA1-4868-AFAF-1356C09F3A8C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Nov 24, 2015, at 4:05 PM, Barry Warsaw <[email protected]> wrote:
>=20
> On Nov 24, 2015, at 08:21 PM, Brett Cannon wrote:
>=20
>>> Module API vs package API.  Doesn't pkg_resources actually support
>>> something similar to both, with the module function providing a =
convenience
>>> API?
>>=20
>> 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.
>=20
> 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 less
> likely to do it for existing code, despite the ability to remove a =
dependency.
>=20
> If my existing code already has
>=20
>    from pkg_resources import resource_string as resource_bytes
>=20
> all I'd need to do is change this one line to
>=20
>    from importlib.resource import read_bytes as resource_bytes
>=20
> and I'm done.  If I need to support multiple versions of Python, I can =
even
> do:
>=20
>    try:
>        from importlib.resource import read_bytes as resource_bytes
>    except ImportError:
>        from pkg_resources import resource_string as resource_bytes
>=20
> Without this API, it's much more difficult for me to convert my =
existing code,
> either incrementally or whole-hog, because now I have to either add =
that
> convenience function myself (and import it everywhere) or rewrite all =
my call
> sites.  Why bother?


try:
    from importlib import resources
    resource_bytes =3D lambda m, r: resources(m).read_bytes(r)
except ImportError:
    from pkg_resources import resource_string as resource_bytes


I kind of agree though that given there isn=E2=80=99t a major difference =
otherwise,
that making it easier to port code to the new API is a useful thing.


>=20
>> 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. :)
>=20
> It's not better or worse, it's just different.  As pkg_resources has =
shown, it
> doesn't have to be either-or.
>=20
> 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>.
>=20
>> I'm not convinced it's necessary to provide an equivalent open() yet;
>=20
> 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.
>=20
>>> I do have one use of resource_listdir() which is used to find =
importable
>>> plugin modules at runtime.  It's handy.
>>=20
>> 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).
>=20
> 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 common
> 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.
>=20
> Cheers,
> -Barry
> _______________________________________________
> Import-SIG mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/import-sig


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 =
DCFA


--Apple-Mail=_3E2D1A81-DEA1-4868-AFAF-1356C09F3A8C
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWVNiTAAoJEG48vOkzctz6WhsP/ix5U7+x+IdDyh4LKOdwc7kK
6W3q6aPzKnmffcsJCV+6sbaUD4pj+h7y6aYrPgdf8EQb3fAtwu5ag5dWWEdtouHo
E2eQDS1hL8HSx1dHa3i2dNwwf2Ck2M0UvbQggbUuN3Q+6sNiD4iMCadWRYw4HgmE
h/LJN6bUe0Itg32Y6oaJgJXEro1DbO4ZrQVKqyhJaBM7IBVdwArTV5YHBLwjl1or
1tV74FMzBbjduteg67fB8tRgwg2TnCvBT3jsE1asqi+2D139nm5Qt6IEbcixXafP
KyhBwGX9Mp+UN+dheTnLsWh+dKlPW4JnrH9QTUNV+FoAyhkHLFOLuIq38Ssm58AS
yeOKQLwaQqkI8dEwXpIAOB3xHDWPJsiK63/phCar9ORY3fPyBUqosQR/lUOjERiI
j64FOUmjLK1KMNZxipvSHdS0QBbGsiXrpjjYRGgLpnBIA/fhnWJN5eAfwEhJzHsC
A1CcORekr6seOyGPMfBq/f9KoSiA85nG8XqWP3KkWxwietFkiAmDKr/+ijFLqgnw
A5UeVETFLKJTI3Sc6C139/BdKpCpap+ULvFeLkADze1n18gc5wBAJcmJHvM6uKD3
9iexOfikhvnmPtx9F9Ac4X2zRFI84jw7jyG+okcE/Y6g8lyd7oZ/9lDe0f7vXXV4
iWcQ9SabjnPv6Kt2hapO
=hUVC
-----END PGP SIGNATURE-----

--Apple-Mail=_3E2D1A81-DEA1-4868-AFAF-1356C09F3A8C--

--===============0155057439569206482==
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

--===============0155057439569206482==--