[issue25330] Docs for pkgutil.get_data inconsistent with semantics

Change by Brett Cannon : -- nosy: +twouters ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue25330] Docs for pkgutil.get_data inconsistent with semantics

Change by Brett Cannon : -- nosy: -brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue25330] Docs for pkgutil.get_data inconsistent with semantics

Brett Cannon added the comment: Notice that the returning of None only has to do with searching for the *package*, not the *data file*. So I think the docs are still correct according to your example, Paul. -- ___ Python tracker

[issue25330] Docs for pkgutil.get_data inconsistent with semantics

Paul Ganssle added the comment: I'm not sure if this warrants a separate issue, but I also notice this in the documentation: > If the package cannot be located or loaded, or it uses a loader which does > not support get_data, then None is returned. In particular, the loader for > namespace p

[issue25330] Docs for pkgutil.get_data inconsistent with semantics

Brett Cannon added the comment: This can't change in Python 2.7 because of backwards-compatibility. And I would argue this isn't a serious security risk as pkgutil.get_data() typically works with string constants and values provided by the library and not user-provided values. This is basicall

[issue25330] Docs for pkgutil.get_data inconsistent with semantics

WGH added the comment: I think it can even be considered a security bug. A classic path traversal. The fact that documentation falsely suggests that there's no such vulnerability is clearly not helping. Python 2.7 is affected as well, by the way. -- nosy: +WGH ___

[issue25330] Docs for pkgutil.get_data inconsistent with semantics

Brett Cannon added the comment: Changing this to be a single issue about the difference between the docs and the semantics of pkgutil. The feature request can be made into a separate issue, but there are plans to replace the API with a more stringently defined one in importlib. -- nos