Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Phillip Schanely
    @pschanely
    @dmontagu thank you :) Yeah, CrossHair would be much more verbose (and is far from production-ready), but the cool thing is that it could type things like numpy.concatenate, where the return shape depends on the input shapes in ways that Literals+Generics can't express? I think?
    David Montague
    @dmontagu
    yeah, I believe a mypy extension would make it possible to express everything using Literals + Generics, but that's not trivial
    I would really like to build a mypy extension that makes the api much less verbose
    and can handle things like "dimension arithmetic" (np.concatenate)
    but it might be too ambitious of an undertaking for my spare time haha
    in principle I think it should be possible though following the same approach as described in the mypy plugin docs for building a plugin that can handle variadic generic parameters
    (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
    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
    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?