-
-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate addinfourl getters #56916
Comments
The documentation for urllib.request.urlopen 0 says that: There's also a third undocumented method: getcode(). Looking at the code1 ISTM that the 3 getters (geturl(), info(), and getcode()):
For these two reasons I propose to:
|
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). 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):
... |
|
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. |
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. |
+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. |
Also note that getcode() is already documented in urllib (not urllib2) documentation:
|
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. |
URLOpener (and by inheritance *FancyURLOpener*) |
This commit by Ezio in the tests is related (1bcddc0a3765) |
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:
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”. |
Blessing a geturl() method or “url” attribute on HTTPError might require bpo-13567 to be fixed |
Thank you so much for your contribution, I close this issue and have merged the PR. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: