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

[Anders Hovmöller]

> 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.
>

I agree with everything except the part of the last sentence after the
comma where you misrepresent the entire issue at hand. Again.


> 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:
>

Again you're conflating my suggested syntax with the underlying idea. The
syntax could be "$foo" instead of "=foo" for example. This has the
advantage that it'd be the same in a dict: "{$foo}", but it has the
disadvantage of not being similar to the existing syntax. Again, the idea
itself is a separate thing from the syntax I spent literally 2 seconds to
come up with :P


> It's less explicit.


You mean "more". It's absolutely more explicit than just using the
position.


> 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?
>

It's so special because one can be derived from the other. Which is
impossible in all the other cases.


> Even if it is special, it's not special *enough* to justify special
> syntax.


In your opinion. In my opinion we could have an open ended brain storm
about these types of things, and we can acknowledge that it's a matter of
trade offs.


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

He was using your hyperbole against you :P


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


If you use the alternative of **locals() suggested as an alternative you're
in tons and tons more trouble than just having to make that edit. Or even
worse with the _() magic that goes through the stack and digs out the
locals. *shudder*

I understand you don't like my suggestion, but I hope we can both agree
that locals() for anything but a string formatter with a literal, or
rummaging through the stack is much much worse?


> 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".


Words are defined not by dictionaries but by how they are used. Words
change meaning over time.


> > 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"?
>

Again with the straw man. That wasn't what he said. He said that if
'personal_name' is *a better name for what it actually is* then it is a
good idea to change it in the entire code base. It's always a good idea to
make the names of stuff in your code better. This has nothing to do with
this thread though!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130625/eb0c3560/attachment.html>