Larry Hastings <report@bugs.python.org> writes:

> Huh.  tar *can* infer it from the data itself.  On the other hand, it
> chooses explicitly not to.  I guess "tar" knows explicit is better
> than implicit too ;-)

I am told that the refusal of "tar" to introspect the data is because:

(a) Tar runs "gunzip -c" (for example) as an external program; it does
not actually compile against libz.

(b) Streams in UNIX cannot be rewound.  Tar cannot look at the first
block of an input pipe and then "put the block back" so that the same
input can be fed directly to "gunzip" as its input.

(c) Given (a) and (b), tar could only support data introspection of
input from a pipe if it were willing to be a pass-through that, after
reading and introspecting the first block, then fired up "gunzip" and
sent ALL of the blocks through.  Which would require multiprocessing,
threading, or async I/O so that tar could both read and write, which
would make tar more complicated.

(d) Therefore, tar refuses to even look.

Since Python does bundle compression in its standard library, it can
quite trivially step forward and actually do the data introspection that
tar insists on not doing; the first few bytes of a tar archive are quite
demonstrably different from the first bytes of a gzip stream, if I
recall.