Inconsistent keyword argument validation for integer keys

[PelinV]

Bug report

Bug description:

There is inconsistent behavior in Python's keyword argument handling when using dictionary unpacking with string keys that contain only digits.

def f(**kwargs):
    return kwargs

# These correctly raise error as expected
f(0=0)  # SyntaxError: keyword can't be an expression
f(**{0: 0})  # TypeError: f() keywords must be strings

# These should raise errors but don't
f(**{'0': 0})  # returns: {'0': 0} - UNEXPECTED
f(**{'0': 0, 'a': 1, 'b': 2})  # returns: {'0': 0, 'a': 1, 'b': 2} - UNEXPECTED

All four calls should behave consistently. Since f(0=0) and f({0: 0}) raise errors (because integer keys are invalid as keyword argument names), f({'0': 0}) should also raise an error because the string '0' cannot be a valid Python identifier for a keyword argument.
I expect to be able to get the same kwargs when migrating them with and without dictionary unpacking.
I can only get {'0':0} when using dictionary unpacking viaf(**{'0': 0})
And I can't get this result without unpacking via f(0=0)

CPython versions tested on:

3.12

Operating systems tested on:

Linux

[ZeroIntensity]

Keyword arguments are just dictionaries, which can support any arbitrary string as a key. Changing this to only support valid identifiers would definitely break a lot of code and slow things down significantly (because we'll need to run the parser every time somebody passes a kwarg).

[terryjreedy]

This is consistent with and basically the same issue as setattr accepting any string as the attribute name, as in setattr(f, '0', 0). This works, but normal attribute access with auto stringification of the name, as in f.0, will not work. One has to access the ersatz attribute with the explicit string '0', as in getattr(f, '0') or f.__dict__['0']. We decided to keep this behavior about 20 years ago when similarly challenged.

[PelinV]

I agree with your argument about the negative consequences of supporting only valid identifiers, however, this may mislead developers.
It is expected that passing arguments to a function in different ways (with or without dictionary unpacking) should provide the same capabilities.
However, using a dictionary gives you more options (especially the ability to use invalid identifiers)
Do I understand correctly that this was done purposefully?
If so, for what purpose was the possibility of using invalid identifiers as argument names added (and why only for this method of passing arguments)?

[ZeroIntensity]

If so, for what purpose was the possibility of using invalid identifiers as argument names added (and why only for this method of passing arguments)?

It's primarily just a party trick, but it's also useful when you want to design something with "secret" functionality. For example, if I had a function python and wanted to add a special parameter that isn't going to show up in a user's IDE, it could be implemented using this technique:

def python(**kwargs):
    special = kwargs.pop(".special", None)
    if special is not None:
        print(f"Special message: {special}")

# For users, this is business as usual. The ".special" parameter won't show up
# in an IDE.
python()

# For me, I can pass my special value
def my_internal_api():
    python(**{".special": "Nobody expects the Spanish Inquisition"})