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

Steven D'Aprano steve at pearwood.info
Tue Jun 25 10:14:35 CEST 2013


On Tue, Jun 25, 2013 at 06:47:57PM +1200, Greg Ewing wrote:
> Steven D'Aprano wrote:
> >>The change required in that case
> >>is much bigger than just replacing '=foo' with 'foo=blarg'.
> >
> >But you don't have to change the *syntax*.
> 
> It's still a bigger change than any automated tool will
> be able to cope with, and if you're changing it manually,
> who cares if the syntax changes or not?

Because having to change the syntax is *one more thing* to worry about 
when you change a variable name, or change a parameter. Because 
forgetting to change the syntax is *one more thing* to go wrong. This 
makes this proposed feature *more* fragile rather than less, and I don't 
think we should be adding syntax that encourages fragile code for 
marginal benefit, particularly when the proposal goes against two of the 
Zen and, frankly, has nothing much going for it except a little less 
typing in a fraction of all function calls.

It doesn't make code more readable, except in the sense that there's 
less to read. If anything, it's *less* readable because it looks like 
you've forgotten the parameter name:

func(a, b, spam=None, ham="green", =eggs, extra=False, another=42*x)

It's less explicit. It priviledges a special case that really isn't that 
important. Out of the infinite number of possible combinations of 
parameter=expression, what's so special about the one where the 
expression happens to be precisely the same string as the parameter? 
Even if it is special, it's not special *enough* to justify special 
syntax.


> >I cannot think of any other syntax, certainly not in Python, which relies 
> >on a name being precisely one value rather than another in order to 
> >work.
> 
> Pardon? *Every* time you use a name, you're relying on it
> being the same as at least one other name somewhere else.

Either I'm not explaining myself, or you're not understanding me. Let me 
give you some examples.

"x = 2*y", if I rename y => z the statement remains "x = 2*z", I don't 
have to change it to "x = x.__mul__(z)".

"mylist.append(None)", if I rename mylist => alist the statement remains 
"alist.append(None), I don't have to change it to 
"alist.extend([None])".

"if seq:", if I rename seq => items the statement remains "if items:", I 
don't have to change it to "if bool(items):".

BUT the proposed syntax is different from everything else in Python:

"func(=spam)", but if I rename spam => ham, I must also change the way I 
call the function to "func(spam=ham)".


The point isn't that it's hard to make that edit. The point is that I 
shouldn't need to make that edit.


> >I exaggerate a little for effect, but it really does seem that many 
> >people think that any piece of code, no matter how trivially small, that 
> >is repeated is a DRY violation. But that's not what DRY is about.
> 
> You seem to think I'm using a form of argument by authority:
> "It's DRY, therefore it's undesirable." But that's not what
> I'm saying. Rather, I'm saying that I feel it's undesirable,
> and I'm using the term DRY to *describe* what I think is
> undesirable about it. Maybe I'm not using the term quite the
> way it was originally meant, but that has no bearing on how
> I feel about the matter and my reasons for it.

This isn't a question of "original meaning", you are misusing DRY to 
describe something which has nothing to do with the principles behind 
DRY, also known as "Single Point of Truth". You might as well describe 
your dislike of func(spam=spam) as "a violation of the Liskov 
Substitution Principle", then say "well that's not what Barbara Liskov 
meant by the LSP, but it's what I mean".

I'm sorry if it annoys you to be told that your understanding of Don't 
Repeat Yourself is mistaken, but it is. It is not "any repetition of 
code is a bad thing".



> >"Every piece of knowledge must have a single, unambiguous, authoritative 
> >representation within a system."
> >
> >https://en.wikipedia.org/wiki/Don%27t_Repeat_Yourself
> >
> >which has nothing to do with writing spam=spam in a function call.
> 
> I'm not so sure about that. I've just been watching this:
> 
> http://pyvideo.org/video/1676/the-naming-of-ducks-where-dynamic-types-meet-sma
> 
> and going by the principles advocated there, if you change the
> name of the parameter in the called function, you *should*
> change the corresponding parameter of your function to match,
> for the sake of consistency. 

The called function may be called from a thousand places. Do you really 
think that because I decide I don't like my local variable to be called 
(say) "first_name", and want to call it "personal_name" instead, that I 
"should" force every other caller to change their local variable too, 
"for the sake of consistency"?

I'm sure you know the proverb about foolish consistency. 



-- 
Steven


More information about the Python-ideas mailing list