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

Skip to content

[feature request] Support ellipsis (...) like Callable when we want untyped arguments #1234

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
wittekm opened this issue Feb 23, 2016 · 11 comments
Labels

Comments

@wittekm
Copy link
Contributor

wittekm commented Feb 23, 2016

Hi all,

It would be nice if MyPy supported a similar ellipsis notation to typing.Callable.

From the typing docs,

It is possible to declare the return type of a callable without specifying the call signature by substituting a literal ellipsis for the list of arguments in the type hint: Callable[..., ReturnType].

It would be nice if MyPy supported something similar - i.e.
# type: ... -> ReturnType
or
# type: (...) -> ReturnType

Which would basically evaluate the same way as # type: (Any, Any, Any, Any) -> ConcreteType for a 4-argument function.

@ddfisher
Copy link
Collaborator

This seems pretty reasonable to me, and could be a good starter task for someone looking to get their hands dirty.

Of the two proposed syntaxes, I'd vastly prefer the second one (# type: (...) -> ReturnType), because the first would require special casing in the parser (and there's no point in doing that when the second syntax is fine).

@gvanrossum would this require a change to PEP 484?

@wittekm
Copy link
Contributor Author

wittekm commented Feb 23, 2016

(I'd actually love to jump on this task myself, once the powers that be give it the OK!)

@gvanrossum
Copy link
Member

Yes, it would require a PEP change. But go ahead and make a PR.

--Guido (mobile)
On Feb 22, 2016 5:28 PM, "Max Wittek" [email protected] wrote:

(I'd actually love to jump on this task myself, once the powers that be
give it the OK!)


Reply to this email directly or view it on GitHub
#1234 (comment).

@ddfisher
Copy link
Collaborator

Here's a good place to start: https://github.com/python/mypy/blob/master/mypy/parse.py#L404

@JukkaL JukkaL added the feature label Feb 23, 2016
@JukkaL
Copy link
Collaborator

JukkaL commented Feb 23, 2016

Note that in Python 3 this is already possible by omitting argument type annotations. For example:

def f(a, b) -> int:
    ...

This proposal brings Python 2 syntax closer to Python 3, which is good. Mixing annotated and unannotated arguments in a single function won't be supported for Python 2, but I'd argue that it's a marginal need.

@ddfisher
Copy link
Collaborator

Agreed. Also, aren't unannotated arguments treated equivalently to arguments annotated with Any? So putting Anys in Python 2 annotations is the same as leaving them unannotated in Python 3 (from a type checking perspective).

@wittekm wittekm changed the title [feature request] Support ellipsis (...) like Callable when we want to defer typing on input [feature request] Support ellipsis (...) like Callable when we want untyped arguments Feb 23, 2016
@gvanrossum
Copy link
Member

gvanrossum commented Feb 23, 2016 via email

@ddfisher
Copy link
Collaborator

Right. I was just responding to Jukka's point about mixing annotated and unannotated arguments in a single function.

@gvanrossum
Copy link
Member

I cross-filed this for PyCharm: https://youtrack.jetbrains.com/issue/PY-18598

@JukkaL
Copy link
Collaborator

JukkaL commented Mar 2, 2016

And if python/typing#186 gets accepted, this would make the syntax even closer to the Python 3 syntax in terms of supported features. I assume that this would be okay:

def f(x,  # type: int
      y):
    # type: (...) -> str
    # Note that only x has an annotation, y has an implicit Any type
    ...

@gvanrossum
Copy link
Member

Yes.

--Guido (mobile)
On Mar 2, 2016 10:42 AM, "Jukka Lehtosalo" [email protected] wrote:

And if python/typing#186 python/typing#186
gets accepted, this would make the syntax even closer to the Python 3
syntax in terms of supported features. I assume that this would be okay:

def f(x, # type: int
y):
# type: (...) -> str
# Note that only x has an annotation, y has an implicit Any type
...


Reply to this email directly or view it on GitHub
#1234 (comment).

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

No branches or pull requests

4 participants