Providing a custom HTTPResponse class to HTTPConnection

[bitdancer]

BPO	13456
Nosy	@orsenthil, @bitdancer, @berkerpeksag, @vadmium
Files	response_class.http.client.patch

^{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 = None
created_at = <Date 2011-11-22.19:02:13.337>
labels = ['type-feature', 'docs']
title = 'Providing a custom HTTPResponse class to HTTPConnection'
updated_at = <Date 2019-02-24.22:59:50.115>
user = 'https://github.com/bitdancer'

bugs.python.org fields:

activity = <Date 2019-02-24.22:59:50.115>
actor = 'BreamoreBoy'
assignee = 'docs@python'
closed = False
closed_date = None
closer = None
components = ['Documentation']
creation = <Date 2011-11-22.19:02:13.337>
creator = 'r.david.murray'
dependencies = []
files = ['39856']
hgrepos = []
issue_num = 13456
keywords = ['patch']
message_count = 4.0
messages = ['148136', '221807', '246241', '246388']
nosy_count = 6.0
nosy_names = ['orsenthil', 'r.david.murray', 'docs@python', 'berker.peksag', 'martin.panter', 'angad']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue13456'
versions = ['Python 3.4', 'Python 3.5', 'Python 3.6']

Linked PRs

• gh-57665: Remove 'response_class' from getresponse docstring. #140707

[bitdancer]

The doc string for HTTPConnection.getresponse mentions (in broken English) that the instance's response_class attribute determines what class gets instantiated for a response. The docs do not mention this attribute, nor any other way to control what class is used.

Since this attribute already exists and is mentioned in the doc string, can we consider this a doc error and just document it?

[BreamoreBoy]

ping.

[angad]

I have a patch for this. I have also documented some of the non-documented attributes of HTTPConnection class.

[vadmium]

Why do people want “response_class” to be part of the API? If so, more details about it may need to added, e.g. the following methods and attributes seem to be required: _read_status(), fp, close(), isclosed(), begin() and will_close.

The “debuglevel” attribute seems fairly redundant with the existing set_debuglevel() method.

Also, what is the point of adding the “default_port” attribute, if it cannot be modified? The only use case I can imagine is in a subclass that specifically does modify it. But I’m not sure it should be added at all.

So I am sorry, but I don’t see why any of the three additions in the patch should be made. IMO it would be better to explain that “response_class” is an internal implementation detail, or even drop it entirely from the doc string.

[bitdancer]

I see the doc string typo was fixed in cc71a79. I created PR 14707 to remove the mention from the docstring, but I'm also fine with just closing this and leaving things alone.

[orsenthil]

@bitdancer, great to see you again. Thanks for the PR. We can remove it.