Skip to content

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

Closed

Description

@BuongiornoTexas

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.

Activity

  1. srittau commented on Apr 12, 2019

    @srittau
    Collaborator

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

  2. BuongiornoTexas commented on Apr 15, 2019

    @BuongiornoTexas
    Author

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

    Regards,

    Larry

  3. added
    reason: inexpressibleClosed, because this can't be expressed within the current type system
    on Apr 15, 2019
  4. srittau commented on Apr 15, 2019

    @srittau
    Collaborator

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

  5. removed
    reason: inexpressibleClosed, because this can't be expressed within the current type system
    on Jun 14, 2019
  6. srittau commented on Jun 14, 2019

    @srittau
    Collaborator

    Literal types are now supported. Patches welcome!

  7. BuongiornoTexas commented on Jun 18, 2019

    @BuongiornoTexas
    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?).

  8. JelleZijlstra commented on Jun 18, 2019

    @JelleZijlstra
    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

Metadata

Metadata

Assignees

No one assigned

    Labels

    topic: ioI/O related issues

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions