[EiNSTeiN-]

I am opening this PR to preserve and/or values inside comprehension elements. The code below currently turns the fallback expression into a filter and loses the selected value:

def select(rows):
    return [max(0.0, float(row.get("x") or 0.0)) for row in rows]

The incorrect output is:

def select(rows):
    return [max(0.0, float(0.0)) for row in rows if row.get('x')]

A row whose value is missing or false should produce a zero-valued element, but the reconstructed filter drops it. A truthy value should reach float, but the incorrect output substitutes 0.0.

The distinction is also visible in these smaller examples:

[row[1] or 0 for row in rows]
[row[1] and 7 for row in rows]
[row[1] for row in rows if row[0]]

The first two always produce one element per iteration, while the third can reject an iteration. In a COPY/conditional-jump sequence, the retained operand and following discard prove a value-preserving Boolean expression. Optional Boolean conversion instructions do not change that distinction.

The inline-comprehension merger now records whether a pending value merge is and, or or a ternary, and builds the matching AST at the merge. An and/or fold consumes one right-hand value, unlike a ternary's two arms. This also preserves selected operands and call order in [row.first() or row.second() for row in rows], and supports set elements and dictionary values.

List-comprehension syntax begins in Python 2.0. The repaired instruction layout starts in Python 3.12, which introduces inlined comprehensions and removes JUMP_IF_FALSE_OR_POP/JUMP_IF_TRUE_OR_POP; it is not exclusive to 3.14. See PEP 709 and Python 3.12's bytecode changes.

[ejfkdev]

Merged via consolidated PR #28 (commit e629b6c). Your fix, fixtures, behavior cases and integration test are all included and verified together: real-world corpus 6411/6411, stdlib corpus 528/528, behavior tests green on 3.9-3.14. Thanks for the detailed reports and repros!