That does seem like a mistake, want to take a crack at fixing it @niwatori1217 ?

Looking at this again I am tempted to say that we should just declare that these arguments are positional-only. The problem is that adding keyword support is only going to make a confusing API even more worse: for example, do we expect that in

quiver(arg1, arg2, U=u, V=v)

arg1 and arg2 are considered as X and Y, but in

quiver(arg1, arg2, X=x, Y=y)

arg1 and arg2 are considered as U and V?
(Of course you can imaging even more funky cases involving passing e.g. X positionally and Y as keyword, but they are a bit artificial, whereas I don't think the above is.)

I think there's some similarly, the builtin range takes no keyword arguments. Again, it would be pretty terrible if range(3, stop=5) meant range(3, 5) but range(3, step=5) meant range(0, 3, 5)...

I agree that the mix is very confusing, but would allowing all kwarg or all arg make sense?

Honestly I don't really see the point... Documenting xyuvc as positional only seems simpler than "positional only, or all keyword".

Up to five positional arguments are not that nice, in particular since the meaning of the arguments depends on the number of arguments used.

quiver(U, V, **kw)
quiver(U, V, C, **kw)
quiver(X, Y, U, V, **kw)
quiver(X, Y, U, V, C, **kw)

However, adding more options does not simplify the present signature of quiver(*args, data=None, **kw). We cannot add explicit kwargs for XYUVC if we want to maintain compatibility with the above positional variants. The signature itself must be unchanged. The only thing would be to allow different calls.

I would in principle be fine with all-kwarg signatures:

quiver(U=u, V=v, **kw)
quiver(U=u, V=v, C=c, **kw)
quiver(X=x, Y=y, U=u, V=v, **kw)
quiver(X=x, Y=y, U=u, V=v, C=v, **kw)

That could in principle catch errors of using the wrong arguments or positions. Say, you want to use X, Y, U, V and you miss V, you would accidentially end up with U, V, C semantics. On the downside, I don't think that the all-kwarg variants add to readability. And internally this would add to the complexity of argument parsing.

Note also, that other similar functions like contour, pcolor and tripcolor variants are currently all positional only. To be consistent, we should change them all if we change one.

Overall, I'm -0.5 on supporting all-kwarg as well here.

fair enough.

@niwatori1217 Thanks for the suggestion, however we are probably not going to implement this 😞 . Hopefully we will hear from you again!