Repository navigation
Regression: importlib.metadata.PathDistribution.requires raises AttributeError, name/version raises TypeError #143387
Description
Activity
Upstream commit is python/importlib_metadata@57f31d7 from python/importlib_metadata#519 -- unfortunately, neither the commit nor the PR provide rationale for this change.
Similarly, before:
>>> d = metadata.PathDistribution.at('/tmp') >>> d.name >>> d.version >>>
After:
>>> from importlib import metadata >>> d = metadata.PathDistribution.at('/tmp') >>> d.name Traceback (most recent call last): File "<python-input-2>", line 1, in <module> d.name File "/usr/lib64/python3.15/importlib/metadata/__init__.py", line 542, in name return md_none(self.metadata)['Name'] ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^ TypeError: 'NoneType' object is not subscriptable >>> d.version Traceback (most recent call last): File "<python-input-3>", line 1, in <module> d.version File "/usr/lib64/python3.15/importlib/metadata/__init__.py", line 552, in version return md_none(self.metadata)['Version'] ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^ TypeError: 'NoneType' object is not subscriptable
- changed the title
[-]Regression: importlib.metadata.PathDistribution.requires raises AttributeError[/-][+]Regression: importlib.metadata.PathDistribution.requires raises AttributeError, name/version raises TypeError[/+]on Jan 3, 2026 Agreed the regression seems to stem from the change in PathDistribution.metadata to return None. It does correctly return None, but downstream properties like .name, .version, and .requires weren't updated to handle the NoneType return.
I’d be happy to patch this if it is indeed a regression.
What is the deal here? Do I need to report this to https://github.com/python/importlib_metadata/ ?
Note that, based on tox-dev/pipdeptree#530 I think that
.metadatabeingNoneis a regression of its own.Hi, I'd like to work on this regression fix. I can see the issue is in PathDistribution where requires, name, and version methods don't handle self.metadata being None. I'll add proper None checks to all three methods.
I am not quite sure this is a proper fix. Considering
self.metadatabeing None is a breaking change, I think the best way forward is to revert it.Reacted by Kemal ZebariHow can I move this forward?
@hugovk As the release manager of 3.15, could you please help me determine what the best way forward is here? This change seems to violate PEP 387 – Backwards Compatibility Policy.
This change was an intentional one, and I apologize for it not being clearly traceable to the rationale.
I only had to go one level deeper from python/importlib_metadata#519 to python/importlib_metadata#493 to see the rationale.
Instead, I would expect
dist.metadatato beNonewhen no metadata file is present, and to return an emptyPackageMetadataobject when a metadata file is present but empty.And one layer deeper python/importlib_metadata#489 (comment) describes where the Python 3.14 behavior missed expectations (and conflated the absence of metadata with a degenerate, empty metadata).
I am not quite sure this is a proper fix. Considering
self.metadatabeing None is a breaking change, I think the best way forward is to revert it.I was assuming, perhaps incorrectly, that there would be little if any reliance on reading
Distribution.metadatafrom invalid sources, so this change while technically incompatible was also refining the behavior around previously-unsupported edge cases, adding fidelity where the previous behavior was undefined and incidental. As mentioned in the referenced comments, I'd have expectedemail.message_from_string(None)to have raised an Exception and not produced a degenerate result, so it was an accident (and a bug) that this edge case didn't fail.Based on those assumptions, I was treating this change as a (technically incompatible, but acceptable) bugfix.
[From PEP 387, API compatibility includes: ] Given a set of arguments, the return value, side effects, and raised exceptions of a function. This does not preclude changes from reasonable bug fixes.
Seeing the examples above, I'm now more concerned about the uses resulting from Hyrum's law.
I did release this behavior early in order to gather feedback, and based on this feedback, it does deserve some reconsideration. I don't want to simply revert the behavior, as I'd like to understand what is the proper design moving forward and whether or not that change deserves a deprecation period.
Regarding the
.metadataproperty, I do feel as if theNonevalue better reflects the reality of the situation, and my instinct was that downstream consumers not handlingNoneshould crash (including cases that hit internal use as reported above). Or maybe better would be to throw an exception (MetadataNotFound) and avoid theNonereturn type altogether. I do feel it's important to help consumers distinguish between a metadata folder with a missing METADATA file (but potentially containing other metadata) and one with an empty METADATA file.Let's not revert this quite yet.
@hugovk Based on my explanation above and the fact that this use case was only viable due to an accident in the underlying APIs, do you want to retroactively support the behavior and demand a deprecation period for the change?
To everyone else, what should be the desired behavior when resolving "metadata" (i.e. the fields) for a folder that lacks the METADATA file? Exception, None, or something else (maybe a DegeneratePackageMetadata object that's distinct from actual PackageMetadata)? My instinct now is it should raise an Exception (and keep the API pure).
51 remaining items
- added a commit that references this issue
on May 20, 2026 Thanks Miro.
Hugo, let me know if I should add the note in What's New, or if that's something someone else will do (in the past, that's generally been handled by someone other than me).
- added a commit that references this issue
on May 21, 2026 - added a commit that references this issue
on May 22, 2026 FTR another one: Pylons/plaster#38
- added a commit that references this issue
on Jun 7, 2026 - added a commit that references this issue
on Jun 25, 2026 - added a commit that references this issue
on Aug 16, 2026 - added a commit that references this issue
on Aug 17, 2026 - added a commit that references this issue
on Aug 19, 2026
Bug report
Bug description:
Python 3.14.2
Python 3.15.0a3
I believe this is a regression from 9b38c66 where the
metadataproperty changed the type from_meta.PackageMetadatato_meta.PackageMetadata | Nonebut other properties (here therequiresproperty) do not account for it beingNone.This was discovered as a failure of tests of rpmlint in Fedora's continuous testing of Python pre-releases: https://bugzilla.redhat.com/show_bug.cgi?id=2424585
CPython versions tested on:
3.15
Operating systems tested on:
Linux
Linked PRs