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

defining the choice of overload when more than one applies #8

Closed
ashleyh opened this issue Dec 9, 2012 · 5 comments
Closed

defining the choice of overload when more than one applies #8

ashleyh opened this issue Dec 9, 2012 · 5 comments

Comments

@ashleyh
Copy link
Contributor

ashleyh commented Dec 9, 2012

I don't think it's completely clear what the following example should print:

class A: pass
class B(A): pass

def f(A a): print('A')
def f(B b): print('B')

f(B())

One might intuitively expect the 'best match' to be chosen, which would print 'B', but the current implementation actually chooses the 'first match', which would print 'A'. This isn't wrong per se but I think it's at least worth documenting.

@JukkaL
Copy link
Collaborator

JukkaL commented Dec 11, 2012

Yes, the desired behaviour is to pick the first matching overload variant. It should be described in the documentation.

@JukkaL
Copy link
Collaborator

JukkaL commented Dec 11, 2012

Ah, and the type checker should probably give a warning in cases like the above example, since the second overload can never be called.

@ashleyh
Copy link
Contributor Author

ashleyh commented Dec 13, 2012

By the way, the overview page says:

The most specific signature is selected at runtime at each call.

@JukkaL
Copy link
Collaborator

JukkaL commented Dec 13, 2012

Oops, that's how I initially designed it, but it turned out to be a bad idea (often there is no single most specific signature). No it should be fixed in the overview.

@ashleyh
Copy link
Contributor Author

ashleyh commented Dec 13, 2012

Yeah, I agree that first match is a better idea, just wanted to point out the discrepancy in the docs.

@JukkaL JukkaL closed this as completed Dec 14, 2012
JukkaL added a commit that referenced this issue Jul 24, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants