`Event.raw` being added to itself instead of to another event's `.raw` in `UnixConsole.getpending`

[devdanzin]

Bug report

Bug description:

There is a small bug in _pyrepl.unix_console.UnixConsole.getpending, where instead of adding the raw data of event 2, we add the raw data of event 1 to itself:

cpython/Lib/_pyrepl/unix_console.py

Lines 540 to 546 in cd52172

	e = Event("key", "", b"")
	while not self.event_queue.empty():
	e2 = self.event_queue.get()
	e.data += e2.data
	e.raw += e.raw

We can just fix the typo: e.raw += e.raw becomes e.raw += e2.raw. It's feasible to add a test for this.

But Event.raw isn't read anywhere and is untested. The 3 callers of getpending() only use ev.data or pending.data. The .raw field is only written to, never consumed. So we can simply remove it from Event and adapt some lines (summary below written with Claude Code).

Please let me know which solution is preferred and I can write a trivial PR to implement it.

---

Since .raw is never read by any consumer, it's dead code. This removes the field and all assignments to it:

console.py — Remove raw from the dataclass:

@dataclass
class Event:
    evt: str
    data: str

unix_console.py — Remove all raw-related code in both getpending variants:

• Line 540: Event("key", "", b"") → Event("key", "")
• Line 545: delete e.raw += e.raw
• Line 549-550: raw = ... / data = str(raw, ...) → data = str(self.__read(amount), ...)
• Line 552: delete e.raw += raw
• Same changes for lines 564, 569, 572-575

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Linked PRs

• gh-145886: Fix e.raw += e.raw typo in UnixConsole.getpending #145888
• gh-145886: remove unused Event.raw field from _pyrepl #146097

[chris-eibl]

Since .raw is never read by any consumer, it's dead code. This removes the field and all assignments to it:

Yeah, I already did so for Windows in adb89ba and left a smiley on that typo #132440 (comment).

Tbh, I think it is time to remove .raw altogether instead of fixing the wrong-but-dead code path.

The only thing I am concerned is the side effect of flush_buf in

cpython/Lib/_pyrepl/base_eventqueue.py

Line 90 in 79b91e7

self.insert(Event('key', k, bytes(self.flush_buf())))

and

cpython/Lib/_pyrepl/base_eventqueue.py

Line 109 in 79b91e7

self.insert(Event('key', decoded, bytes(self.flush_buf())))

but I think, we can just simplify

def flush_buf(self):
    """
    Flushes the buffer.
    """
    self.buf = bytearray()

since the raw member is nowhere needed AFAICT ...

[chris-eibl]

Please let me know which solution is preferred and I can write a trivial PR to implement it.

@wavebyrd please don't open a PR when

• the OP already stated they're up for it
• and furthermore there even isn't a decision, yet

[HCYT]

Hi, I opened a PR for this: #146097

I went with removing the Event.raw field entirely since it's not read anywhere, instead of just fixing the typo. Also cleaned up the tests.

@chris-eibl would appreciate if you can take a look when you have time, thanks!

[picnixz]

We did not decide whether to remove the field or not. Please do not open PRs

[picnixz]

I think we need to keep the raw data. I might be necessary in the future to handle special key sequences that are not recognized. And if we were to expose the repl publicly it would also be a way for custom handlers to handle the event.

So I personally prefer fixing the typo rather than removing the field.

[picnixz]

OTOH the Windows console has no more raw buffer. What was the rationale for removing it?