Proper support in the loader API is possible and was on its way to being
coded up until GitHub took precedence (realize this project has put all
other major python projects of mine on hold for nearly 2 years hence the
delay). And pkg_resources I'm sure could be updated to use any new API when
available, so I don't think it's appropriate to bring the name into the
stdlib.
On Mon, Jan 30, 2017, 10:28 Barry Warsaw,
On Jan 30, 2017, at 06:14 PM, Brett Cannon wrote:
What functionality are you after here from pkg_resources? If it's the reading of data files then you will get that in the stdlib through importlib as soon as I'm not working on getting our workflow to work through GitHub's web UI (which obviously includes the migration itself).
http://setuptools.readthedocs.io/en/latest/pkg_resources.html#basic-resource...
Mostly I use:
* resource_filename() * resource_string() (really, resource_bytes!) * resource_stream() (although I'd really like a more open()-like API)
This might fall under a simpler PEP 365. Also, while I would love to have these available say in importlib, I also like to consider a backward compatible API where the stdlib provides the `pkg_resources` module name. That's not totally required though because you can play ImportError games until Python 3.7 (presumably) is in widespread -and only- use.
Cheers, -Barry _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/brett%40python.org