importlib.metadata.PackageMetadata has no get method?

[rra]

Since the return value for importlib.metadata.metadata was fixed in #7331, mypy now incorrectly diagnoses calls to get as a call to an invalid method. That PR took the approach of importing PackageMetadata from the relevant module, but that protocol does not apparently capture the entire supported interface.

(Maybe this is a bug in my understanding of the return value of metadata and get isn't a valid call? But I have a lot of code that does this and it's always worked.)

% cat test.py
from importlib.metadata import metadata
print(metadata("mypy").get("Version"))
% python test.py
0.950
% mypy test.py
test.py:2: error: "PackageMetadata" has no attribute "get"
Found 1 error in 1 file (checked 1 source file)

[duckinator]

I ran into this problem too. get() isn't documented in the importlib.metadata docs ( https://docs.python.org/3/library/importlib.metadata.html ), so mypy/typeshed's behavior is matching the documentation. So I guess the real question would be, is importlib.metadata(pkg).get(key) part of the defined API, or an implementation detail? It looks like it might the latter, but that would surprise me a lot.

[AlexWaygood]

I ran into this problem too. get() isn't documented in the importlib.metadata docs ( https://docs.python.org/3/library/importlib.metadata.html ), so mypy/typeshed's behavior is matching the documentation. So I guess the real question would be, is importlib.metadata(pkg).get(key) part of the defined API, or an implementation detail? It looks like it might the latter, but that would surprise me a lot.

I don't think this is a question that we, at typeshed, can really answer. We're basically taking the type hints from upstream here, and I think — since importlib.metadata is one of the few stdlib modules that is typed — that that's probably the right thing to do. So if I were you, I'd probably ask for clarification over at the https://github.com/python/importlib_metadata issue tracker about why the PackageMetadata protocol doesn't have a .get() method.

[duckinator]

I don't think this is a question that we, at typeshed, can really answer.

Yeah, sorry for the weird phrasing there — I meant that the question is more "is there supposed to be a .get() method?" as opposed to "why did typeshed leave out the .get() method?"

As you pointed out, that question is better answered by the importlib_metadata folks.

I'll open an issue over there asking about it. 🙂

[duckinator]

Opened python/importlib_metadata#384 asking for a clarification on whether it's an implementation detail that should be migrated away from.

[AlexWaygood]

Opened python/importlib_metadata#384 asking for a clarification on whether it's an implementation detail that should be migrated away from.

Thank you!

[AlexWaygood]

I'm marking this issue as "deferred" until we get an answer from upstream

[duckinator]

There's some more details in python/importlib_metadata#384 (comment) , but I'll quote the part that seems directly-relevant here:

tl;dr - yes, it's an implementation detail.

This is another case (similar to python/importlib_metadata#371), where the duck-typing approach has left ambiguity. This project has provided a viable implementation but not a rigorously specified one. In more recent releases, PackageMetadata was introduced to be explicit about the supported interface. That answers the question in the title. It's an implementation detail that was not expected to be used.

The rest of the comment mentions possibly adding it, but right now typeshed is correct.

[AlexWaygood]

The rest of the comment mentions possibly adding it, but right now typeshed is correct.

I don't think there's anything actionable for typeshed here unless and until the runtime decides that .get() should be added to the protocol at runtime. So I'll close this for now — but feel free to open a new issue if the situation changes :)