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 differe
On 1/3/2023 10:35 AM, c.bu...@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 i
On 2023-01-03 15:35, c.bu...@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
> On Jan 3, 2023, at 10:38 AM, c.bu...@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 mat
Really doesn’t have much to do with Python and very much with standard streams,
which go back as far as the 1950s.
https://en.wikipedia.org/wiki/Standard_streams
When a user types -h / --help to a Python argparse script, the output of the
script is the help message. The standard behavior is to
On 1/3/23, c.bu...@posteo.jp wrote:
>
> If the user request the usage info via "-h" it goes to stdout.
The standard file for application output is sys.stdout. Note that
sys.stdout may be buffered, particularly if it isn't a tty. When a
file is buffered, writes are aggregated and only written to t
MRAB 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 ex
On 1/3/2023 11:51 AM, Stefan Ram wrote:
Thomas Passin writes:
On 1/3/2023 10:35 AM, c.bu...@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 messa
If sys.stdout is a tty, it typically flushes on newline. e. g.
!/usr/bin/env python3
import time
import sys
print("No flush",end='',file=sys.stdout)
time.sleep(2)
print("flushed",file=sys.stdout)
time.sleep(5)
will print the “flushed” 5 seconds before the script ends
From: Python-list on
behal
On 1/3/23, Weatherby,Gerard wrote:
> If sys.stdout is a tty, it typically flushes on newline. e. g.
Sorry if I wasn't clear. Yes, a tty file will be buffered, but it's
line buffering, which isn't an issue as long as lines are written to
stdout. I was referring to full buffering of pipe and disk f
Am 03.01.2023 17:51 schrieb r...@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
On Jan 3, 2023, at 10:38 AM, c.bu...@posteo.jp wrote:
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 i
On Wed, 4 Jan 2023 at 08:25, wrote:
>
> Am 03.01.2023 17:51 schrieb r...@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.
But why are DEBUG
On 1/3/23 11:45, Keith Thompson wrote:
> MRAB 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
On 2023-01-03 at 21:24:20 +,
c.bu...@posteo.jp wrote:
> The main question here is why does Python deciecded to make all logs
> go to stderr?
It makes sense to send all logging to one destination, and stderr is
that place.
> Maybe I totally misunderstood the intention of logging.info()?! Isn'
On Wed, 4 Jan 2023 at 09:17, Michael Torrie wrote:
>
> On 1/3/23 11:45, Keith Thompson wrote:
> > MRAB 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 importan
On 2023-01-03, Michael Torrie wrote:
> On 1/3/23 11:45, Keith Thompson wrote:
>> MRAB 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 w
On Wed, 4 Jan 2023 at 09:52, Grant Edwards wrote:
>
> On 2023-01-03, Michael Torrie wrote:
> > On 1/3/23 11:45, Keith Thompson wrote:
> >> MRAB writes:
> >> [...]
> >>> The purpose of stderr is to display status messages, logging and error
> >>> messages, even user prompts, and not mess up the p
On Wed, 4 Jan 2023 at 10:28, Stefan Ram wrote:
>
> c.bu...@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".
Yet another shining exampl
On 1/3/23, Chris Angelico 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$" (r
I was wondering if I could be in your group
--
https://mail.python.org/mailman/listinfo/python-list
I am trying to wrap my head around how one goes about working with and
editing xml elements since it feels more complicated than it seems it
should be.. Just to get some feedback on how others might approach it
and see if I am missing anything obvious that I haven't discovered yet,
since maybe
On 2023-01-04, Chris Angelico wrote:
> On Wed, 4 Jan 2023 at 09:52, Grant Edwards 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 fo
On Wed, 4 Jan 2023 at 15:11, Eryk Sun wrote:
>
> On 1/3/23, Chris Angelico 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
On Wed, 4 Jan 2023 at 16:21, Grant Edwards wrote:
>
> On 2023-01-04, Chris Angelico wrote:
> > On Wed, 4 Jan 2023 at 09:52, Grant Edwards
> > 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 pr
On 1/3/23, Grant Edwards wrote:
>
> 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
On 1/3/23, Chris Angelico 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-se
On Wed, 4 Jan 2023 at 17:26, Eryk Sun wrote:
>
> On 1/3/23, Chris Angelico 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
>
28 matches
Mail list logo
