bpo-24744: Raises error in pkgutil.walk_packages if path is str#1926
bpo-24744: Raises error in pkgutil.walk_packages if path is str#1926bitdancer merged 13 commits intopython:masterfrom
Conversation
|
@CuriousLearner, thanks for your PR! By analyzing the history of the files in this pull request, we identified @Yhg1s, @ericsnowcurrently and @brettcannon to be potential reviewers. |
|
I think ValueError would be better, but it doesn't matter all that much (the two have a very blurry line between them in Python). A test is needed as well. And we should also add a test that a bytes object also produces some sort of error (we don't care what sort). |
|
@bitdancer what would be the most appropriate place to put the test at? I can see that there is a test written for |
|
I haven't reviewed the reason for the 'hack' of putting the walk_packages test in test_runner, but since this is only checking the raising of an error on bad input, I'm guessing you can put it in test_pkgutil. Try it :) The long term goal is to move the tests from test_runner to test_pkgutil, so any new tests that can go in test_pkgutil should go there. |
|
Hi @bitdancer, I've updated the branch with changes and also added a test. However, I'm not sure why the PR is not reflecting it, although it's from the same branch (https://github.com/CuriousLearner/cpython/tree/fix-issue24744) I'm doing the changes in. This seems weird to me. |
|
Never mind, I figured that out, it was a minor naming issue with the branch. The patch would be now updated here. Please have a look @bitdancer . Let me know if this needs changes. Thanks! |
|
@bitdancer Some of the tests currently in test_runpy are there not because that's the right place for them, but because they re-use some of the testing machinery that's currently in that file. There are a couple of old issues about moving those helpers out into the
|
| with self.assertRaises(ValueError) as context: | ||
| list(pkgutil.walk_packages(str_input)) | ||
|
|
||
| self.assertTrue('path must be None or list of paths' in str(context.exception)) |
There was a problem hiding this comment.
I don't think this assertion is needed. All we care about here is that the ValueError gets raised, we really don't care what the error message is. (This is not always true, but in this case I think it is.)
In fact, in this particular case we don't even care whether we get a ValueError or a TypeError, so I'd make the test accept both as passing. That way we're doing the same check for both str and bytes: all we are trying to prove with these tests is that we get an error rather than an empty list.
| """ | ||
| if path is None: | ||
| importers = iter_importers() | ||
| elif isinstance(path, str) or isinstance(path, bytes): |
There was a problem hiding this comment.
isinstance(path, bytes) is problematic. I was hoping that walk_packages would throw some other error for bytes input (perhaps a TypeError on some string operation), because checking for all the bytes types is a bit of a pain. And testing it, this is in fact true. So the bytes check isn't needed, just the str check. (Yes, the error is a bit mysterious, but if we want to address that, it requires more of a design discussion, and we shouldn't deal with that in this particular issue).
There was a problem hiding this comment.
Hi @bitdancer , what is meant by:
checking for all the bytes types
There was a problem hiding this comment.
bytes, bytearray, array('b') (or whatever the right incantation is), memoryview....
| """ | ||
| if path is None: | ||
| importers = iter_importers() | ||
| elif isinstance(path, str) or isinstance(path, bytes): |
There was a problem hiding this comment.
bytes, bytearray, array('b') (or whatever the right incantation is), memoryview....
|
|
||
| bytes_input = b'test_dir' | ||
| with self.assertRaises(ValueError) as context: | ||
| with self.assertRaises(TypeError): |
There was a problem hiding this comment.
I would like both of these to be assertRaises((TypeError, ValueError)).
|
It would be better if the two tuples were in the same order, but I wouldn't have bothered you with that except that I'd like to request that you delete the test method docstring. We don't in general use docstrings for test methods in the cpython test suite. If there is important information not included in the test name, you can use a comment. But I'd just rename the test "test_walk_packages_raises_on_string_or_bytes_input". |
|
Sure @bitdancer , I've done the changes :) |
bitdancer
left a comment
There was a problem hiding this comment.
I don't see the NEWS entry, I suspect you forgot to 'git add' it.
| * :meth:`pkgutil.walk_packages` now raises ValueError/TypeError if path is | ||
| string/bytes object. | ||
| Previously an empty list was returned. (Contributed by Sanyam Khurana in | ||
| :issue:`24744`.) |
There was a problem hiding this comment.
Please reflow this into a single paragraph. And it should only mention str; it has always raised a TypeError for bytes.
| :issue:`24744`.) | ||
| * :meth:`pkgutil.walk_packages` now raises ValueError if path is a string | ||
| object. Previously an empty list was returned. (Contributed by Sanyam | ||
| Khurana in :issue:`24744`.) |
There was a problem hiding this comment.
'object' is redundant here. Also, mark up "path" as an argument by surrounding it with asterisks.
| ------- | ||
|
|
||
| - bpo-24744: pkgutil.walk_packages function raises ValueError if path is of | ||
| str object type. Patch by Sanyam Khurana. |
There was a problem hiding this comment.
... function now raises a ValueError if *path* is a string ...
94637e5 to
e61e323
Compare
|
Thanks @bitdancer :) |
|
That the line is blurry doesn't mean it should be blurried further in the cases where it's obvious what should be raised. May I ask what's the rationale for ValueError? |
Attempts to resolve: http://bugs.python.org/issue24744
In the Bug @bitdancer suggested that some sort of error should be raised if path is of type str in
pkgutil.walk_packagesfunction.@bitdancer For the meanwhile I've raised TypeError since that was looking most appropriate to me. Please let me know what kind of error is expected to be raised here and I'll update the PR.
Thanks!