This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author martin.panter
Recipients BreamoreBoy, angad, berker.peksag, docs@python, martin.panter, orsenthil, r.david.murray
Date 2015-07-07.01:01:37
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1436230898.68.0.849372579109.issue13456@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2015-07-07 01:01:38martin.pantersetrecipients: + martin.panter, orsenthil, r.david.murray, docs@python, BreamoreBoy, berker.peksag, angad
2015-07-07 01:01:38martin.pantersetmessageid: <1436230898.68.0.849372579109.issue13456@psf.upfronthosting.co.za>
2015-07-07 01:01:38martin.panterlinkissue13456 messages
2015-07-07 01:01:37martin.pantercreate