gh-121973: Fix flaky test_pyrepl tests

[colesbury]

This fixes the flakiness in:

• test_inspect_keeps_globals_from_inspected_file
• test_inspect_keeps_globals_from_inspected_module

The output already includes newlines. Adding newlines for every entry in the output list introduces non-determinism because it added '\n' in places where stdout is flushed or some buffer becomes full.

The regex also needed to be updated because pyrepl includes control characters -- the visible output on each line doesn't immediately follow a newline character.

• Issue: test_pyrepl: test_inspect_keeps_globals_from_inspected_* are very flaky #121973

[colesbury]

!buildbot s390x Fedora Refleaks

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @colesbury for commit d23344e 🤖

The command will test the builders whose names match following regular expression: s390x Fedora Refleaks

The builders matched are:

• s390x Fedora Refleaks PR

[ambv]

The output already includes newlines.

Good observation!

Adding newlines for every entry in the output list introduces non-determinism (...)

That looks like it's surfacing a different problem then, because run_repl executes the subprocess with -u (unbuffered). So there shouldn't be non-determinism here. But sure, removing the spurious newlines makes sense regardless, so let's do that.

The regex also needed to be updated (...)

Without the extra newlines that may be so. But the new regex is a bit weird. There are no braces in the output, that's an f-string. It's 2am now, I'll come up with something in the morning.

[ambv]

(maybe something as simple as a word boundary would work, i.e. \b instead of [^{{]; but I'll test it in the morning)

[colesbury]

I think -u just disables Python's buffering in TextIOWrapper. It doesn't make things deterministic. Sometimes the read() boundaries match the newlines, but if once process is slower you might read multiple lines in a single os.read(). Or you might be limited by the 1024 bytes in the os.read() call.

There are braces in the output because the "output" also contains the input, which contains an f-string that we don't want to match. That's apparently how ptys work -- I don't make the rules!

A nicer regex would be welcome.

[ambv]

That's apparently how ptys work

Ah, of course, you need to show user input in the terminal, of course. It works as regular output because of possible cursor changes, control characters, syntax highlighting, and stuff.

In any case, I added a caret before the variable name in the output so we could match it. That way if we ever want to query a variable bar but there's foobar in the output, it won't match incorrectly.

[ambv]

!buildbot s390x Fedora Refleaks

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @ambv for commit 1c4be95 🤖

The command will test the builders whose names match following regular expression: s390x Fedora Refleaks

The builders matched are:

• s390x Fedora Refleaks PR

[ambv]

Refleaks buildbot's happy with it, and so am I.

[miss-islington-app]

Thanks @colesbury for the PR, and @ambv for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖

[bedevere-app]

GH-122173 is a backport of this pull request to the 3.13 branch.