-
-
Notifications
You must be signed in to change notification settings - Fork 30.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make xml.sax.make_parser accept iterables #78970
Comments
Doc says: "If parser_list is provided, it must be a *sequence* of strings which name modules that have a function named create_parser()" but code concatenas parser_list with an existing list: for parser_name in parser_list + default_parser_list: Fix this by stating parser_list must be a specific kind of sequence, that is, a list. |
I'm just going to presume this issue has been around a long time, but I think that's a pretty safe presumption. Accepting a general sequence instead of only a list would reasonable, and I'd support a fix that caused the code to accept a general sequence (or any iterable) by calling list() on the passed-in value, starting with 3.8. The patch provided looks good for versions in maintenance. (It would also be fine for 3.8 if there's no interest in generalizing the code to accept arbitrary iterables). |
I think it makes sense for make_parser to accept any iterable too. I'll update the PR when I have the testcase ready. |
It probably makes more sense to keep that PR for the maintenance branches, and create a new branch / PR to land on master. |
Admittedly, my Git-fu is not strong, but since the PR was opened against master, and given that the PR as is won't be merged to master, can it still be "backported" to 3.7, 3.6, and 2.7? Shouldn't I update the PR so it can be merged to master (that won't be backported), and then open a new PR against 3.7 that will be backported to 3.6 and 2.7? |
The existing PR can be re-targeted to merge to a maintenance branch (I'd be inclined to merge manually, myself, but will have to check the current devguide to make sure that's still allowed). A new PR can be made for the non-documentation fix for master. My thought is that a PR is more about the patch than about the workflow; a different patch can be handled in a separate PR, and review & discussion are used to determine which PR should be applied where. |
Thanks for reporting the issue and making the PRs, Andrés! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: