<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 13, 2018, 11:48 PM Anders Hovmöller <<a href="mailto:boxed@killingar.net">boxed@killingar.net</a>> wrote:<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"><br><div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div>It's a bit too large for me to make sense of it quickly. My apologies for not offering a holistic refactor.</div></div></div></div></blockquote><div><br></div><div>My tool will print plenty of other examples. You can pick anyone really...</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><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"><div style="word-wrap:break-word"><div>That’s positional because keyword is more painful.</div></div></blockquote><div><br></div><div>Why would keyword arguments be more painful here? They've already split the call across 4 lines. Why not go a bit further and use keyword args to make it 6 or 7 lines? Maybe they decided it reads fine as it is.</div></div></div></div></blockquote><div><br></div><div>Yes, exactly. Why not go further? This is exactly my point. </div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><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>Sure. Run this script against django: <a href="https://gist.github.com/boxed/e60e3e19967385dc2c7f0de483723502" target="_blank">https://gist.github.com/boxed/e60e3e19967385dc2c7f0de483723502</a> </div></div></blockquote><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><br></div><div>It will print all function calls that are positional and have > 2 arguments. Not a single one is good as is, all would be better with keyword arguments.</div></div></blockquote><div><br></div><div>I disagree. Please expand your assertion by explaining why an example is not good as-is and would be better with keyword arguments.</div></div></div>
</blockquote></div><br><div>Because keyword arguments are checked to correspond to the parameters. The example I gave was:</div><div><br></div><div><br>handler.new_file(<br>    field_name, file_name, content_type,<br>    content_length, charset, content_type_extra,<br>)</div><div><br></div><div><br></div><div>it reads fine precisely because the variables names match with the signature of new_file(). But if new_file() is changed they won't match up anymore and it will still read fine and look ok, but now the parameters don't line up and it's broken in potentially very subtle ways. For example if content_type and file_name switch places. Those are the same time but the consequences for the mixup are fairly large and potentially very annoying to track down. </div><div><br></div><div>Do you disagree on this point?</div></div></blockquote></div><div><br></div><div>The mixup you describe would probably cause an immediate error as the filename would not be a valid content type. I suspect it'd be easy to track down.</div><div><br></div><div>Keyword arguments are especially important when the type and value of two arguments are hard to distinguish, like a height and width. If one is an int and the other is a str, or if it must be a str with only a handful of valid values, I'm not so worried about making mistakes.</div><div><br></div><div>Further, I think it's reasonable to use keyword arguments here and no more "painful" than the use of positional arguments in this case. Both are annoyingly verbose. I'd prefer refactoring the new_file method, but I didn't spot where it's defined.</div>