[Python-ideas] Short form for keyword arguments and dicts

[Joshua Landau]

On 22 June 2013 22:01, Anders Hovmöller <boxed at killingar.net> wrote:
>
>> Yes, but consistency, y'know. Why "bar = bar ≡ = bar" here and "bar =
>> bar !≡ = bar" there?
>
>
> Keyword arguments aren't the same thing as assignment. The consistency ship
> has sailed and we're not on it :P

Fair 'nuf, except that you wanted {:this, :ugly, :not, :a, :set, :but,
:looks, :like, :one} too.

Why "we need to be consistent here" but "we don't here, btw"?

>> I've skimmed a bit but I'm still unsure; why? How does Objective-C
>> deal with this?
>
>
> They deal with it with the nuclear option: all methods are 100% of the time
> ordered AND named. Unfortunately this has the side effect of a lot of method
> calls like "[foo setX:x y:y width:width height:height font:font]" which is
> almost exactly the same as the worst case in python: "foo.setStuff(x=x, y=y,
> width=width, height=height, font=font)".
>
> This rather brutish approach forces a rather verbose style of writing, which
> is annoying when you just want to bang out a prototype but extremely
> valuable when having to maintain large code bases down the line. One of the
> main points about my suggestion is that there should be almost no overhead
> to using keyword arguments when just passing arguments along or when
> variable names are nice and descriptive. This would create a lower barrier
> to use, which in turn leads to more solid and more readable code (I hope!).

As other people have pointed out, you've sort'a just contradicted yourself.

>> >> There are so many more cases to cover and this doesn't fill them,
>> >
>> > Like what? At least name one so we can have a discussion about it!
>>
>> One? Well, the one above!
>>
>> I agree that classes seem a bit far-fetched (personally I dislike that
>> syntax) but what about:
>>
>> def function(arg=arg):
>>     ...
>>
>> def function(arg):
>>     self.arg = arg
>
> (Where is self defined?)

Yeah, you know what I meant.

>> thing = dictionary[thing]
>>
>> and so on, which are all of the same form, albeit with different
>> "surroundings". We can't just double the whole syntax of Python for
>> this!
>
> I'm not suggesting that though. It seems to me like you're taking my
> suggestion in absurdum.

Hang on; you asked me to point out cases this *didn't* cover. I'd be
very surprised if you managed to both not-propose and propose any of
these.

>> Does foo(=bar) not bug you?
>> Really?
>
> Compared to foo(bar=bar)? No.

We'll just have to disagree.
Strongly.