Thank you all for reading and responding to my submission.

I post the following without expectation of results, only to expand my 
reasoning:

The following aren't applicable to the situation I described:

def f():
    class
    return

def f(class):
    class
    return

The are not applicable because inside the function, "class" would always 
be contained in a string (as a key of the kwargs dictionary).

To explain further, for:

def f(**kwargs):
     print(kwargs['foo'])
f(foo='bar')

This isn't a problem.  So why is this a problem?

def f(**kwargs):
     print(kwargs['class'])
f(class='foo')

In response to Mr. Brandl's statements:

> First, function call syntax is nicely parallel to parameter definition
> syntax, and it is obviously not possible to define parameters named 
like
> keywords.

For normal arguments this is true:  def a(b,c) is called with 
a(<b>,<c>).  But this parallel breaks down when you introduce variable 
arguments def a(*b) is called a(<b0>,<b1>,<b2>).  And it breaks down 
even more when you add keyword arguments.  def a(**b) is called 
a(<b0name>=<b0value>,<b1name>=<b1value>) At this point, where's the 
parallel?

If anything, there's a parallel between the keywords and the dictionary 
keys, which, as strings, can contain anything.  We obviously have to 
limit this a bit to keep the overall syntax unambiguous, but restricting 
out keywords isn't necessary.  You're essentially preventing us from 
putting keywords in a string.

> Second, making exceptions like this leads to more exceptions and 
finally
> inconsistencies. People will say "if it's allowed here, why not there
> too, where it is grammatically unambiguous". Quoting the Zen: Special
> cases aren't special enough to break the rules.

Allowing keywords as keyword arguments isn't an exception to the rule; 
NOT allowing them is the exception.  "class" is a perfectly valid 
dictionary key, and given that there's no syntactic reason not to allow 
this, why do so?