Skip to content

Python 3 HTTPConnection stubs missing class variables #1901

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

Closed
scottbelden opened this issue Feb 19, 2018 · 3 comments
Closed

Python 3 HTTPConnection stubs missing class variables #1901

scottbelden opened this issue Feb 19, 2018 · 3 comments

Comments

@scottbelden
Copy link
Contributor

The python 2 stubs have the class variables:

class HTTPConnection:
response_class = ... # type: Any
default_port = ... # type: Any
auto_open = ... # type: Any
debuglevel = ... # type: Any
strict = ... # type: Any
timeout = ... # type: Any
source_address = ... # type: Any
sock = ... # type: Any

but the python 3 stubs do not:

class HTTPConnection:
if sys.version_info >= (3, 4):
def __init__(
self,
host: str, port: Optional[int] = ...,
timeout: int = ...,
source_address: Optional[Tuple[str, int]] = ...
) -> None: ...
else:
def __init__(
self,
host: str, port: Optional[int] = ...,
strict: bool = ..., timeout: int = ...,
source_address: Optional[Tuple[str, int]] = ...
)-> None: ...

This causes a mypy error with the following:

error: "Type[HTTPConnection]" has no attribute "debuglevel"

If all that needs to be done is to add the hints for those class variables, then I don't mind making a PR to do so.

Please let me know if I should make the PR or if I have the error wrong and the problem is somewhere else.

@gvanrossum
Copy link
Member

Hmmm... Those attributes are not documented, so I'm not sure it would be a good idea to add them to the stubs. I'm not sure why they exist in the Python 2 stubs.

This kind of question has come up a few times recently. I wonder if we need to have a general ruling on what to do with undocumented/unsupported attributes. Is it better to have mypy flag those, so you know your code is doing something fishy, or is it better to make mypy silent? There's no other tool that I know of that is capable of flagging the use of undocumented attributes, so I'm kind of leaning towards seeing this as a valuable service mypy (or rather, typeshed) provides, rather than a deficiency in the stubs. For example, if we were to add these attributes to the stubs, IDEs like PyCharm would start suggesting auto-completion for undocumented attributes, which I definitely think is a bad idea. (If there's something that's commonly used, you should petition for it to be included in the docs first.)

@scottbelden
Copy link
Contributor Author

I like the idea of these undocumented attributes being flagged. I didn't know that debuglevel was undocumented, but I see that set_debuglevel is the proper way to do it, so I can call that instead.

As far as actual discussion on flagging vs not flagging undocumented/unsupported attibutes, perhaps that should be in a separate issue (I'm not sure if that should be in typeshed or mypy) and this should be closed.

@srittau
Copy link
Collaborator

srittau commented Sep 11, 2018

It seems this problem was resolved using set_debuglevel. If further fields are needed, please file a separate bug report or a PR, using the # undocumented syntax.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants