gh-123503: Replace usages of addinfourl and HTTPResponse deprecated attributes with stable ones

[Alexandr153]

I replaced deprecated features with the recommended current features(updated to the latest version)

• Issue: HTTPErrorProcessor uses deprecated members of addinfourl/HTTPResponse #123503

[picnixz]

Please, don't re-create your PRs. Next time, just ask if there is some issue with git and I'll try helping you.

[picnixz]

I would say "yes, let's do this", but I honestly want a second opinion on this change. We can always revert it later during the beta if this causes issues, though.

cc @serhiy-storchaka @vadmium

[python-cla-bot]

All commit authors signed the Contributor License Agreement.

[serhiy-storchaka]

LGTM. 👍

[vadmium]

I don’t understand what you mean by “while retaining backwards compatibility”. Why are you changing the test suite?

There doesn’t seem to be any consideration given to existing user code, such as the caching class in the bug report. Does this change break code that implements code but not status? Does it break code implementing info but not headers? Before 3.9, only HTTP and HTTPS responses had the status attribute, and headers was not documented while info was.

I winder if we at least need documentation saying what changes a user needs to remain compatible with the changes in Python. Maybe also fall back to the old attribute and method as well? This is the problem with deprecating two-way APIs that are implemented in both user code and Python.

[picnixz]

I winder if we at least need documentation saying what changes a user needs to remain compatible with the changes in Python

Mmh, I see your point. You mean that "what if someone coming from something before 3.9 is now trying to port stuff to Python 3.14"? I'd say that anything marked as being deprecated should also be changed on their side but I guess it doesn't hurt having a paragraph in "Porting to 3.14".

Does this change break code that implements code but not status

Strictly speaking, yes. But I wouldn't consider this as being critical as the attribute has been marked as deprecated since 3.9. And any class that inherits from HTTPResponse or addinfourl would automatically have a status attribute.

Does it break code implementing info but not headers

I'd say it's the same as above.

---

That being said, we're already using "possible missing" attributes in, for instance, xmlrpc:

try:
    http_conn = self.send_request(host, handler, request_body, verbose)
    resp = http_conn.getresponse()
    if resp.status == 200:
        self.verbose = verbose
        return self.parse_response(resp)

OTOH, for contextlib.closing(urlopen(url, data)) as fp: and the change fp.info() to fp.headers, the docs for urlopen says (emphasis mine):

This function always returns an object which can work as a
context manager and has the properties url, headers, and status.

So we should already be on the safe side. But OTOH, the changes to other occurrences may indeed break stuff, though I wouldn't consider this as being critical, especially if it's something that's been deprecated since 3.9.

In the original report, what was actually annoying was more that users need to provide the deprecated attributes as well. So I think it's better to move forwards, at the cost of possibly breaking APIs that use deprecated attributes.

Now, if you want to be on the safe side, how about adding a true DeprecationWarning, without any removal plans, and implement a fallback logic if needs arise?

[vadmium]

You mean that "what if someone coming from something before 3.9 is now trying to port stuff to Python 3.14"? I'd say that anything marked as being deprecated should also be changed on their side . . .

But someone using 3.13 today cannot change their deprecated code attribute and info method due to the bug. (They could add the recommended replacements, but they must keep the old ones.)

how about adding a true DeprecationWarning, without any removal plans, and implement a fallback logic if needs arise?

If the fix claims backwards compatibility, I suspect we should add that fallback logic. On the other hand, it would be simpler to just document that a custom class would need porting to the new response attributes in 3.14, and remove the claim that backwards compatibility is retained.

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[serhiy-storchaka]

@vadmium I have added a fallback, so both spellings are accepted.