On Jun 23, 2013, at 1:22, Anders Hovmöller <boxed@killingar.net> wrote:

You initially said that ObjC deals with this problem better than Python, and now you say that it's better because it forces you to use the keyword names (actually they're part of the method name, but let's ignore that) _always_, which Python only forces you to do it when not using them positionally.

I don't understand why you're making this argument in support of a proposal that would make Python even less explicit about keyword names, less like ObjC, and, by your analysis, harder to maintain and therefore worse.

I think you and I are talking about different things when talking about "this problem". For me the problem is to avoid stuff like "foo(1, 'foo', None, 9, 'baz')", not avoid repeating names.

But your suggestion wouldn't affect that at all, as not a single one of the arguments is a variable, much less a variable with the same name as a keyword parameter.

And I don't think it's a coincidence that you came up with a bad example--I think good examples are very rare.

I just believe that python has syntax that promotes positional arguments even when it makes the code worse. My suggestion might on the surface look like just a way to type less, but that misses the point. It's about shifting the balance towards keyword arguments.

I don't think it does. It shifts the balance toward creating unnecessary local variables instead of explicit keyword names. Let's look at your example again, five different ways:

foo(1, 'foo', None, 9, 'baz')

foo(bar=1, baz='foo', qux=None, spam=9, eggs='baz')

bar, baz, qux, spam, eggs = 1, 'foo', None, 9, 'baz'

foo(bar, baz, qux, spam, eggs)

bar, baz, qux, spam, eggs = 1, 'foo', None, 9, 'baz'

foo(bar=bar, baz=baz, qux=qux, spam=spam, eggs=eggs)

bar, baz, qux, spam, eggs = 1, 'foo', None, 9, 'baz'

foo(=bar, =baz, =qux, =spam, =eggs)

I'll agree that the 5th is better than the 4th. But the 2nd and 3rd are also much better than the 4th, and the 5th.

In particular, if your arguments are already in variables with the same name as the parameters, adding the keyword names doesn't add anything.

That may not be so obvious with this silly example, so let's take a real example:

In an expression like "Barrier(4, f, 5)", it's completely unclear what the arguments mean without reading the help. Even with "Barrier(len(threads), callback, 5)" it's not very clear. But with "Barrier(parties, action, timeout)" there's no confusion at all.

Your suggestion would do nothing to encourage the use of keywords in the first two cases, where they're essential, but only in the last case, where they don't add any information.

On top of that, if the most natural names for your variables do not match the keywords, your change would encourage renaming them just to access the syntactic sugar.

The only common case where I see this being useful is in the construction of dict (and other mappings), and I think the alternative ideas described by (IIRC) Nick Coghlan are much more interesting for that use case.

But just because I can't imagine it doesn't mean it's not real. If you can show some real-life code, or even realistic fake code, where there are variables that match the parameter names, and the author either used keywords leading to overly verbose code, or should have used them but didn't leading to confusing code, please offer up the examples.