Where in the specs are these decided?

I prefer that we keep per-instance caches instead of per-class caches, even for 0.

Hello, sorry but there seems no availableTarFile object for_create_gnu_long_header to cache the querying result:

• aTarFile instance does have cache members ofself._unames: Dict[uid, uname]
• however, across the calling stack ofTarInfo.tobuf() -> TarInfo.create_gnu_header() -> TarInfo._create_gnu_long_header(), there's noTarFile argument.

If we add aTarFile intoTarInfo.tobuf(...), then this PR may break existing subclasses ofTarInfo. Is it indeed necessary?

Um, to make this cache safe for the free-threading version of CPython, I've replaced the_unames = {} with_name_uid0 = None (and_gnames = {} with_name_gid0 = None).

Do you developers have any suggestions?

@picnixz Any idea about where to put the cache object?

This will need to be moved in whatsnew/3.15.rst now

What I meant before is: why using a class variable? the issue is that once we deduceuid=0, we're stuck with it for theentire Python process.

EDIT: I didn't see you comment, my bad. Then we need to think of another solution because storing them inTarFile feels wrong. What we can do is to add a private attribute in TarInfo and populate it from TarFile. When writing, if the attribute is not set, we populate it eagerly (and thus subclasses of TarInfowill be slower but they won't be broken). Or instead, we can even just dump them with the legacy way (namely without aligning with GNU Tar). Only default TarFile and TarInfo objects will be having this new feature.

More generally, we should be able to set cached contextual information on TarInfo objects coming from a TarFile.