Anthony Sottile <asott...@umich.edu> added the comment:
> Which types are sneaky and look like built-in types but do not act like them? well for starters, there's the tuple subclass which pretends to be a dict. but it violates substitutability for both `tuple` and `Mapping` so it's not useful in either contexts. mypy complains about incorrect types in overrides for both. the worst part of this is that the `__getitem__` moves from O(1) to O(N) (in some private code this makes importlib.metadata on 3.10 _10x slower than on 3.9_). next there's the `EntryPoints` tuple subclass which looks like a tuple but doesn't at all act like one (__getitem__ fails substitutability for example) -- this is an api break with 3.9 which returned a `list` (can't `.sort()` `.extend(...)`, etc. any more) > Given that backports are available I don't think this is appropriate. re-introducing a backport brings in a tree of dependencies that have been shaky at best with backward compatibility. in other words, using standard library importlib.metadata provides significantly improved compatibility and stability over the moving target backport (and its tree of dependencies, zipp being the one that breaks the most often from experience). you'll notice I closed the flake8 PRs specifically because I didn't want to reintroduce the backport. This backport also globally monkeypatches the import machinery breaking any other consumer as well -- in a tool as popular as flake8 I can't really make that global mutation decision for all of the other consumers. > The typing issues these were *trivially solved* by a dictionary comprehension using `entrypoint.name` -- it really did not need a full rework and break of the api to solve (could have just deprecated the `__iter__` which I actually suggested on the *original implementation* way back in 3.8) > The new APIs are not only easier to describe with types the types describing the new apis require *significant* `# type: ignore`s to pass mypy because they violate basic substitutability. they also cannot be used in any of the contexts they were appropriate for in <3.10 (Dict[str, List[EntryPoint]] or List[Entrypoint] depending on the api). > I'm not aware of a single breakage. I'm sorry but you have to have realized from the many issues on importlib-metadata or the many issues linking to your deprecation issue that there is significant toil caused directly by your change. cpython is meant to be a stable substrate to build upon, please do not force the community to shoulder the burden of your poor api decisions. > even without requiring an updated importlib_metadata backport. your proposed change introduced a different, unrelated package. not without its own maintenance problems (an additional dependency that has to ~work indefinitely, a hack at best to support this breaking change) > Given the amount of adoption already, reverting these changes is likely to > cause more disruption than moving forward with them. I disagree, bigger things have been reverted (see: __future__.annotations) > So far, the only example presented above appears contrived and not an actual > concern I promise you this is not a contrived case, if you look at your issue tracker it has been reported before and by others. For every issue reported there's likely tens or hundreds of others which are not reported. > It's common for Python minor releases to introduce undocumented changes that > are technically incompatible I've seen this as a rationalization for intentional surprise breaking changes but I don't buy it. Additionally your comments about (paraphrased) "the testsuite didn't demonstrate this usecase so I'm free to change it" are frankly a cop out -- your api returned a dict and a list, that's part of the public api -- changing that is a breaking change. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue44246> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
