Skip to content
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

Inconsistent type inference between open() and Path().open() #2911

Closed
BuongiornoTexas opened this issue Apr 12, 2019 · 6 comments · Fixed by #3371
Closed

Inconsistent type inference between open() and Path().open() #2911

BuongiornoTexas opened this issue Apr 12, 2019 · 6 comments · Fixed by #3371
Labels
topic: io I/O related issues

Comments

@BuongiornoTexas
Copy link

I have run into an issue with inconsistent type-inferences for open() and pathlib.Path().open().

I've previously raised this as possible mypy bug #6666. In response to this gvanrossum advised:

Right now we have a plugin that special-cases builtins.open() but not Path.open(). This should be solved in typeshed by making the definition of Path.open() overloaded on various Literal types. So I am closing this as "not a mypy bug" but I recommend that you submit a PR to typeshed to add this.

So I am re-raising this issue here. The following snippet demonstrates the issue.

#!/usr/bin/env python3

from pathlib import Path
fp = open('README.rst', 'rt')
print(type(fp))
fp1 = Path('README.rst').open('rt')
print(type(fp1))

yields:

<class '_io.TextIOWrapper'>
<class '_io.TextIOWrapper'>

However, running mypy reveal_type on fp and fp1 yields:

Revealed type is 'typing.TextIO'
Revealed type is 'typing.IO[Any]'

I would expect both of these to reveal typing.TextIO. I found this issue when using a routine that switched TextIO output between sys.stdout (TextIO) and a file opened with Path().open() (IO).

This is on python 3.7.2 and mypy 0.700.

I'm happy to develop a PR on this, but it will be a while before I get started and given I've got a bit of learning curve, probably a while longer before I finish. I'm assuming this shouldn't be an issue given I couldn't find any other references to this problem in several hours of combing github issues and the web in general.

@srittau
Copy link
Collaborator

srittau commented Apr 12, 2019

Literal types are not supported currently, see #2913. Using IO[Any] is currently the best we can do.

@BuongiornoTexas
Copy link
Author

Thanks Sebastian - Should we leave this open until literal types are supported?

Regards,

Larry

@srittau srittau added the reason: inexpressable Closed, because this can't be expressed within the current type system label Apr 15, 2019
@srittau
Copy link
Collaborator

srittau commented Apr 15, 2019

I added the inexpressable tag. We can leave it open so it can be fixed later.

@srittau srittau removed the reason: inexpressable Closed, because this can't be expressed within the current type system label Jun 14, 2019
@srittau
Copy link
Collaborator

srittau commented Jun 14, 2019

Literal types are now supported. Patches welcome!

@BuongiornoTexas
Copy link
Author

I'll pull something together in a while - as I'm still a relative python novice, does the typeshed have a style guide (or ideally, something I can refer to as an acceptable style for implementing literal type lookups?).

@JelleZijlstra
Copy link
Member

Our CONTRIBUTING.md has a couple of style guidelines. For Literals specifically, we're in mostly uncharted territory, though I think we just merged one PR adding Literals.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: io I/O related issues
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants