pyrefly icon indicating copy to clipboard operation
pyrefly copied to clipboard

Handling @overload with a docstring declaration

Open arnav-jain1 opened this issue 9 months ago • 1 comments

fixes #359. Added a check to make sure the body was not a docstring. Also added a test in the the third_party folder to show that the change is working. Let me know if anything needs to be changed.

arnav-jain1 avatar May 27 '25 02:05 arnav-jain1

Thanks!

The third_party/conformance tests are pulled from the typing spec conformance test suite, and shouldn't be modified directly here: https://github.com/python/typing/tree/main/conformance

For this type of feature, could you please add an integration test here? https://github.com/facebook/pyrefly/blob/main/pyrefly/lib/test/overload.rs

Also, I think we should only allow docstrings for function bodies if there is an @overload decorator

For example, a program like this should still be invalid:

def foo() -> int:
    """hello"""

yangdanny97 avatar May 27 '25 02:05 yangdanny97

Should be fixed. Added 3 test cases, first one is the basic one. Second one was to make sure that stuff after a docstring would still be typechecked properly and if the body of the function had more info, it wouldn't deem it a stub. The last one is for the case you mentioned of the nonoverloaded function with a docstring.

arnav-jain1 avatar Jun 09 '25 03:06 arnav-jain1

My commits are a bit messy because I am a little new to this but the code should be right

arnav-jain1 avatar Jun 09 '25 03:06 arnav-jain1

Also if you have others that you want me to fix, let me know! I am a bit swamped right now but I can try and get to it soon.

arnav-jain1 avatar Jun 09 '25 04:06 arnav-jain1

@yangdanny97 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

facebook-github-bot avatar Jun 09 '25 15:06 facebook-github-bot

Sorry for the delay @arnav-jain1 and thanks for your contribution

We'll get this merged soon!

My only feedback would be that it's more readable to just use a loop and set the is_overload/has_no_type_checking inside the loop v.s. using a reduce. I've applied that change to the patch that we're merging, so there's no action required from you.

yangdanny97 avatar Jul 02 '25 17:07 yangdanny97

@yangdanny97 merged this pull request in facebook/pyrefly@e888be05e61be13c96eeab456d19eca67fa3644c.

facebook-github-bot avatar Jul 02 '25 17:07 facebook-github-bot

All good on the delay. Been a bit busy so I forgot. But yeah I'll remember that for the future. Im tryna learn haskell or functional programming in general and kind of used it as a fun exercise.

arnav-jain1 avatar Jul 06 '25 20:07 arnav-jain1

Im tryna learn haskell or functional programming in general and kind of used it as a fun exercise.

Functional programming is fun! Pyre being written in OCaml was one of the reasons I joined this team in the first place haha.

The simple reduce ops like sum/any/all are already their own functions, so it's pretty rare to actually use reduce directly I think. These days I only really use reduce if 1) it's chained after a map or filter 2) I'm reducing to a single value 3) the reduce operation is simple.

yangdanny97 avatar Jul 06 '25 22:07 yangdanny97