Author jaraco
Recipients Anthony Sottile, Zac Hatfield-Dodds, domdfcoding, jaraco, miss-islington
Date 2021-05-30.17:36:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1622396216.0.0.105052838213.issue44246@roundup.psfhosted.org>
In-reply-to
Content
There are known performance concerns. I recommend to set those aside for now or move them to a separate issue because

(a) The performance is theoretically better in the nominal case because it avoids a sort/group operation.
(b) There are known performance degradations introduced by importlib_metadata 3.5 to de-duplicate distributions, degradations mitigated somewhat by importlib_metadata 4.3.
(c) Compatibility layers may be confounding performance concerns.

May I suggest addressing performance concerns in the importlib_metadata project as that project provides much better granularity on the different changes?

> I think my only satisfactory outcome would be:
> - the original api returns actual dicts

The original API returns an actual dict subclass (SelectableGroups).

- the sub-api returns actual lists

With https://github.com/python/importlib_metadata/pull/323, this expectation is also met as EntryPoints is a list.

- the new select is implemented as a separate *new* api without changing the existing api

The new API is invoked only through opt-in calls not previously available in the old API. I believe this achieves your goal without requiring a new name for `entry_points` or `Distribution.entry_points` (and thus creating less toil for consumers).
History
Date User Action Args
2021-05-30 17:36:56jaracosetrecipients: + jaraco, Anthony Sottile, Zac Hatfield-Dodds, miss-islington, domdfcoding
2021-05-30 17:36:56jaracosetmessageid: <1622396216.0.0.105052838213.issue44246@roundup.psfhosted.org>
2021-05-30 17:36:55jaracolinkissue44246 messages
2021-05-30 17:36:55jaracocreate