Add EntryPoints.__repr__

[amundhov]

@jaraco With commit 0c819641d314ac496eb32b55f2b15215fa6fa55f the behavior of Entrypoints gets a bit disorienting. Being unfamiliar with the EntryPoints API I fired up ipython and inspected the result of selecting some entry-point I am interested in. The representation is that of a regular tuple:

(EntryPoint(name='py.test', value='pytest:console_main', group='console_scripts'), EntryPoint(name='pytest', value='pytest:console_main', group='console_scripts'), EntryPoint(name='humanfriendly', value='humanfriendly.cli:main', group='console_scripts'))

My expectation was that the collection should act like a tuple which can be indexed by integers. Would you be open to accept the custom __repr__ in this PR ? I gather that Entrypoints at this point is essentially an immutable OrderedDict with some convenience selectors/filters. Is this correct? Alternatively you could consider vendoring frozenordereddict (I haven't tried it myself).

[jaraco]

With commit 0c81964 the behavior of Entrypoints gets a bit disorienting.

Thanks for reporting. In an early iteration of this approach, I was aiming to make things like entry_points() return built-in Python objects for simplicity, but ultimately found that simple objects couldn't supply the level of flexibility needed by users of EntryPoints.

My expectation was that the collection should act like a tuple which can be indexed by integers. Would you be open to accept the custom __repr__ in this PR ?

Yes, that seems perfectly reasonable.

Alternatively you could consider vendoring frozenordereddict (I haven't tried it myself).

Given that this implementation is reflected in the stdlib (importlib.metadata), I'm reluctant to include vendored dependencies that aren't also slated for inclusion in the stdlib and it sounds like that won't happen.