Always use bool and Literal for Python compat code

[sobolevn]

When values used for python compat are defined, they are always bool.
But, we can also highlight that some versions are not supported at all: by marking them as Literal[False].

[AlexWaygood]

Some of these go against the policy we established in #7258

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

[sobolevn]

@AlexWaygood I don't think it is:

1. There are exactly the same annotations we have in multiple other places
2. These are real Literal constants that affect code reachability, that's their main goal

[AlexWaygood]

1. There are exactly the same annotations we have in multiple other places

We agreed in #7258 that we'd pause converting global constants to Literal types. We didn't say that we wanted to revert all of the global constants that already use Literal types. That's going to necessarily lead to a certain amount of inconsistency.

2. These are real Literal constants that affect code reachability, that's their main goal

I don't have a problem with these constants being included in the stubs, since it's plausible that some users might be using them and/or find them useful, and I don't think they do much harm. But I think they're mostly intended as internal implementation details rather than things that are meant to be publicly exported.

[sobolevn]

But I think they're mostly intended as internal implementation details rather than things that are meant to be publicly exported.

It depends, at least 3rd-party plugins for sqlalchemy and requests might be using them to have similar features support for different languages.

[AlexWaygood]

But I think they're mostly intended as internal implementation details rather than things that are meant to be publicly exported.

It depends, at least 3rd-party plugins for sqlalchemy and requests might be using them to have similar features support for different languages.

That's an interesting point. Are 3rd-party plugins for requests and sqlalchemy a thing?

It's worth noting that neither requests nor sqlalchemy appear to document these constants anywhere, so if third-party plugins are using them, they probably shouldn't be.

[sobolevn]

Yes, there are multiple requests and sqlalchemy plugins (like 100+ of them totally):

• https://pypi.org/project/requests-html/
• https://pypi.org/project/requests-async/
• https://pypi.org/project/requests-cache/
• https://pypi.org/project/requests-oauthlib/
• Full list: https://pypi.org/search/?q=requests-

And:

• https://pypi.org/project/sqlalchemy-fsm/
• https://pypi.org/project/clickhouse-sqlalchemy/
• https://pypi.org/project/sqlalchemy-sotero/
• Full list: https://pypi.org/search/?q=sqlalchemy-&o=

[srittau]

I don't think the reasoning from #7258 applies here. From rereading that issue, the main problem was "enum-like" literals. When assigning such a literal to a field or variable and later re-assigning the variable, type checkers will complain. I can't really imagine situations where you would want to assign these "flag-like" literals and later change the flag.

[AlexWaygood]

Alrighty, let's do it then