[Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

[Michael Selik]

On Fri, Sep 14, 2018 at 12:30 AM Anders Hovmöller <boxed at killingar.net>
wrote:

> Since neither version fits well on one line or even three, I'd have
> written each of those on a separate line, indented nicely to emphasize the
> repetition. Seems fine to me.
>
> Sure. As would I. Doesn't change anything[.]
>

Our aesthetics are different. Some people like Rothko, others don't. Since
that pattern is rare for me, I don't wish for a better way.

The real problem with this code section wasn't the positional arguments,
> but that it was so heavily indented. Whenever I have code so nested, I put
> in a great deal of effort to refactor so that I can avoid the nesting of
> many try/except, for, and if/else statements.
>
> Most code has many problems. Bringing up random other problems instead of
> sticking to the topic doesn't seem very helpful. Or did you want to change
> the topic to generally be about how to clean up code? If so I'd like to
> know so I can stop responding, because that's not what I am trying to
> discuss.
>

I don't think it's off-topic. The ugliness of the line you're talking about
stems in large part from that it's in a heavily indented complex section.
The distinction between positional and keyword args in this case is
superficial.


On Fri, Sep 14, 2018 at 12:27 AM Anders Hovmöller <boxed at killingar.net>
wrote:

> > I enjoy using keywords to explain the values I'm passing. If I already
> have a well-named variable, I'm less keen on using a keyword.
>
> Here lies the crux for me. You're describing telling the next reader what
> the arguments are. But without keyword arguments you aren't telling the
> computer what the arguments are, not really. The position and the names
> become disconnected when they should be connected.
>
> It's very similar to how in C you use {} for the computer but indent for
> the human, and no one checks that they are the same (not true anymore
> strictly because I believe clang has an option you can turn off to validate
> this but it's default off). In python you tell the computer and the human
> the same thing with the same language. This is robust and clear. I think
> this situation is the same.
>

It may be similar in theme, but in my experience it's different in practice
-- how often the problem arises and how difficult it is to detect and fix.

Remembering your comments about string interpolation, it sounds like you
write a lot of templating code and craft large JSON blobs for REST APIs. I
agree that keyword arguments are critical in those situations for avoiding
tedious and error-prone positional matching. When I have similar situations
I tend to avoid the `f(a=a)` annoyance by creating kwds dicts and passing
them around with ** unpacking.

> Here's a possible refactor. I didn't bother with keyword arguments,
> because the variable names are easy to match up with arguments
> positionally. My screen was large enough that I could read the signature at
> the same time as I wrote the call.
> >
> > def recurse(name):
> >     return self.find_ordering_name(name, opts, alias, order,
> already_seen)
> > return itertools.chain.from_iterable(map(recurse, opts.ordering))
>
> I don't see how that changed anything. That just changes it to a
> functional style, but otherwise it's identical.


It avoids creating extra lists, which might make it more efficient. It also
emphasizes the recursion, which wasn't obvious to me when I first glanced
at the code. No, I didn't bother switching to keyword arguments, because I
didn't feel it helped. My screen was big enough to verify the order as I
wrote the arguments.


On Thu, Sep 13, 2018 at 11:35 AM Anders Hovmöller <boxed at killingar.net>
wrote:

> I’ll repeat myself [...]
>

If you feel like you're repeating yourself, the easiest way to avoid
frustration is to simply stop. Don't fall for the sunk cost fallacy,
despite the effort you've put into this proposal.

Have a good evening.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180914/756de16d/attachment.html>