I agree that this is a familiar pattern, but I long since forgot the specifics of the domain it happens in. I borrowed your code, and added filename tracking to see what source files had high `could_have_been_a_matched_kwarg`. Here is the top one:
https://github.com/django/django/blob/master/tests/migrations/test_autodetector.py The argument-name-matches-the-local-variable-name pattern does appear to happen in many test files. I assume programmers are more agnostic about variable names in a test because they have limited impact on the rest of the program; matching the argument names makes sense. There are plenty of non-test files that can use this pattern, here are two intense ones: https://github.com/django/django/blob/master/django/contrib/admin/options.py (212 call parameters match) https://github.com/django/django/blob/master/django/db/backends/base/schema.py (69 call parameters match) Opening these in an IDE, and looking at the function definitions, there is a good chance you find a call where the local variable and argument names match. It is interesting to see this match, but I not sure how I feel about it. For example, the options.py has a lot of small methods that deal with (request, obj) pairs: eg `has_view_or_change_permission(self, request, obj=None)` Does that mean there should be a namedtuple("request_on_object", ["request", "obj"]) to "simplify" all these calls? There are also many methods that accept a single `request` argument; but I doubt they would benefit from the new syntax. On 2018-09-06 06:15, Anders Hovmöller wrote: > I have a working implementation for a new syntax which would make using > keyword arguments a lot nicer. Wouldn't it be awesome if instead of: > > foo(a=a, b=b, c=c, d=3, e=e) > > we could just write: > > foo(*, a, b, c, d=3, e) > _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/