Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Malik Koné
    @maliky
    How do you specify the shape of an array in a typing hint? foo(arr : np.array(3,10) ?)
    Phillip Schanely
    @pschanely
    @maliky You need a pretty expressive type system to handle numpy shapes in the general case (I think the best you can do right now is say that it is an array "numpy.ndarray"). See python/typing#516
    FWIW, I am working on a system which might let you say such things (and looking for people to test/help): https://github.com/pschanely/CrossHair/blob/0e1a8fef06fee1671e923f6a3a49c9be2c48fcac/crosshair/examples/numpy_examples.py#L69
    David Montague
    @dmontagu
    It is possible to handle array shapes if you are willing to get your hands pretty dirty with Literal and generics
    here's a gist I threw together a while ago doing something along these lines: https://gist.github.com/dmontagu/69baaa9459bbfc471136ffd5d38bc6b6
    thinc, the lower-level machine learning library used by spaCy took a related idea a little farther: https://github.com/explosion/thinc/blob/develop/thinc/types.py (they drop checks on specific dimension sizes/dtypes as far as I can tell, but use separate types for different dimension counts)
    David Montague
    @dmontagu
    @maliky crosshair looks very cool
    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.