I don't think that we need to support compressing/decompressing using
the standard input/output.

2013/3/20 Brandon Craig Rhodes <report@bugs.python.org>:
>
> Brandon Craig Rhodes added the comment:
>
> 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.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue13477>
> _______________________________________