Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add EntryPoints.__repr__ #473

Merged
merged 1 commit into from Dec 1, 2023
Merged

Conversation

amundhov
Copy link
Contributor

@jaraco With commit 0c81964 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).

Change __repr__ to reflect that Entrpoints is are longer indexable by integers like tuples, but signal our custom behavior.
@jaraco
Copy link
Member

jaraco commented Dec 1, 2023

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.

@jaraco jaraco changed the title With commit 0c819641d314ac496eb32b55f2b15215fa6fa55f the behavior of … Add EntryPoints.__repr__ Dec 1, 2023
@jaraco jaraco merged commit 650996f into python:main Dec 1, 2023
jaraco added a commit that referenced this pull request Dec 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants