Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue on page /keyword_arguments.html #132

Open
kuraga opened this issue Feb 20, 2024 · 4 comments
Open

Issue on page /keyword_arguments.html #132

kuraga opened this issue Feb 20, 2024 · 4 comments

Comments

@kuraga
Copy link

kuraga commented Feb 20, 2024

Good day!

https://beartype.github.io/plum/keyword_arguments.html#why :

@dispatch
def f(x: int, y: float):
    ... # Method 1

@dispatch
def f(y: float, x: int):
   ... # Method 2

Then calling f(1, 1.0) would call method 1 and calling f(1.0, 1) would call method 2.

Yes.

What might be confusing is what f(x=1.0, y=1) would do. For method 1, the call would be equivalent to f(1.0, 1), which wouldn’t match. For method 2, the call would be equivalent to f(1, 1.0), which also wouldn’t match.

It's not confusing. It shouldn't match, should it? There is no method (f) with (float x) and (int y).

Thoughts?

@PhilipVinc
Copy link
Collaborator

Plum only dispatches positional arguments, and pipes through keyword arguments.

To all effects, what plum is doing is interpreting your function definitions as

@dispatch
def f(x: int, y: float, /):
    ... # Method 1

@dispatch
def f(y: float, x: int, /):
   ... # Method 2

.
So you cannot get those methods by keyword arguments.
You can see that, as calling f(x=1.0, y=1) will fail with the error

NotFoundLookupError: `f()` could not be resolved.

Closest candidates are the following:
    f(x: int, y: float)
        <function f at 0x10643b6a0> @ /<ipython-input-4-b2e5973ca9b8>:1
    f(y: float, x: int)
        <function f at 0x106439620> @ /<ipython-input-4-b2e5973ca9b8>:5

because plum will attempt to dispatch to a function with signaturef(**kwargs).

The

@kuraga
Copy link
Author

kuraga commented Feb 20, 2024

@PhilipVinc , thanks!

I agree Plum does such. Agree it is convenient now.

I'm trying to understand the Why Doesn’t Dispatch Fully Support Keyword Arguments? paragraph.

Hence, in some sense, it’s an either-or situation where you have to choose to designate arguments by position or designate arguments by name.

In the above,

  • f(1, 1.0) should call method 1;
  • f(1.0, 1) should call method 2;
  • f(x=1.0, y=1) should raise an error;
  • f(x=1, y=1.0) should call method 1.
  • f(y=1.0, x=1) should call method 2;
  • f(y=1, x=1.0) should raise an error.

No choices, yes?

Which example shows the choice necessity?

@wesselb
Copy link
Member

wesselb commented Feb 28, 2024

Hey @kuraga,

You're right that it would perhaps be possible to set things up in the way that you describe, and that a construction like that wouldn't be unreasonable. Perhaps the documentation is worded a little too strongly. It would be interesting to explore this further! :)

Generally, the design of Plum mimics Julia as closely as possible, which works in the same way.

@kuraga
Copy link
Author

kuraga commented Feb 28, 2024

which works in the same way.

Hm.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants