| msg141756 - (view) |
Author: Ezio Melotti (ezio.melotti) *  |
Date: 2011-08-07 23:46 |
| The documentation for urllib.request.urlopen [0] says that: """ This function returns a file-like object [addinfourl] with two additional methods from the urllib.response module geturl() — return the URL of the resource retrieved, [...] info() — return the meta-information of the page, [...] """ There's also a third undocumented method: getcode(). Looking at the code[1] ISTM that the 3 getters (geturl(), info(), and getcode()): 1) have an inconsistent interface (why not getinfo() or getheaders()?); 2) they just return the url, headers, and code attributes; For these two reasons I propose to: * document the 3 attributes as the suggested way to access this information; * deprecate the 3 getters; * avoid to document the now undocumented getcode(); [0]: http://docs.python.org/py3k/library/urllib.request.html [1]: Lib/urllib/response.py:83 |
|
|
| msg141757 - (view) |
Author: Ezio Melotti (ezio.melotti) * |
Date: 2011-08-08 00:26 |
| Another possible improvement that can be done is providing a proper Response object instead of addbase, addinfo, addinfourl (yes, those are oddly-named classes, not functions [0]). The Response object could be like 'addbase', but with this signature: class Response: def __init__(self, fp, headers=None, url=None, code=None): ... and without additional getters. The addclosehook class could be provided via an alternative constructor: @classmethod def with_close_hook(cls, fp, hook, *hookargs): ... [0]: Lib/urllib/response.py |
|
|
| msg142424 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2011-08-19 12:04 |
| > For these two reasons I propose to: > * document the 3 attributes as the suggested way to access this > information; > * deprecate the 3 getters; > * avoid to document the now undocumented getcode(); +1 > The addclosehook class could be provided via an alternative constructor I can’t say why, but I don’t like that. |
|
|
| msg142438 - (view) |
Author: Ezio Melotti (ezio.melotti) * |
Date: 2011-08-19 12:50 |
| I thought about having another class, but I couldn't come up with a decent name for it (ResponseWithCloseHook?). After all it's still a Response and unless you need a way to distinguish responses with and without close hooks, I think it might be better to have a single class for both. |
|
|
| msg147983 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2011-11-20 12:02 |
| > I thought about having another class, but I couldn't come up with a > decent name for it (ResponseWithCloseHook?). If it’s used together with the base Response class (I don’t have the details in memory anymore), you could try ClosingMixin or FileLikeMixin. |
|
|
| msg180901 - (view) |
Author: Petri Lehtinen (petri.lehtinen) * |
Date: 2013-01-29 11:31 |
| +1 for the documentation changes, which should be applied to 2.7 as well. The deprecation is the only thing to go to 3.4 only, if it's done at all. |
|
|
| msg180902 - (view) |
Author: Petri Lehtinen (petri.lehtinen) * |
Date: 2013-01-29 11:43 |
| Also note that getcode() is already documented in urllib (not urllib2) documentation: http://docs.python.org/2/library/urllib.html#urllib.urlopen |
|
|
| msg184552 - (view) |
Author: Senthil Kumaran (orsenthil) * |
Date: 2013-03-18 23:22 |
| And getcode is documented all 3.x documentation now. URLOpener (and by inheritance) raise DeprecationWarning since 3.3. I believe, when class becomes deprecated and removed, their methods go away too? For the URLOpener, I would like that to happen as it will present a much cleaner newer way for further enhancement. |
|
|
| msg184553 - (view) |
Author: Senthil Kumaran (orsenthil) * |
Date: 2013-03-18 23:23 |
| URLOpener (and by inheritance *FancyURLOpener*) |
|
|
| msg184567 - (view) |
Author: Senthil Kumaran (orsenthil) * |
Date: 2013-03-19 00:34 |
| This commit by Ezio in the tests is related (1bcddc0a3765) |
|
|
| msg234945 - (view) |
Author: Martin Panter (martin.panter) * |
Date: 2015-01-29 04:44 |
| I think it would be okay to deprecate the methods in the documentation, but they should not be removed nor trigger warnings any time soon. Currently the following related methods and attributes are documented: * addinfourl.getcode() == HTTPResponse.status == HTTPError.code * HTTPResponse.reason == HTTPError.reason (HTTPError documentation is vague on this.) * addinfourl.geturl() * addinfourl.info() == HTTPResponse.msg == HTTPError.headers (But see Issue 22989 and patch in Issue 21228 for a quirk with HTTPResponse.) It would be nice to ensure these three classes all implement the same “Response” interface, except that geturl() and “url” may not be appropriate for HTTPResponse. The “code” and “headers” attributes should definitely be documented for consistency. I propose also adding and documenting “reason”. |
|
|
| msg234947 - (view) |
Author: Martin Panter (martin.panter) * |
Date: 2015-01-29 05:06 |
| Blessing a geturl() method or “url” attribute on HTTPError might require Issue 13567 to be fixed |
|
|
| msg352293 - (view) |
Author: Stéphane Wirtel (matrixise) * |
Date: 2019-09-13 11:40 |
| New changeset ff2e18286560e981f4e09afb0d2448ea994414d8 by Stéphane Wirtel (Ashwin Ramaswami) in branch 'master': bpo-12707: deprecate info(), geturl(), getcode() methods in favor of headers, url, and status properties for HTTPResponse and addinfourl (GH-11447) https://github.com/python/cpython/commit/ff2e18286560e981f4e09afb0d2448ea994414d8 |
|
|
| msg352294 - (view) |
Author: Stéphane Wirtel (matrixise) * |
Date: 2019-09-13 11:40 |
| Thank you so much for your contribution, I close this issue and have merged the PR. |
|
|