Why do this in the AST optimizer, rather than the CFG optimizer?
Can this convert tuples containing slices, as used in numpy, into constants? . E.g. [:, 1]

Why do this in the AST optimizer, rather than the CFG optimizer?

How is this different than any kind of constant folding that we do in the AST optimizer? The only reason to move that I can think of is, having CFG to cover more cases than the AST optimizer (like the stuff compiler generates independently from the AST node) but I do not think it is a valid argument for slices (I can't think of any code path that the AST optimizer would miss).

That wasn't a "please justify yourself" question, just an "I'm curious" question 🙂
I'm wondering whether we should remove constant folding from the CFG optimizer, if the AST optimizer does it anyway.

It seems that neither optimizer turns (0 if True else 1, None) into a constant (yet).

A quick bit of experimentation shows that the CFG optimizer folds default values and annotations, which aren't handled by the AST optimizer.

A quick bit of experimentation shows that the CFG optimizer folds default values and annotations, which aren't handled by the AST optimizer.

How can the CFG optimizer can do extra work on annotations? (Since PEP 563 is enabled by default, they are all strings)? For the default values, I believe this code path should optimize the defaults away, but if there is something wrong with it let's open an issue and discuss.

Try it for yourself. Comment out fold_tuple_on_constants in compile.c

Try it for yourself. Comment out fold_tuple_on_constants in compile.c

It works fine for defaults?

 $ ./python -m dis
def foo(a = (1,2,3)): pass
  1           0 LOAD_CONST               0 ((1, 2, 3))
              2 BUILD_TUPLE              1
              4 LOAD_CONST               1 (<code object foo at 0x7fde5581e520, file "<stdin>", line 1>)
              6 LOAD_CONST               2 ('foo')
              8 MAKE_FUNCTION            1 (defaults)
             10 STORE_NAME               0 (foo)
             12 LOAD_CONST               3 (None)
             14 RETURN_VALUE

Disassembly of <code object foo at 0x7fde5581e520, file "<stdin>", line 1>:
  1           0 LOAD_CONST               0 (None)
              2 RETURN_VALUE

Try running the test suite, and look at the failures. I think it only happens in nested functions with defaults. Not sure why.

Ah, I see. It is not related to the constant folding that I was speaking of (like folding a single default's value a = (1, 2, 3)) but rather the tuple of all default values a=1, b=2 => (1, 2). AFAIK this and some other cases where the compiler generates tuples (via BUILD_TUPLE) but the cases aren't exactly optimizable on the AST is the reason that we do this after the CFG is emitted (BUILD_TUPLE search on Python/compile.c highlights some of these, especially the ones that represents the signatures of function objects).

This PR is stale because it has been open for 30 days with no activity.

@isidentical This has merge conflicts now.

Should this PR and the associated issue be closed as totally abandoned? The conflicts are not resolved for at least six month.

Yes.
@isidentical free free to reopen if you want to.

FTR, we plan to add a new instruction LOAD_COMMON_CONSTANT to handle None, True, False, etc.
We could add [:], [::-1] and other common slice constants to that set.