# Deprecate unmatched keyword args to Func, Case, and Subquery

**URL:** <https://forum.djangoproject.com/t/deprecate-unmatched-keyword-args-to-func-case-and-subquery/33534>\
**Category:** ORM\
**Created:** [August 3, 2024, 6:42pm UTC](https://forum.djangoproject.com/t/deprecate-unmatched-keyword-args-to-func-case-and-subquery/33534 "2024-08-03T18:42:13Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![jacobtylerwalls](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/jacobtylerwalls/32/30603_2.png) [@jacobtylerwalls](https://forum.djangoproject.com/u/jacobtylerwalls)\
**Post date:** [August 3, 2024, 6:42pm UTC](https://forum.djangoproject.com/t/deprecate-unmatched-keyword-args-to-func-case-and-subquery/33534/1 "2024-08-03T18:42:13Z")

</div>

[Ticket-35459](https://code.djangoproject.com/ticket/35459) narrates a debugging session where the culprit turned out to be accidentally passing extraneous keyword args to `Case`.

As I read it, the ticket was accepted to add coverage and clarify in docs how arbitrary `**extra` args are allowed to support custom SQL templates in subclasses. However, there is an interesting asymmetry here we could do something about.

If the left-hand side (the SQL template) has extraneous args e.g. because it was subclassed, and there is no matching right-hand side argument, a `KeyError` escapes from the failed string format operation.  
But if the right-hand side (`**extra`) has extraneous args e.g. because of a mistaken call, the string formatting proceeds without error.

Is there value in putting this behavior on a deprecation path and eventually raising an exception if a provided keyword argument doesn’t match a parameter in the SQL template?