> It's a bit too large for me to make sense of it quickly. My apologies for not 
> offering a holistic refactor.

My tool will print plenty of other examples. You can pick anyone really...

> 
> That’s positional because keyword is more painful.
> 
> 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.

Yes, exactly. Why not go further? This is exactly my point. 


> Sure. Run this script against django: 
> https://gist.github.com/boxed/e60e3e19967385dc2c7f0de483723502 
> <https://gist.github.com/boxed/e60e3e19967385dc2c7f0de483723502> 
> 
> 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.
> 
> I disagree. Please expand your assertion by explaining why an example is not 
> good as-is and would be better with keyword arguments.

Because keyword arguments are checked to correspond to the parameters. The 
example I gave was:


handler.new_file(
    field_name, file_name, content_type,
    content_length, charset, content_type_extra,
)


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. 

Do you disagree on this point?

/ Anders
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to