Most operations with literals are optimized as well, so why shouldn't the comparison/contain operators be? I created a new bug report for it because of this fact and the TODO in the `fold_compare` function in `Python/ast_opt.c`.

This PR looks to be the same as one that was recently rejected.

Compare:
   https://github.com/python/cpython/pull/29639/files
   https://github.com/python/cpython/pull/29810/files

See discussion at:
   https://bugs.python.org/issue45843

It doesn't seem to make sense why other operations on literals are optimized but these particular ones aren't optimized (much).

If this bug report isn't accepted, for how long would the TODO remain in `Python/ast_opt.c`?

> It doesn't seem to make sense why other operations on literals are optimized but these particular ones aren't optimized (much).

The existing optimizer optimizes the following cases (note that the parser does not produce negative or complex numbers, they are created by the optimizer):

   -1
   1-2j
   1/3
   16*1024
   2**32-1
   1<<12
   b'a'[0]

They all are extremely common. Virtually every Python file contain some of such expressions, and they are often used in loops. In contrary, it is difficult to find any example of using comparison operations with all constant operands.

List and sets as right operands in literal contains are optimized to constant tuples and frozensets, and I'd like to take this optimization a step further.

We just rejected the same issue 2 days ago. If you feel very strong about this; instead of creating new ticket in the same place, you might want to try python-dev instead. 

Re: the todo comment, feel free to send a patch that removes it. I don't thank that is still applicable.

I agree with Serhiy and Batuhan. Please reach to python-dev of you really want to pursue this even after what has been already discussed.

On the other hand, we can probably just remove the TODO