Improved error message for incompatible default argument

[elazarg]

When a default argument is incompatible with the parameter, the current error message is

Incompatible types in assignment (expression has type "B", variable has type "A")

Which is slightly confusing, and does not include the name of the parameter. I suggest changing it to something like

Incompatible default argument for parameter "x" (initializer has type "B", parameter has type "A")

Although I'm sure there are better ways to phrase this.

[gvanrossum]

I'd use "argument" instead of "parameter". With one exception we seem to use "argument" everywhere when referring to function arguments, and "parameter" for generic types.

[elazarg]

Changed to

Incompatible default initializer for argument "x" (initializer has type "B", argument has type "A")

[elazarg]

I'm not sure why does travis fail for 3.3:

pkg_resources.VersionConflict: (pytest 2.9.2 (/home/travis/virtualenv/python3.3.6/lib/python3.3/site-packages), Requirement.parse('pytest>=3.0.0'))

[emmatyping]

#3777 fixes the pytest error

[gvanrossum]

I like this, but I'd like to tweak the error message some more. I'd also like to see an explicit test for the Python 2 syntax where an argument can be a tuple, e.g.

def foo((x, y) = (1, 1)): pass

and some examples of errors there (an incorrect type, and too many or too few values).

[gvanrossum]

To shorten the message a bit, I'd suggest leaving out "initializer" here and replacing that word with "default" three lines below.

[gvanrossum]

Also, if you rebase, the Travis error should be gone.

[gvanrossum]

Ping?

[elazarg]

Sorry. I've been working on this, but (as is usual for me) got carried away. What I have now is a check using an ad-hoc parameter passing instead, and a complete removal of Argument.initialization_statement and Argument.type_annotation since it's not used.

I think these changes are nice, since they clean up some boilerplate, avoid using new top_frame_context in the argument check, and revealed an escaped UnboundType; they also not immediately what you've asked for, and introduce bigger code churn which is not immediately relevant to this PR, so I did not push them.

I'm still trying to figure out how to take only what is needed, and how to get the parameter names correctly in the general case of tuple arguments (instead of having error messages about __tuple_arg_1 having type Tuple[int, Tuple[str, int]] but default has type Tuple[str, Tuple[str, int]]. It shouldn't be too hard, but I'd like to find "the right way" to do it.

I can push the bigger change if you want to see it (it's bigger than necessary, but not huge), or continue to work on the smaller one, which was my intention.

[gvanrossum]

I'd appreciate it if you pushed just the wording changes I suggested, then after that you can work on the bigger one and show it.

[elazarg]

I have actually pushed the wording changes, unless it's not what you meant:

Incompatible default for argument "x" (argument has type "A", default has type "B")

And the error message for tuples is not as clear but I think is passable:

Incompatible default for tuple argument no' 1 (argument has type "Tuple[B, B]", default has type "Tuple[A, B]")

I also kept the use of call expression instead of assignment. I think it's better, but I can revert (this is not the big change).

[gvanrossum]

Sigh. You destroyed the github review history by squashing all your commits. I'm annoyed and am going to close this PR. Please start over with just what I requested without more refactoring.