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

All commit authors signed the Contributor License Agreement.

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 implementscode but notstatus? Does it break code implementinginfo but notheaders? Before 3.9, only HTTP and HTTPS responses had thestatus attribute, andheaders was not documented whileinfo 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.

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 fromHTTPResponse oraddinfourl would automatically have astatus 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()ifresp.status==200:self.verbose=verbosereturnself.parse_response(resp)

OTOH, forcontextlib.closing(urlopen(url, data)) as fp: and the changefp.info() tofp.headers, the docs forurlopen says (emphasis mine):

This function always returns an object which can work as a
context manager and has the propertiesurl, 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?

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 deprecatedcode attribute andinfo 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.