Make xml.sax.make_parser accept iterables

[andresdelfino]

BPO	34789
Nosy	@freddrake, @taleinat, @andresdelfino, @miss-islington
PRs	[3.7] bpo-34789: xml.sax.make_parser expects a list not just any sequence #9542 bpo-34789: make xml.sax.make_parser accept iterables of all types #9576 [3.6] [3.7] bpo-34789: xml.sax.make_parser expects a list not just any sequence (GH-9542) #10123 [2.7] [3.7] bpo-34789: xml.sax.make_parser expects a list not just any sequence (GH-9542) #10124

^{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:

assignee = None
closed_at = <Date 2018-10-26.14:57:58.376>
created_at = <Date 2018-09-24.16:04:07.518>
labels = ['expert-XML', '3.8', 'type-feature', '3.7']
title = 'Make xml.sax.make_parser accept iterables'
updated_at = <Date 2018-10-26.14:57:58.375>
user = 'https://github.com/andresdelfino'

bugs.python.org fields:

activity = <Date 2018-10-26.14:57:58.375>
actor = 'taleinat'
assignee = 'docs@python'
closed = True
closed_date = <Date 2018-10-26.14:57:58.376>
closer = 'taleinat'
components = ['XML']
creation = <Date 2018-09-24.16:04:07.518>
creator = 'adelfino'
dependencies = []
files = []
hgrepos = []
issue_num = 34789
keywords = ['patch']
message_count = 11.0
messages = ['326261', '326262', '326279', '326280', '326283', '326285', '328544', '328545', '328546', '328555', '328556']
nosy_count = 5.0
nosy_names = ['fdrake', 'taleinat', 'docs@python', 'adelfino', 'miss-islington']
pr_nums = ['9542', '9576', '10123', '10124']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue34789'
versions = ['Python 2.7', 'Python 3.6', 'Python 3.7', 'Python 3.8']

[andresdelfino]

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.

[freddrake]

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).

[andresdelfino]

I think it makes sense for make_parser to accept any iterable too. I'll update the PR when I have the testcase ready.

[freddrake]

It probably makes more sense to keep that PR for the maintenance branches, and create a new branch / PR to land on master.

[andresdelfino]

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?

[freddrake]

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.