Tidy and optimize `zipfile` module

Feature or enhancement

Proposal:

Tidy and optimize zipfile module internal pipelines

This issue serves as a tracking umbrella to modernize and optimize zipfile's internal data-handling pipelines—specifically targeting dead/suboptimal code cleanup, memory allocation reduction via memoryview/bytearray, and structural simplification without altering public APIs.

Task 1: Replace _Extra class with a ZipFile._strip_extra_fields() static method

The _Extra class is over-engineered for its active responsibilities. Its only operational usage in the entire module is its strip() method, called exclusively by ZipFile._write_end_record() to provide the stripping logic for ZIP64 fields.

The context-dependent nature of extra fields also makes it difficult to be reused by _decodeExtra() or other methods efficiently. Additionally, its split() classmethod explicitly calls _Extra directly rather than utilizing cls, which introduces an unneeded hardcoded class coupling that hinders clean extensibility.

Proposed Vector

Remove the _Extra class entirely and reimplement its stripping logic as a private static method _strip_extra_fields() that processes a bytearray inside ZipFile, positioned directly beneath its caller. This eliminates dead and suboptimal code, achieves clean encapsulation and code locality, and improves performance by avoiding temporary class allocations.

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

#134999

Linked PRs

• gh-152141

Beginnen Sie mit dem Lesen der Klasse _Extra des zipfile-Moduls und von ZipFile._write_end_record(); dies sind die spezifischen Codepfade, die im Vorschlag genannt werden. Sehen Sie sich vor Beginn den verknüpften PR gh-152141 an; als abgeschlossen gilt die Arbeit, wenn die gezielte Verwendung von _Extra entfernt, die öffentlichen APIs beibehalten und das Verhalten zum Entfernen von ZIP64-Extra-Feldern erhalten wurde.