Hello,
this posting isn't about asking for a technical solution. My intention
is to understand the design decision Python's core developers made in
context of that topic.
The logging module write everything to stderr no matter which logging
level is used.
The argparse module does it more differentiated. If arguments are
mandatory but none are given then argparse produce a short version of
the usage info; on stderr. If the user request the usage info via "-h"
it goes to stdout. This is the behavior I would expect.
Why does logging behave different? DEBUG and INFO imho should go to
stdout not stderr.
Of course I could modify the handlers etc. to workaround this. But I
assume that there was something in mind of the Python developers when
they decided that.
My goal is not to divide between the use of print() or logging.info()
in my own code. This would mess up a lot.
On Jan 3, 2023, at 10:38 AM, c.buhtz@posteo.jp wrote:
Hello,
this posting isn't about asking for a technical solution. My intention
is to understand the design decision Python's core developers made in
context of that topic.
The logging module write everything to stderr no matter which logging
level is used.
The argparse module does it more differentiated. If arguments are
mandatory but none are given then argparse produce a short version of
the usage info; on stderr. If the user request the usage info via "-h"
it goes to stdout. This is the behavior I would expect.
Why does logging behave different? DEBUG and INFO imho should go to
stdout not stderr.
Of course I could modify the handlers etc. to workaround this. But I
assume that there was something in mind of the Python developers when
they decided that.
My goal is not to divide between the use of print() or logging.info()
in my own code. This would mess up a lot.
--
https://mail.python.org/mailman/listinfo/python-list
Hello,
this posting isn't about asking for a technical solution. My intention
is to understand the design decision Python's core developers made in
context of that topic.
The logging module write everything to stderr no matter which logging
level is used.
The argparse module does it more differentiated. If arguments are
mandatory but none are given then argparse produce a short version of
the usage info; on stderr. If the user request the usage info via "-h"
it goes to stdout. This is the behavior I would expect.
Why does logging behave different? DEBUG and INFO imho should go to
stdout not stderr.
Of course I could modify the handlers etc. to workaround this. But I
assume that there was something in mind of the Python developers when
they decided that.
My goal is not to divide between the use of print() or logging.info()
in my own code. This would mess up a lot.
On 1/3/2023 10:35 AM, c.buhtz@posteo.jp wrote:
Also, I think it would be confusing to sometimes have logging output go
to stdout and other times go to stderr.
import logging
import sys
logging.getLogger().addHandler( logging.StreamHandler( sys.stdout )) >logging.error( 'example' )
Hello,
this posting isn't about asking for a technical solution. My intention
is to understand the design decision Python's core developers made in
context of that topic.
The logging module write everything to stderr no matter which logging
level is used.
The argparse module does it more differentiated. If arguments are
mandatory but none are given then argparse produce a short version of
the usage info; on stderr. If the user request the usage info via "-h"
it goes to stdout. This is the behavior I would expect.
Why does logging behave different? DEBUG and INFO imho should go to
stdout not stderr.
Of course I could modify the handlers etc. to workaround this. But I
assume that there was something in mind of the Python developers when
they decided that.
My goal is not to divide between the use of print() or logging.info()
in my own code. This would mess up a lot.
If the user request the usage info via "-h" it goes to stdout.
Why does logging behave different? DEBUG and INFO imho should go to
stdout not stderr.
The purpose of stderr is to display status messages, logging and error messages, even user prompts, and not mess up the program's actual
output. This is important on a *nix system where you might be piping
the output of one program into the input of another.
Thomas Passin <list1@tompassin.net> writes:
On 1/3/2023 10:35 AM, c.buhtz@posteo.jp wrote:
Also, I think it would be confusing to sometimes have logging output go
to stdout and other times go to stderr.
In UNIX, the output of a program can be redirected,
so error messages written to the output might get appended
to some result file and might not be seen by the user.
Therefore, UNIX and C provide the unbuffered "stderr" stream
that can be redirected separately.
The following example shows how logging might write to stdout.
import logging
import sys
logging.getLogger().addHandler( logging.StreamHandler( sys.stdout )) logging.error( 'example' )
If the user request the usage info via "-h" it goes to stdout.
Why does logging behave different? DEBUG and INFO imho should go to
stdout not stderr.
If sys.stdout is a tty, it typically flushes on newline. e. g.
But I don't want to make all log levels go to stdout. Just DEBUG and
INFO.
logging.getLogger().addHandler( logging.StreamHandler( sys.stdout ))
Am 03.01.2023 17:51 schrieb ram@zedat.fu-berlin.de:
logging.getLogger().addHandler( logging.StreamHandler( sys.stdout ))
But I don't want to make all log levels go to stdout. Just DEBUG and
INFO. But this would be a workaround.
The main question here is why does Python deciecded to make all logs go
to stderr?
Maybe I totally misunderstood the intention of logging.info()?! Isn't
this the "usual applicaton output"?
If not, what messages should go into logging.info()? Can you name me
some examples?
this posting isn't about asking for a technical solution. My
intention is to understand the design decision Python's core developers made in
context of that topic.
The logging module write everything to stderr no matter which logging
level is used.
The argparse module does it more differentiated. If arguments are
mandatory but none are given then argparse produce a short version of
the usage info; on stderr. If the user request the usage info via "-h"
it goes to stdout. This is the behavior I would expect.
Why does logging behave different? DEBUG and INFO imho should go to
stdout not stderr.
Of course I could modify the handlers etc. to workaround this. But I
assume that there was something in mind of the Python developers when
they decided that.
My goal is not to divide between the use of print() or logging.info()
in my own code. This would mess up a lot.
MRAB <python@mrabarnett.plus.com> writes:
[...]
The purpose of stderr is to display status messages, logging and error
messages, even user prompts, and not mess up the program's actual
output. This is important on a *nix system where you might be piping
the output of one program into the input of another.
I would expect user prompts to be written to stdout, or perhaps to some system-specific stream like the current tty, not to stderr. If a
program has user prompts, it probably doesn't make sense to pipe its
output to the input of another.
Maybe I totally misunderstood the intention of logging.info()?! Isn't
this the "usual applicaton output"?
The main question here is why does Python deciecded to make all logs
go to stderr?
Maybe I totally misunderstood the intention of logging.info()?! Isn't
this the "usual applicaton output"?
If not, what messages should go into logging.info()? Can you name me some examples?
On 1/3/23 11:45, Keith Thompson wrote:
MRAB <python@mrabarnett.plus.com> writes:
[...]
The purpose of stderr is to display status messages, logging and error
messages, even user prompts, and not mess up the program's actual
output. This is important on a *nix system where you might be piping
the output of one program into the input of another.
I would expect user prompts to be written to stdout, or perhaps to some system-specific stream like the current tty, not to stderr. If a
program has user prompts, it probably doesn't make sense to pipe its
output to the input of another.
I can't think of a specific example, but I know I have piped the output
of a program while at the same time interacting with a prompt on stderr.
A rare thing, though.
Maybe some day an interface and shell syntax will be developed to
interact with an arbitrary number of standard streams. Current piping
syntax really only works well with one stream and even trying to use
stderr and stdout with pipes and filters in a shell is awkward.
On 1/3/23 11:45, Keith Thompson wrote:
MRAB <python@mrabarnett.plus.com> writes:
[...]
The purpose of stderr is to display status messages, logging and error
messages, even user prompts, and not mess up the program's actual
output. This is important on a *nix system where you might be piping
the output of one program into the input of another.
I would expect user prompts to be written to stdout, or perhaps to some
system-specific stream like the current tty, not to stderr. If a
program has user prompts, it probably doesn't make sense to pipe its
output to the input of another.
I can't think of a specific example, but I know I have piped the output
of a program while at the same time interacting with a prompt on stderr.
A rare thing, though.
On 2023-01-03, Michael Torrie <torriem@gmail.com> wrote:
On 1/3/23 11:45, Keith Thompson wrote:
MRAB <python@mrabarnett.plus.com> writes:
[...]
The purpose of stderr is to display status messages, logging and error >>> messages, even user prompts, and not mess up the program's actual
output. This is important on a *nix system where you might be piping
the output of one program into the input of another.
I would expect user prompts to be written to stdout, or perhaps to some
system-specific stream like the current tty, not to stderr. If a
program has user prompts, it probably doesn't make sense to pipe its
output to the input of another.
I can't think of a specific example, but I know I have piped the output
of a program while at the same time interacting with a prompt on stderr.
A rare thing, though.
Programs that ask for passwords often do it by reading/writing to fd 0
or /dev/tty so that stdout is unaffected.
c.buhtz@posteo.jp writes:
But I don't want to make all log levels go to stdout. Just DEBUG and
INFO.
The following was stripped down from something some guy
posted on a web site, maybe it was "rkachach".
writing the FD is the same as using stdout
use /dev/tty to reach for the console directly.
On 1/3/23, Chris Angelico <rosuav@gmail.com> wrote:
writing the FD is the same as using stdout
Except stdout may be buffered. One should probably flush the buffer
before each raw write to the file descriptor.
use /dev/tty to reach for the console directly.
On Windows, open "CON" (read or write), "CONIN$" (read-write), or
"CONOUT$" (read-write). Or use the more explicit device paths
"\\.\CON", "\\.\CONIN$", and "\\.\CONOUT$". If the process has no
console, one can call WinAPI AllocConsole() or
AttachConsole(process_id) to obtain one.
On Wed, 4 Jan 2023 at 09:52, Grant Edwards <grant.b.edwards@gmail.com> wrote:
I can't think of a specific example, but I know I have piped the output
of a program while at the same time interacting with a prompt on stderr. >>> A rare thing, though.
Programs that ask for passwords often do it by reading/writing to
fd 0 or /dev/tty so that stdout is unaffected.
Reading/writing the FD is the same as using stdout.
(technically you'd write to fd 1 and read from fd 0),
but yes, can use /dev/tty to reach for the console directly.
On 2023-01-04, Chris Angelico <rosuav@gmail.com> wrote:
On Wed, 4 Jan 2023 at 09:52, Grant Edwards <grant.b.edwards@gmail.com> wrote:
I can't think of a specific example, but I know I have piped the output >>> of a program while at the same time interacting with a prompt on stderr. >>> A rare thing, though.
Programs that ask for passwords often do it by reading/writing to
fd 0 or /dev/tty so that stdout is unaffected.
Reading/writing the FD is the same as using stdout.
No, stdout is fd 1.
(technically you'd write to fd 1 and read from fd 0),
No, the whole point is _not_ to write to stdout (which would corrupt
the program's output). The way I remember it was that you wrote the
prompt to fd 0, and then read the password from fd 0. That way it
worked even when fd 1 (stdout) was redirected. It still failed if
stdin was redirected...
but yes, can use /dev/tty to reach for the console directly.
That's definitely a better option, but I'm pretty sure I've seen
multiple examples over the decades where fd 0 was used instead. Was
/dev/tty a "recent" enough invention that I would have seen
application code that was written before it existed? Or maybe I was
just looking at code written by people who weren't aware of /dev/tty?
On 1/3/23, Chris Angelico <rosuav@gmail.com> wrote:
FDs can also be buffered. If it's buffering you want to avoid, don't
mess around with exactly which one you're writing to, just flush.
I meant to flush a C FILE stream or Python file before writing
directly to the file descriptor, in order to avoid out-of-sequence and interlaced writes that make no sense. Any OS buffering on the file
doesn't matter in this regard.
That's definitely a better option, but I'm pretty sure I've seen
multiple examples over the decades where fd 0 was used instead. Was
/dev/tty a "recent" enough invention that I would have seen
application code that was written before it existed? Or maybe I was
just looking at code written by people who weren't aware of /dev/tty?
No, the whole point is _not_ to write to stdout (which would corrupt
the program's output). The way I remember it was that you wrote the
prompt to fd 0, and then read the password from fd 0. That way it
worked even when fd 1 (stdout) was redirected. It still failed if
stdin was redirected...
FDs can also be buffered. If it's buffering you want to avoid, don't
mess around with exactly which one you're writing to, just flush.
Dealing with stdout / stderr is bash is just syntax. I don’t always remember it off the top of my head but … stackoverflow.com.
On Linux at least it’s possible to pipe to arbitrary streams, it
seems. The following uses bash to write “Hi” to the file “third” opened by Python. I determined the file was 5 empirically.
import os
import subprocess
command= 'echo Hi >/dev/fd/5'
fd = os.open("third",os.O_WRONLY|os.O_CREAT)
os.set_inheritable(fd,True)
subprocess.run(('/usr/bin/bash','-c',command),close_fds=False)
I've known some systems to have a trigger of "reading on FD 0 flushes
FD 1"
Reading/writing the FD is the same as using stdout (technically you'd
write to fd 1 and read from fd 0), but yes, can use /dev/tty to reach
for the console directly.
On Wed, 4 Jan 2023 at 15:11, Eryk Sun <eryksun@gmail.com> wrote:
On 1/3/23, Chris Angelico <rosuav@gmail.com> wrote:
writing the FD is the same as using stdout
Except stdout may be buffered.
One should probably flush the buffer
before each raw write to the file descriptor.
FDs can also be buffered.
If it's buffering you want to avoid, don't
mess around with exactly which one you're writing to, just flush.
The main question here is why does Python deciecded to make all logs go to stderr?
Am 03.01.2023 17:51 schrieb ram@zedat.fu-berlin.de:
logging.getLogger().addHandler( logging.StreamHandler( sys.stdout ))
But I don't want to make all log levels go to stdout. Just DEBUG and
INFO. But this would be a workaround.
The main question here is why does Python deciecded to make all logs
go to stderr?
Maybe I totally misunderstood the intention of logging.info()?! Isn't
this the "usual applicaton output"?
If not, what messages should go into logging.info()? Can you name me
some examples?
The logging module write everything to stderr no matter which logging
level is used.
Am 03.01.2023 17:51 schrieb ram@zedat.fu-berlin.de:
logging.getLogger().addHandler( logging.StreamHandler( sys.stdout ))
But I don't want to make all log levels go to stdout. Just DEBUG and
INFO. But this would be a workaround.
The main question here is why does Python deciecded to make all logs
go to stderr?
Maybe I totally misunderstood the intention of logging.info()?! Isn't
this the "usual applicaton output"?
If not, what messages should go into logging.info()? Can you name me
some examples?
On 03/01/2023 21:24, c.buhtz@posteo.jp wrote:
Am 03.01.2023 17:51 schrieb ram@zedat.fu-berlin.de:
logging.getLogger().addHandler( logging.StreamHandler( sys.stdout ))
But I don't want to make all log levels go to stdout. Just DEBUG and
INFO. But this would be a workaround.
The main question here is why does Python deciecded to make all logs
go to stderr?
Maybe I totally misunderstood the intention of logging.info()?! Isn't
this the "usual applicaton output"?
If not, what messages should go into logging.info()? Can you name me
some examples?
Example:
write an app that prints the contents of a file.
The application output is the contents of the file.
The logging might be this when all is working:
INFO About to open <filename>
INFO Wrote <number> bytes from <filename>
The logging might be this when there is a problem:
INFO About to open <filename>
ERROR Failed to open <filename> - <reason>
Does that help?
On 1/3/2023 10:35 AM, c.buhtz@posteo.jp wrote:
The logging module write everything to stderr no matter which logging
level is used.
The OP wrote this, but it's not so by default.
On 2023-01-04 12:32:40 -0500, Thomas Passin wrote:
On 1/3/2023 10:35 AM, c.buhtz@posteo.jp wrote:
The logging module write everything to stderr no matter which logging
level is used.
The OP wrote this, but it's not so by default.
By default it is - sort of.
That is all log messages go to stderr, but not all log levels are
logged.
The logging system is so configurable that a user could set a different destination for each level of logging. So it seems that the O.P.'s original question about why the package's developers choose stderr for all levels can be answered: "They didn't".
On 2023-01-05 08:31:40 -0500, Thomas Passin wrote:
The logging system is so configurable that a user could set a different
destination for each level of logging. So it seems that the O.P.'s original >> question about why the package's developers choose stderr for all levels can >> be answered: "They didn't".
Which is almost exactly what I wrote in <20230104162154.uzljittbs6xwtx6y@hjp.at> ;-)
On 2023-01-05, Thomas Passin <list1@tompassin.net> wrote:
The logging system is so configurable that...
I find it almost impossible to use unless I copy a working example I
find somewhere. ;)
I'm not at all surprised that the OP didn't understand how it
works. I've been writing Python programs for over 20 years, and it's
beyond me.
The logging system is so configurable that...
The logging system is so configurable that...
I find it almost impossible to use unless I copy a working example I
find somewhere. ;)
logging.basicConfig()
logging.info(“Nice to know”)
logging.debug(“Details for when things are funky”) logging.warn(“Trouble is brewing”)
logging.basicConfig()
logging.info(“Nice to know”)
logging.debug(“Details for when things are funky”) logging.warn(“Trouble is brewing”)
<stdin>:1: DeprecationWarning: The 'warn' function is deprecated, useimport logging
logging.basicConfig()
logging.info("Nice to know")
logging.debug("Details for when things are funky")
logging.warn("Trouble is brewing")
INFO:root:So should thislogging.basicConfig(level=logging.DEBUG)
logging.info('So should this')
From: Python-list <python-list-bounces+gweatherby=uchc.edu@python.org> on behalf of Grant Edwards <grant.b.edwards@gmail.com>
Date: Thursday, January 5, 2023 at 3:31 PM
To: python-list@python.org <python-list@python.org>
Subject: Re: What should go to stdout/stderr and why Python logging write everything to stderr?
*** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. ***
On 2023-01-05, Thomas Passin <list1@tompassin.net> wrote:
The logging system is so configurable that...
I find it almost impossible to use unless I copy a working example I
find somewhere. ;)
I'm not at all surprised that the OP didn't understand how it
works. I've been writing Python programs for over 20 years, and it's
beyond me.
--
Grant
-- https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!l6vSXQFKppEuLS0R5gYeLYaiHyVFfs2Rapqm1oPGEtvnZ5ivQyApZcnJyNTnnH9zEVY80ajNb-HfYkNwgw8fMtsnlSOT$<https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!l6vSXQFKppEuLS0R5gYeLYaiHyVFfs2Rapqm1oPGEtvnZ5ivQyApZcnJyNTnnH9zEVY80ajNb-HfYkNwgw8fMtsnlSOT$>
You often can replace threads in tkinter by coroutines using
asyncio when you write a replacement for the mainloop of
tkinter that uses asyncio. Now, try to read only the official
documentation of asyncio and tkinter and figure out only from
this how to get such a program to work!
On 2023-01-05, Thomas Passin <list1@tompassin.net> wrote:
The logging system is so configurable that...
I find it almost impossible to use unless I copy a working example I
find somewhere. ;)
I'm not at all surprised that the OP didn't understand how it
works.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 34:47:41 |
| Calls: | 10,391 |
| Calls today: | 2 |
| Files: | 14,064 |
| Messages: | 6,417,140 |