On 21 January 2018 at 01:56, Barry Warsaw wrote:
> On Jan 05, 2018, at 05:12 PM, Nick Coghlan wrote:
>
>>I think the main reason you're seeing a problem here is because
>>ResourceReader has currently been designed to be implemented directly
>>by loaders, rather than being a subcomponent that you c
On Jan 05, 2018, at 05:12 PM, Nick Coghlan wrote:
>I think the main reason you're seeing a problem here is because
>ResourceReader has currently been designed to be implemented directly
>by loaders, rather than being a subcomponent that you can request
>*from* a loader.
>
>If you instead had an in
Barry and I had a meeting at work today and we decided to go with Nick's
idea of using a get_resource_reader(fullname) method on loaders. We aren't
going to go with an ABC and simply depend on the method existing as
implementing the API (and then returning None if the loader can't handle
the specif
On 3 January 2018 at 06:35, Barry Warsaw wrote:
> Brett doesn’t like this, for several reasons (quoting):
>
> 1. redundant API in all cases where the loader is unique to the module
> 2. the memory savings of sharing a loader is small
> 3. it's implementation complexity/overhead for an optimization
We have what I think is one last design question for importlib.resources.
https://gitlab.com/python-devs/importlib_resources/issues/49
The problem is that the ResourceReader ABC omits the package from the function
signatures, so that on a compatible loader, you only need to specify the
resource
