[ python-Bugs-1235266 ] debug info file descriptor of tarfile is inconsistent

[SourceForge.net]

Bugs item #1235266, was opened at 2005-07-09 16:24
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: George Yoshida (quiver)
>Assigned to: Georg Brandl (gbrandl)
Summary: debug info file descriptor of tarfile is inconsistent

Initial Comment:
"7.19.1 TarFile Objects" says
  The messages are written to sys.stdout.
but they are actually written to sys.stderr ::

  def _dbg(self, level, msg):
      """Write debugging output to sys.stderr.
      """
      if level <= self.debug:
          print >> sys.stderr, msg

There are 2 options:
(a) change document from stdout to stderr.
(b) rewrite the code to use stdout.

Given this is debug messages and most other modules 
use stdout for debug printing(gc is one of the few 
exceptions?), I'm +1 on (b).

[*] http://docs.python.org/lib/tarfile-objects.html


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-12 07:29

Message:
Logged In: YES 
user_id=1188172

Okay. Checked in Doc/lib/libtarfile.tex r1.10, r1.7.2.1.

And when will be some day?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-07-12 03:06

Message:
Logged In: YES 
user_id=80475

Just change the docs to match the actual behavior.  Let's
leave the implementation alone.

There is no great need to have tarfile's implementation
match zipfile.  Someday, all of the modules will generate
messages via the logging module and you'll trivially be able
to mask them or redirect them in a consistent manner.

----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-11 06:19

Message:
Logged In: YES 
user_id=1188172

Attaching patches for both tarfile and zipfile. For tarfile,
the docs are changed to stderr, for zipfile, both docs and
implementation are changed to stderr.

Since I don't assume that someone actually uses the debug
info in some automated way, I think we can correct this in 2.5.

Raymond, please review.

----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2005-07-10 16:26

Message:
Logged In: YES 
user_id=671362

OK. I tested some GNU compression/decompression tools 
and comfirmed that they write debugging messages
(displayed in verbose mode(-v)) to stderr.

Now I'm leaning toward Reinhold's idea.

> What about zipfile? 
> Should we print debug info to stderr there, too?

Maybe yes.  I'd be happy to volunteer for that patch.


----------------------------------------------------------------------

Comment By: Lars Gustäbel (gustaebel)
Date: 2005-07-10 08:00

Message:
Logged In: YES 
user_id=642936

This is a documentation error. Debug messages must go to
stderr because that's what stderr is for. Think of a script
that writes a tar archive to stdout for use in a unix shell
pipeline. If debug messages went to stdout, too, it would
produce unusable output, because archive data and debug
messages would be mixed.


----------------------------------------------------------------------

Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-09 17:04

Message:
Logged In: YES 
user_id=1188172

The documentation seems to be borrowed from zipfile, where
the statement is true: debug info is written to stdout.

I'm in favour of changing the docs to stderr for tarfile.
What about zipfile? Should we print debug info to stderr
there, too?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1235266&group_id=5470