You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After Loader.module_repr has been deprecated, the repr of namespace is like:
<module 'xx' (<_frozen_bootstrap_external.NamespaceLoader object at 0x0000000>)>
which is unreadable. So I purpose the following repr:
<module 'xx' (namespace) from ['path1', 'path2']>
The change purposed to code is:
def_module_repr_from_spec(spec):
"""Return the repr to use for the module."""name='?'ifspec.nameisNoneelsespec.nameifspec.originisNone:
ifspec.loaderisNone:
returnf'<module {name!r}>'else:
returnf'<module {name!r} (namespace) from {list(spec.loader._path)}>'<<<thislinechangedreturnf'<module {name!r} ({spec.loader!r})>'>>>theunmodifiedlineelse:
ifspec.has_location:
returnf'<module {name!r} from {spec.origin!r}>'else:
returnf'<module {spec.name!r} ({spec.origin})>'
In my interpreter test:
>>> import a
>>> a
<module 'a' (namespace) from ['/home/iyume/workspace/cpython/a']>
This is tricky, the proposal removes the loader from the repr, which is useful information, and makes it possible to have ridiculously big reprs due to including the search paths, but it does produce arguably better reprs for lots of situations. I am slightly inclined towards keeping the current repr.
I like this feature suggestion, I can think of a couple times it would have helped some people at work.
I'm not sure how intentional showing the loader in the repr was (e.g. 3.9 shows just <module 'xx' (namespace)>), seems mostly that the change to introduce it was to avoid use of the deprecated Loader.module_repr, if possible. Brett was the last person to touch this logic, in case we want his opinion.
IMO, the paths where the namespace is loaded are particularly useful. I'm +1 to the proposal. I'm not sure that I've ever used the repr of the loader except to recognize that it's a namespace package, which is retained in the proposal.
Filipe mentions the risk of ridiculously big reprs, which seems like a plausible scenario, even with just a couple of very long paths. Still, being able to see the paths in the repr seems a lot more valuable than the memory address of the loader.
I'm thinking that almost all uses of this repr are going to be for internal troubleshooting anyway, so I'm not terribly concerned about the size of the repr. I'm not aware of any situations where large reprs could cause problems, though I certainly don't have a full survey of user experiences.
Activity
FFY00 commentedon Oct 30, 2022
This is tricky, the proposal removes the loader from the repr, which is useful information, and makes it possible to have ridiculously big reprs due to including the search paths, but it does produce arguably better reprs for lots of situations. I am slightly inclined towards keeping the current repr.
@jaraco thoughts?
hauntsaninja commentedon Oct 30, 2022
I like this feature suggestion, I can think of a couple times it would have helped some people at work.
I'm not sure how intentional showing the loader in the repr was (e.g. 3.9 shows just
<module 'xx' (namespace)>), seems mostly that the change to introduce it was to avoid use of the deprecatedLoader.module_repr, if possible. Brett was the last person to touch this logic, in case we want his opinion.jaraco commentedon Nov 6, 2022
IMO, the paths where the namespace is loaded are particularly useful. I'm +1 to the proposal. I'm not sure that I've ever used the repr of the loader except to recognize that it's a namespace package, which is retained in the proposal.
Filipe mentions the risk of ridiculously big reprs, which seems like a plausible scenario, even with just a couple of very long paths. Still, being able to see the paths in the repr seems a lot more valuable than the memory address of the loader.
I'm thinking that almost all uses of this repr are going to be for internal troubleshooting anyway, so I'm not terribly concerned about the size of the repr. I'm not aware of any situations where large reprs could cause problems, though I certainly don't have a full survey of user experiences.
gh-98139: enhance namespace package repr
FFY00 commentedon Nov 6, 2022
Implemented in #98870.