python/typing

PEP 484, mypy, typeshed, pytype, pyre and typing in PyCharm

dmontagu

@dmontagu

(the top thing under "Current list of plugin hooks" here: https://mypy.readthedocs.io/en/stable/extending_mypy.html#current-list-of-plugin-hooks)

Manuel Vázquez Acosta

@mvaled

@oremanj

Do you want “any type” or do you want “any type with these characteristics”?

Does bound support Protocol?

T = TypeVar("T")
class TypeClassEq(Protocol[T]):
    def __eq__(self: T, other: T) -> bool: ...

TEq = TypeVar("TEq", bound=TypeClassEq)

If so, then bound could be used to mimic constraints by type-classes.

Phillip Schanely

@pschanely

@dmontagu I think you're right. If you wanted to take on the ambitious dependent type aspects, I think you need a solver like the one I'm using. Feel free to ping me for my experience on what works ok and what doesn't!

Justin Wood

@mozCallek_twitter

Hi Everyone - So I'm having some confusion in how I would type a decorator.....

Ethan Smith

@ethanhs

@paabrown sorry, I missed your message, I don't know if it is common :) And yes, you would need to string escape the types

Hi @mozCallek_twitter !

Justin Wood

@mozCallek_twitter

see the simplified example in https://gist.github.com/Callek/8bca70ffbe560c22dba72b21ecd49ec8

I'm basically looking to ideally make the method typed the same as it initially is, but still provide the right magic to the function retry_async and the related inner functions of the wrap

Ethan Smith

@ethanhs

@namruf15 please open a feature request, I don't think there is a way to do this on a project wide level.

Justin Wood

@mozCallek_twitter

the type of the arg(s) doesn't always match the type of the return

I tried to follow, roughly "Decorators that do not change the signature of the function" in python/mypy#3157 but either I'm doing something wrong or that isn't fully implemented yet

Justin Wood

@mozCallek_twitter

I'm open to any advice, a doc location, or a "do it for me" solution.

Ethan Smith

@ethanhs

@mozCallek_twitter so to be clear, are you trying to maintain the exact same signature?

The return type would change, no?

Justin Wood

@mozCallek_twitter

the wrapped method would maintain its return type

Ethan Smith

@ethanhs

Ah ok

Justin Wood

@mozCallek_twitter

(I think I may need to do retry_async itself as Any or some such, so could end up needing a cast ;-) )

but yea, that's the general idea with keeping the wrapped method having its original signature

Ethan Smith

@ethanhs

so it seems that the signature for retry_async_decorator is documented pretty well, so you should be able to translate to types

It isn't clear to me, are these methods supposed to be async?

Justin Wood

@mozCallek_twitter

err yea -- messed up in writing that simplified gist

async def for both

it was mostly the "how do I preserve the wrapped signature" so that e.g. in my gist a call of Foo.bar('str') or Foo.bar(1, 2) would both fail (and would check the return type correctly too)

[where Foo in this case my last message is an instantiation of Foo() and not me calling as a class method]

Ethan Smith

@ethanhs

I think you need https://www.python.org/dev/peps/pep-0612/

But that is still a WIP

Justin Wood

@mozCallek_twitter

hrm ok -- what would you recommend for type annotation here in the meantime (I'm hitting this one with --disallow-untyped-calls)

Justin Wood

@mozCallek_twitter

Open to a suggestion that lets me add stricter type checking and I can comment to that pep for future cleanup ;-)

Ethan Smith

@ethanhs

@mozCallek_twitter maybe consider Callable[[...], Any]

er, maybe Callable[[...], Awaitable[Any]]?

Justin Wood

@mozCallek_twitter

ok, thanks - That helps for now

Thank you very much for not only having mypy as it exists today, but being available for a sync-chat thing like this, it is very helpful! [not sure if you, directly, work on it or if you're just helping as a community member - but either way THANK YOU]

Ethan Smith

@ethanhs

@mozCallek_twitter you're welcome! Yeah I'm on the mypy team, I'm glad you like it!

Justin Wood

@mozCallek_twitter

@ethanhs ok, so I'm still having issues :( my error:

tmp.py:29: error: Incompatible return value type (got "Callable[[Callable[..., Awaitable[Any]]], Callable[..., Awaitable[Any]]]", expected "Callable[..., Awaitable[Any]]")

with this gist https://gist.github.com/Callek/8bca70ffbe560c22dba72b21ecd49ec8

There must be something obvious I'm missing here, but I'm having trouble decoding this error message and even with reveal_type

Ethan Smith

@ethanhs

@mozCallek_twitter the outer function returns a callable that returns a callable, not an awaitable

the retry_async_decorator to be exact

Justin Wood

@mozCallek_twitter

Great thanks! I suspected it was something simple like that, was just banging my head trying to comprehend it.

Ethan Smith

@ethanhs

fair enough, having a callable in the return type of a callable can get confusing

SONALIUMARE

@SONALIUMARE

How do i write the code of lagrange multiplier in lagrange function?

Ethan Smith

@ethanhs

@SONALIUMARE this is a forum for static typing of Python, not general Python question and answers, you'll have to look somewhere else

Malik Koné

@maliky

@pschanely @dmontagu Thank you for your directions. I'm not ready to in mypy's code as I've only been using for one week. But It's good to know what I can or cannot do with the basic installation.

Bernát Gábor

@gaborbernat

@graingert

@gaborbernat is it worth re-opening again?

Got very late the notification for this. I think the feature would be very useful in a post no python 2 world too. It's a matter of fact that type annotations make the code more verbose; so there will be projects who don't want to pay the price of this, or projects you can't modify. In this case, you want to provide the type information as stubs... and for maintaining those stubs would be great if you can use some merge-check tool to validate they're correct against the source.

Saul Shanabrook

@saulshanabrook

Does anyone have a link to any notes/summaries from the PyCon 2019 type summit?

i.e. https://discuss.python.org/t/typing-summit-at-pycon-us/1546

Saul Shanabrook

@saulshanabrook

Here is the schedule, did anyone publish notes from it though? https://paper.dropbox.com/doc/Typing-Summit-Schedule-7CZ2iT5PNszAq9RmY4WmN

Ah I see they are added to the sub-documents https://paper.dropbox.com/doc/Typing-and-mypy-usability-58lNM498db1NalRQsme4U

There are some more notes here but it seems to be restricted access: https://paper.dropbox.com/doc/OwcJbZZBYMc7qU2UWMrBL Could anyone open it up? I am looking for any notes on the discussion around type application to classes/functions.

Michael J. Sullivan

@msullivan

fixed

rpgoldman

@rpgoldman

I'm seeing what I think Is a mypy false positive:

def mypy_type_issue(foo: List[str], bar: List[str]) -> Tuple[List[str], List[str]]:
    new_foo: List[str]
    new_bar: List[str]

    pairlis = list(zip(foo, bar))
    pairlis.sort(key=lambda x: x[0])
    new_foo, new_bar = zip(*pairlis) # *******
    return new_foo, new_bar

The line with the asterisks gives me this error: Incompatible types in assignment (expression has type "Tuple[Any, ...]", variable has type "List[str]"). Is mypy not understanding the * or am I not understanding mypy? Thanks!

Where communities thrive

People

Repo info

Activity