Brandon Craig Rhodes added the comment: Larry Hastings <rep...@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 <rep...@bugs.python.org> <http://bugs.python.org/issue13477> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com