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.
Created on 2011年08月07日 23:46 by ezio.melotti, last changed 2022年04月11日 14:57 by admin. This issue is now closed.
| Pull Requests | |||
|---|---|---|---|
| URL | Status | Linked | Edit |
| PR 11447 | merged | epicfaace, 2019年01月06日 19:37 | |
| PR 11447 | merged | epicfaace, 2019年01月06日 19:37 | |
| PR 11447 | merged | epicfaace, 2019年01月06日 19:37 | |
| PR 11447 | merged | epicfaace, 2019年01月06日 19:37 | |
| Messages (14) | |||
|---|---|---|---|
| msg141756 - (view) | Author: Ezio Melotti (ezio.melotti) * (Python committer) | 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) * (Python committer) | 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) * (Python committer) | 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) * (Python committer) | 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) * (Python committer) | 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) * (Python committer) | 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) * (Python committer) | 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) * (Python committer) | 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) * (Python committer) | Date: 2013年03月18日 23:23 | |
URLOpener (and by inheritance *FancyURLOpener*) |
|||
| msg184567 - (view) | Author: Senthil Kumaran (orsenthil) * (Python committer) | Date: 2013年03月19日 00:34 | |
This commit by Ezio in the tests is related (1bcddc0a3765) |
|||
| msg234945 - (view) | Author: Martin Panter (martin.panter) * (Python committer) | 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) * (Python committer) | 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) * (Python committer) | 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) * (Python committer) | Date: 2019年09月13日 11:40 | |
Thank you so much for your contribution, I close this issue and have merged the PR. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022年04月11日 14:57:20 | admin | set | github: 56916 |
| 2019年09月13日 11:40:45 | matrixise | set | status: open -> closed messages: + msg352294 keywords: patch, patch, patch, patch, easy resolution: fixed stage: patch review -> resolved |
| 2019年09月13日 11:40:10 | matrixise | set | nosy:
+ matrixise messages: + msg352293 |
| 2019年09月11日 18:28:37 | matrixise | set | keywords:
patch, patch, patch, patch, easy versions: + Python 3.9, - Python 2.7, Python 3.3, Python 3.4 |
| 2019年01月21日 04:59:19 | demian.brecht | set | keywords:
patch, patch, patch, patch, easy nosy: + demian.brecht |
| 2019年01月06日 19:37:53 | epicfaace | set | keywords:
+ patch stage: needs patch -> patch review pull_requests: + pull_request10907 |
| 2019年01月06日 19:37:40 | epicfaace | set | keywords:
+ patch stage: needs patch -> needs patch pull_requests: + pull_request10908 |
| 2019年01月06日 19:37:26 | epicfaace | set | keywords:
+ patch stage: needs patch -> needs patch pull_requests: + pull_request10906 |
| 2019年01月06日 19:37:13 | epicfaace | set | keywords:
+ patch stage: needs patch -> needs patch pull_requests: + pull_request10905 |
| 2015年01月29日 05:30:23 | berker.peksag | set | nosy:
+ berker.peksag |
| 2015年01月29日 05:06:51 | martin.panter | set | messages: + msg234947 |
| 2015年01月29日 04:44:46 | martin.panter | set | messages: + msg234945 |
| 2014年09月01日 01:18:05 | martin.panter | set | nosy:
+ martin.panter |
| 2013年03月19日 00:34:14 | orsenthil | set | messages: + msg184567 |
| 2013年03月18日 23:27:55 | orsenthil | set | assignee: orsenthil |
| 2013年03月18日 23:23:35 | orsenthil | set | messages: + msg184553 |
| 2013年03月18日 23:22:39 | orsenthil | set | messages: + msg184552 |
| 2013年01月29日 11:43:40 | petri.lehtinen | set | messages: + msg180902 |
| 2013年01月29日 11:31:35 | petri.lehtinen | set | nosy:
+ petri.lehtinen messages: + msg180901 versions: + Python 2.7, Python 3.3 |
| 2012年09月26日 16:50:16 | ezio.melotti | set | type: enhancement versions: + Python 3.4, - Python 3.3 |
| 2011年11月20日 12:02:07 | eric.araujo | set | messages: + msg147983 |
| 2011年08月19日 12:50:57 | ezio.melotti | set | messages: + msg142438 |
| 2011年08月19日 12:04:56 | eric.araujo | set | nosy:
+ eric.araujo messages: + msg142424 |
| 2011年08月08日 06:08:04 | nadeem.vawda | set | nosy:
+ nadeem.vawda |
| 2011年08月08日 00:26:11 | ezio.melotti | set | messages: + msg141757 |
| 2011年08月07日 23:46:10 | ezio.melotti | create | |