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

[Anders Hovmöller]

Thank you for that long and thoughtful message.

Unfortunately the big hairy examples where I believe something like my
suggestion would be good are stuff I'm sitting and looking right now which
of course is closed source so I can't share it with you :(

Maybe it's just this code base that's pathological or maybe I'm just being
paranoid about stuff not matching up. I'm gonna think about these
possibilities for a while and give up on convincing you guys for now at
least :P


On Tue, Jun 25, 2013 at 11:14 AM, Andrew Barnert <abarnert at yahoo.com> wrote:

> From: Anders Hovmöller <boxed at killingar.net>
> Sent: Monday, June 24, 2013 11:25 PM
>
>
> Before getting to the specific replies, I'd like to repeat my call for
> some examples of real (or at least realistic) code that would actually
> benefit from this change.
>
> I've already agreed that the two special cases of dict construction and
> str.format could benefit—but those are special cases. Nick Coghlan and
> others have already suggested they could be better handled with different
> improvements. Maybe they're wrong; maybe those special cases are important
> enough, and there is no better solution for them. But you're presenting
> this as a broader fix than that, and I don't see it. The only other real
> examples I've seen are my own cases of delegating functions that forward
> their parameters exactly, and I don't think those need to be improved.
>
> Maybe there's a lot more to your idea than I and others are seeing. You're
> clearly a knowledgeable and sane programmer, not some crank, and I believe
> that you do have real code you'd like to improve. But I can't imagine it,
> so I'd like you to demonstrate that real code.
>
> >>When the arguments are already variables (parameters or locals) with the
> same name, you already have the same information, and there is no benefit
> from getting it twice.
> >
> >Absolutely not. At that point you have to make a pretty big assumption
> that this is the case.
>
> An assumption? Sure. A big one? No.
>
> When I'm reading this code:
>
>
>     url = get_appdir_url(per_user, for_domain, create)
>
> … I have to assume that per_user is some kind of flag value that selects
> between a per-user appdir and a local-system appdir, not an integer that
> specifies the primary group ID. Just as I have to assume
> that get_appdir_url returns a URL to an appdir, not a pandas table full of
> the populations of world capitals. In other words, I have to assume that
> whoever wrote the code I'm reading isn't being malicious or psychotic when
> coming up with names.
>
> And again, this is totally different from the paradigm case for keyword
> arguments:
>
>
>     url = get_appdir_url(False, None, True)
>
>
>
> Here, maybe I can guess that one of those two boolean values might be a
> per-user/local-system flag, but I have no idea which one, or whether False
> means local-system or per-user. So, using keywords makes a _huge_
> difference.
>
> But in the previous case, I always know what per_user means. And, in fact,
> adding keywords doesn't affect what I have to assume. When I see this:
>
>
>     url = get_appdir_url(per_user=per_user, for_domain=for_domain,
> create=create)
>
> … I _still_ have to assume that per_user means what I think it means. It's
> the same words, with the same meaning. And adding an "=" prefix to each
> argument wouldn't add any meaning either; it's just a meaningless symbol
> that I have to pass over to read the actual meaning of the code.
>
> > In order to KNOW you need to go look up the function and compare two
> lists of names.
>
>
> No, in order to KNOW I'd need to pore over the implementation of the
> function, and either prove that it does what I expect, or test it
> sufficiently to my satisfaction.
>
> Fortunately, I don't usually need that kind of knowledge when reading
> someone's code. If I want to understand what your script does, or expand
> its functionality, I read it with the assumption that each expression means
> what it says. I may come back and look at some of them more carefully if I
> find a bug, or a clever hack that I don't understand, but that's not the
> usual case when reading code.
>
> > And if it changes keyword arguments will throw an error upon invocation,
> positional arguments will not.
>
>
> How many times has it happened that some function changed the order of its
> parameters, but didn't change anything else that would break your code?
> Maybe once or twice in your lifetime as a programmer? Is it really common
> enough to be worth making your code less readable, even a little bit, to
> protect against it?
>
> >>Most Python programmers today seem to do a decent job finding the right
> balance, and the language and library do a decent job helping them. Could
> that be better? Sure. But encouraging keywords everywhere would not make it
> better.
>
> >
>
> >Just want to point out that you have no idea of knowing that.
>
> Sure I do. And so do you. If you didn't have some sense, based on
> experience reading and writing lots of code in Python and other languages,
> about how well Python programmers take advantage of the freedom to choose
> between positional and keyword arguments, you wouldn't have proposed a
> change in the first place.
>
> And this is the key question. You're supporting the general principle that
> people should use keyword arguments whenever possible—replacing flexibility
> with TOOWTDI dogma. That can be a good thing when the flexibility has been
> poorly used (e.g., Python no longer lets you choose whether to explicitly
> or implicitly decode byte strings), or it can be a bad thing when the
> flexibility leads to better code. A big part of the reason both you and I
> use Python is that people have argued out these kinds of questions, instead
> of just assuming that there's no way of knowing and choosing arbitrarily.
>
> >Except of course the little detail that with my suggestion the added
> noise would be almost insignificant. 1 extra character per variable name.
> Only for really horrible code with variable names of 1 or 2 characters will
> that be a significant increase in "noise".
>
>
> I realize this is almost like Godwin's Law here, but…
>
> By the exact same argument, perl sigils are insignificant. But everyone
> knows they're not. When I see "$remaining = shift(@ARGV);" instead of just
> "remaining = shift(ARGV);", it disturbs the flow of reading code, despite
> only being 1 extra character per variable name. That's what people mean
> when they say it's "ugly"—it's not about typographical beauty, it's about
> being able to look at code and quickly understand what it's doing.
>
> Consider the fact that Python doesn't require parens around conditions, or
> that it does require colons in block-introducing statements. Those are even
> tinier—one characters for the whole statement—and yet they make a huge
> difference in readability.
>
> There's always a cost in adding extra noise, and just saying "It's not
> that bad" isn't a good argument. The question is whether the benefit
> outweighs the cost. The **kw syntax is a stumbling block that every
> immigrant from JavaScript or C++ runs into at some point—first they have to
> figure out what it means, then they have to get used to it. But it's so
> hugely useful that the cost is obviously worth taking. Your =keyword syntax
> would have the same cost. Would it have a similarly large benefit?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130625/52b57b68/attachment-0001.html>