Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Remove open plugin, not needed with overloaded signatures on typeshed #7794

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
wants to merge 10 commits into from

Conversation

ilai-deutel
Copy link
Contributor

@ilai-deutel ilai-deutel commented Oct 25, 2019

python/typeshed#3371 adds overloaded signatures for open(), Path.open(), etc.
Consequently:

  • Plugins that analyze the signatures of these functions can be removed
  • Tests have to be changed. For instance, reveal_type(open()) now produces error: All overload variants of "open" require at least one argument instead of Too few arguments for "open".

This pull request should probably not be merged before python/typeshed#3371. However, we have a circular dependency: mypy_selftest in the typeshed PR fails because of the issues with mypy tests mentioned above. We can use CI on this PR to make sure the tests will pass on typeshed after merging both PRs.

After python/typeshed#3371 is merged, the typeshed submodule will need to be updated.

@@ -321,8 +325,8 @@ reveal_type(p.open(errors='replace', mode='rb'))
mode = 'rb'
reveal_type(p.open(mode=mode, errors='replace'))
[out]
_program.py:3: note: Revealed type is 'typing.BinaryIO'
_program.py:4: note: Revealed type is 'typing.BinaryIO'
_program.py:3: note: Revealed type is 'typing.IO[Any]'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These seem like regressions. Why can mypy no longer infer BinaryIO here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

p.open(mode='rb', errors='replace') raises an exception (ValueError: binary mode doesn't take an errors argument), so its type is not really BinaryIO.

mypy infers it is a IO[Any] because of the fallback overload with mode: str, but ideally open should have a return type of NoReturn in this case. I wonder if adding an overload variant with a return type of NoReturn would solve the problem.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NoReturn is not really intended for error cases. Falling back to the default return type on error case seems fine to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be clear, when you say "default return type", do you mean IO[Any] or BinaryIO?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at this it seems to me it is better to improve this plugin instead of removing it. For example, the p.open(mode='rb', errors='replace') call will silently fall back to the default overload, but with the plugin we can detect the error and give a nice error message (matching the runtime one).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I modified the plugin to detect use of text-only arguments in binary mode.

@ilevkivskyi
Copy link
Member

The CI failure is caused by python/typeshed#3446.

@ilai-deutel
Copy link
Contributor Author

Fixed upstream, AppVeyor tests now pass

Copy link
Collaborator

@JukkaL JukkaL left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that is close to ready to merge, but there is still an issue with the Python 2 signature of open().

@ilai-deutel ilai-deutel requested a review from JukkaL February 5, 2020 07:57
@ilai-deutel ilai-deutel requested a review from ilevkivskyi April 18, 2020 00:03
@ilevkivskyi
Copy link
Member

Since Jukka made previous reviews, I think it would make sense if he will review.

@ilevkivskyi ilevkivskyi removed their request for review April 18, 2020 20:15
@ilai-deutel
Copy link
Contributor Author

Hi @JukkaL, is there anything else I need to do before we can merge this PR?

@msullivan
Copy link
Collaborator

I'm sorry about this, but I'm going to close this in favor of #9275. (Which I'm also not sure if it is going to get merged)

@msullivan msullivan closed this Oct 18, 2020
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

Successfully merging this pull request may close these issues.

5 participants