gh-101536: [docs] Improve attributes of urllib.error.HTTPError

[sobolevn]

There are several tricky parts:

1. The are multiple aliases. url and filename, hdrs and headers, code and status, msg and readonly reason. Which ones should we document? My idea was that we should try to stick to the same names we use in constructor. But, with some exceptions. For example: filename does not make much sense here: I changed it to be url. And the same with msg and hdrs: I use reason and headers
2. Do we need to list aliases? I think so, because otherwise it would be hard to understand that msg and reason are the same thing

CC @facundobatista @orsenthil

• Issue: HTTPError documentation needs improvement #101536

[slateny]

Maybe more concisely, the 'Is' can be dropped here and below? Not sure which style's better though.

[sobolevn]

I am not a native speaker, so I am fine with any decision, which sounds better :)

[facundobatista]

Not English native speaker either, but "Alias for ..." sounds better to me.

[ngie-eign]

My 2 cents: it seems like the shorter property names should be discouraged: the variable names are more cryptic to read in code and might confuse developers/laypeople who don’t know what the shorthand means.

[sobolevn]

it seems like the shorter property names should be discouraged

Yes, this exactly what I was thinking. That's why I went with the longer and more semantic names in the docs.

[facundobatista]

Hello! Thanks for this work. I added a minor detail here.

Regarding your questions, we need to document everything that is public. I like the approach you took of listing first the "good names", declaring the others as aliases.

[facundobatista]

The file like object does not have the body, you can read from it. I'd write something like "A file-like object where the HTTP error body can be read from."

[bedevere-bot]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[sobolevn]

I have made the requested changes; please review again

Thanks everyone!

[bedevere-bot]

Thanks for making the requested changes!

@facundobatista: please review the changes made to this pull request.

[facundobatista]

Wonderful, thanks!

[ngie-eign]

Thank you so very much everyone!!!

[orsenthil]

Thank you. :) LGTM.