Choose the ZIP interface from the kind of answer your caller needs. A list of names, metadata for a supplied name, and a particular member entry are different results. This reference helps make that choice; the companion article owns the duplicate diagnosis and reading procedure.
Choose between a name list and an entry list
Use namelist() when the output is simply an inventory of member names. A menu that displays names, or a quick question about which spellings appear, may need no more. If the number of occurrences matters, preserve the list while analyzing it. Converting it to a set answers a different question: which names are distinct.
Use infolist() when the caller must select an entry. Its result contains a ZipInfo object for each member, in archive entry order for an existing ZIP file. That makes it suitable for an interface that must distinguish two rows bearing the same displayed name. Give each row a separate selection value instead of treating the label as its identifier.
A practical design question is what happens after the user selects a row. If the next step only displays a name, a name inventory may suffice. If the next step inspects metadata or reads that particular occurrence, begin with entry objects and carry the selected object forward. The companion article shows the counting procedure for archives whose names repeat.
Sources: Python documentation: zipfile — ZipFile objects — ZipFile.namelist(), Python documentation: zipfile — ZipFile objects — ZipFile.infolist()
Use getinfo() for a supplied name
Use getinfo(name) when a caller already has a name and wants member metadata. An absent name raises KeyError, so decide whether absence is an error in your application or an expected result that should receive its own message. This is a lookup, not an inventory operation.
Before using it, ask whether the caller's name is enough to specify the intended entry. If the application accepts archives with repeated names and must choose a particular occurrence, collect entry objects instead. Do not promise that a name-only lookup selects a particular duplicate: the documented description does not give a rule for that choice.
For example, a configuration that names one expected file can reasonably request its metadata by name when your application has established that the name is unambiguous. A forensic inspection screen has a different requirement: it must let the reader distinguish occurrences. Make that requirement explicit at the boundary where the name enters your code.
Sources: Python documentation: zipfile — ZipFile objects — ZipFile.getinfo()
Carry ZipInfo into the reading method
A ZipInfo object represents one archive member. After an entry is selected, pass that object to open() if the caller needs a binary stream, or to read() if it wants bytes returned as a single result. Both methods accept an object as well as a name. This lets the selection survive the move from an inventory screen to a content operation.
Choose between the two reading methods according to how the caller will consume the data. A parser that accepts a file-like input can work with the object from open(); code that needs the entire byte value can request read(). If you only plan to report metadata, neither content method belongs in that path.
Keep the selected object associated with its displayed row for as long as the archive is open. Avoid reconstructing the selection from its filename later, since the display label may be shared. If the intended choice is “all occurrences,” use the entry-by-entry procedure in the companion article instead of adding a hidden first-or-last rule to the interface.
Sources: Python documentation: zipfile — ZipInfo objects, Python documentation: zipfile — ZipFile objects — ZipFile.open(), Python documentation: zipfile — ZipFile objects — ZipFile.read()
Primary sources checked: 2026-10-22. Prepared with AI assistance and a separate evidence review. This is documentation-based guidance, not a hands-on test or performance benchmark.
댓글 없음:
댓글 쓰기