<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Sep 14, 2018 at 12:30 AM Anders Hovmöller <<a href="mailto:boxed@killingar.net">boxed@killingar.net</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><blockquote type="cite"><div>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.</div></blockquote></div><div style="word-wrap:break-word;line-break:after-white-space"><div>Sure. As would I. Doesn't change anything[.]</div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div><div>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.</div></div></blockquote></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div>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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div><br></div><div><div dir="ltr">On Fri, Sep 14, 2018 at 12:27 AM Anders Hovmöller <<a href="mailto:boxed@killingar.net">boxed@killingar.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> 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.<br><br>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. <br><br>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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> 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.<br>> <br>> def recurse(name):<br>>     return self.find_ordering_name(name, opts, alias, order, already_seen)<br>> return itertools.chain.from_iterable(map(recurse, opts.ordering))<br><br>I don't see how that changed anything. That just changes it to a functional style, but otherwise it's identical.</blockquote><div><br></div><div>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.</div></div><div><br></div><div><br></div><div><div dir="ltr">On Thu, Sep 13, 2018 at 11:35 AM Anders Hovmöller <<a href="mailto:boxed@killingar.net">boxed@killingar.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div></div><div>I’ll repeat myself [...]</div></div></blockquote><div><br></div><div>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.</div></div><div><br></div><div>Have a good evening.</div></div></div>