`Expected TypedDict key to be string literal` when passing `{str('foo'): str('bar')}`

[EvanKrall]

from mypy_extensions import TypedDict


FooDict = TypedDict(
    'FooDict',
    {
        'foo': str,
    },
)


def my_cool_function(arg: FooDict) -> None:
    pass


my_cool_function({"foo": "bar"})
my_cool_function({str("foo"): "bar"})

$ mypy blurp.py
blurp.py:17: error: Expected TypedDict key to be string literal

I understand this is going through the str() function, which is why it's failing, but it seems like this simple case could be handled.

[ilevkivskyi]

but it seems like this simple case could be handled.

But why especially this one, why not str(42), or not str("foo" + "bar")? It is hard to draw the line anywhere except from the very start: this has to be a literal. I propose that we don't do this, sorry.

[gvanrossum]

And ehy would you write that anyway?

[EvanKrall]

Both of those cases also seem like they could work -- there are no variables involved, so as far as I understand they'll produce the same string every time.

I can totally understand the argument that there has to be a line somewhere, and that this would probably require a lot of complexity for dubious gains (i.e. why am I calculating a key for a TypedDict anyway?), so I won't be bothered if this issue gets closed.

[EvanKrall]

And ehy would you write that anyway?

This is no longer necessary for us (since we've finished moving to py3), but it was to ensure that the keys/values were native string types on both py2 and py3 even with from __future__ import unicode_literals, for reasons.