Message246388
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. |
|
Date |
User |
Action |
Args |
2015-07-07 01:01:38 | martin.panter | set | recipients:
+ martin.panter, orsenthil, r.david.murray, docs@python, BreamoreBoy, berker.peksag, angad |
2015-07-07 01:01:38 | martin.panter | set | messageid: <1436230898.68.0.849372579109.issue13456@psf.upfronthosting.co.za> |
2015-07-07 01:01:38 | martin.panter | link | issue13456 messages |
2015-07-07 01:01:37 | martin.panter | create | |
|