Marti Raudsepp

Similar to https://github.com/typeddjango/django-stubs/issues/1858#issuecomment-1853693605, even if we can't teach mypy to understand the dynamically generated members of enum classes, I believe we can fix still typechecking of the constructor arguments?

@clouds56 I'm guessing the `Need type annotation for "object"` error may be caused by #1150? Any thoughts how to fix it?

This issue isn't about the dynamic enum members. The report is about the `choices` property. Even if we can't teach mypy about the dynamically generated members of enum, fixing `choices`...

But +1 for adding a FAQ entry about the enum members.

> state that use of the functional API is not supported until that issue is addressed in mypy itself as there is a heap of stuff that just doesn't work...

Ping @Alexerson as author of https://github.com/typeddjango/django-stubs/pull/1529

> I would say it is object, not Any or str. Because `object.__str__` is defined. Passing anything other than `str` causes `request.headers[x]` to return incorrectly typed values in a view...

Apologies in advance for the following rant, but I just find this so weird. When I suggested changing `Any` to `str` in https://github.com/typeddjango/django-stubs/pull/1529#discussion_r1219317158 and in this PR, two maintainers were...

Right now request header values are typed as `str`, see `HttpHeaders` type (which is used for `HttpRequest.headers`). https://github.com/typeddjango/django-stubs/blob/master/django-stubs/http/request.pyi#L24 If you insist that header values are `Any` because they come from...

I split out the non-controversial changes as a separate PR in #1537. This discussion is now focused on whether header values should be typed `str` or `Any`.