GithubHelp home page GithubHelp logo

Comments (5)

sterliakov avatar sterliakov commented on July 28, 2024

This would break PEP484 compliance of mypy. To quote,

For a checked function, the default annotation for arguments and for the return type is Any. An exception is the first argument of instance and class methods. If it is not annotated, then it is assumed to have the type of the containing class for instance methods, and a type object type corresponding to the containing class object for class methods.

The same from typing documentation:

Furthermore, all functions without a return type or parameter types will implicitly default to using Any:

from mypy.

Avasam avatar Avasam commented on July 28, 2024

Hmm, that's kinda old and imo it doesn't make sense to force a type checker to infer any (as that would make all inference-based checking non-compliant, see pytype and pyright). I don't see anything about this in https://typing.readthedocs.io/en/latest/spec/index.html , maybe that's a discussion for the modern typing spec to rectify.

from mypy.

sterliakov avatar sterliakov commented on July 28, 2024

I'm actually quite against doing that, I love that all annotations are "opt in", and I do not have subtle errors and bunch of type-ignore comments when interfacing with some legacy stuff or just poorly typed codebases.

And it's right there in typing spec (here):

It is recommended but not required that checked functions have annotations for all arguments and the return type. For a checked function, the default annotation for arguments and for the return type is Any. An exception is the first argument of instance and class methods. If it is not annotated, then it is assumed to have the type of the containing class for instance methods, and a type object type corresponding to the containing class object for class methods. For example, in class A the first argument of an instance method has the implicit type A. In a class method, the precise type of the first argument cannot be represented using the available type notation.

(that's copied verbatim from current docs)

from mypy.

sterliakov avatar sterliakov commented on July 28, 2024

Either way, this decision cannot be made by a type checker. If you think that typing spec should be amended, then typing-sig or https://github.com/python/typing/issues is the right place to discuss that.

from mypy.

Avasam avatar Avasam commented on July 28, 2024

Thanks for pointing to me where that's addressed in the spec.

It is recommended but not required that checked functions have annotations for all arguments and the return type. For a checked function, the default annotation for arguments and for the return type is Any.
[...]
Type checkers are expected to attempt to infer as much information as necessary.

So default to Any, but if you can infer it that's fine to do so. That keeps pytype, pyright, this request and #4409 compliant. So I think they can be discussed on their own merits.

If you think that typing spec should be amended

Now that I found (you showed me) the section about it, I think the spec is fine as-is. It offers guidelines, a default behaviour, and possibility for checkers to do more.


when interfacing with some legacy stuff or just poorly typed codebases.

When you say "interfacing with legacy stuff", do you mean libraries that are not py.typed? Which brings a clarification: this would not be run on untyped external packages (or could be opt-in like pyright's useLibraryCodeForTypes, but whether this could be allowed as an additional possibility is out of scope of my request)

About poorly typed codebases:

  • I can see the argument for libraries that declare themselves as py.typed, but are missing most return types as a way to hide incorrect typing.
  • As for poorly typed user code (either badly typed, or untyped "legacy stuff"). I'd personally this would help improve one's typing, finding more issues. Or force being explicit about typing that's too dynamic (ie: explicit Any return type). Note that my suggestion also only applies for functions whose parameters are annotated and that mypy already type-checks.

from mypy.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.