Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    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?
    Saul Shanabrook
    @saulshanabrook
    Here is the schedule, did anyone publish notes from it though? https://paper.dropbox.com/doc/Typing-Summit-Schedule-7CZ2iT5PNszAq9RmY4WmN
    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!

    Justin Wood
    @mozCallek_twitter
    Next up, a thing confusing me - but I'm sure its simple in the end, I have https://gist.github.com/Callek/74f2bcc77a0c261405df57ac50c870fb (see the log on the gist) which boils down to redefining a var (which may be bytestring to a unicode string via .decode and catching the potential error and passing the unicode normalized version out
    I'm open to both a slight redesign of the file or some way to convince mypy that I know this might not be bytes here, and to indeed use the unicode type for output
    Marti Raudsepp
    @intgr
    I submitted two bugfix PRs to Mypy but they haven't been looked at yet. Am I supposed to request reviews via the GitHub "suggested reviewers"?