> On 7 Jul 2024, at 23:21, Barry via Python-list wrote:
>
>
>
>> On 7 Jul 2024, at 22:09, Tomas Ukkonen via Python-list
>> wrote:
>>
>>Py_Initialize();
>
> You also need to tell python to init threading.
I'm in front of my dev machine now and checking up on threading.
There is no
Am 07.11.23 um 20:10 schrieb MRAB via Python-list:
On 2023-11-07 18:30, dn via Python-list wrote:
On 08/11/2023 06.47, Egon Frerich via Python-list wrote:
I've no idea why this happens. In a module there are lists and
definitions:
...
["%s%s%s " % (i[fCONV_AUSRICHTG], i[fLG
On 8/11/23 8:10 am, MRAB wrote:
Something to do with how scoping is implemented in comprehensions?
Yes, together with the way class scopes work during class construction.
Behind the scenes, the body of a listcomp happens to be implemented
as a nested function.
Usually you don't notice this,
On 2023-11-07 20:56, Thomas Passin via Python-list wrote:
On 11/7/2023 3:29 PM, MRAB via Python-list wrote:
On 2023-11-07 19:20, Jim Schwartz via Python-list wrote:
Where do you define fCONV_AUSRICHTG? It must be initialized or defined
somewhere. Did you leave out a statement from the python 2
. A simplified example:
>>> S1 = 'string 1'
>>> S2 = 'string 2'
>>> (fS1, fS2) = list(range(2))
>>> fS1
0
>>>
>>> fS2
1
On Nov 7, 2023, at 1:06 PM, Thomas Passin via Python-list
wrote:
On 11/7/2023 12:47 PM, Egon Frerich via Python-
no idea why this happens. In a module there are lists and definitions:
Felder = [
# Name lg1 lg2 typ Ausrichtung Holen Prüfen Prüfvorg
["Jahr", 4, 5, "u", "", "right", "center"],
["Monat", 2, 5, "
n-list wrote:
>> I've no idea why this happens. In a module there are lists and definitions:
>> Felder = [
>> # Name lg1 lg2 typ Ausrichtung Holen Prüfen Prüfvorg
>> ["Jahr", 4, 5, "u", "", "right", "c
On 2023-11-07 18:30, dn via Python-list wrote:
On 08/11/2023 06.47, Egon Frerich via Python-list wrote:
I've no idea why this happens. In a module there are lists and definitions:
...
["%s%s%s " % (i[fCONV_AUSRICHTG], i[fLG2], i[fTYP]) for i in Felder])
File "/home/ego
On 11/7/2023 12:47 PM, Egon Frerich via Python-list wrote:
I've no idea why this happens. In a module there are lists and definitions:
Felder = [
# Name lg1 lg2 typ Ausrichtung Holen Prüfen Prüfvorg
["Jahr", 4, 5, "u", "", "righ
On 08/11/2023 06.47, Egon Frerich via Python-list wrote:
I've no idea why this happens. In a module there are lists and definitions:
...
["%s%s%s " % (i[fCONV_AUSRICHTG], i[fLG2], i[fTYP]) for i in Felder])
File "/home/egon/Entw/Geldspur/geldspur/gui/GUI_Konf
I've no idea why this happens. In a module there are lists and definitions:
Felder = [
# Name lg1 lg2 typ Ausrichtung Holen Prüfen Prüfvorg
["Jahr", 4, 5, "u", "", "right", "center"],
["Monat",
Thanks for all repliers:
@Tony & @Cameron, I do know related stuffs about the dunder methods, and your
explanation just make it to be more clear, thank you!
@Roel, you just caught everyone here, we do miss it even though we know it and
use it regularly!
@Clara
> its both, depending on how
Op 15/09/2023 om 15:05 schreef anthony.flury via Python-list:
Like all of the other methods you shouldn't ever need to
call them directly : these are called dunder methods and represent
functions and features which are called by other operators.
The only recommended way to call
On 15Sep2023 10:49, scruel tao wrote:
```python
class A:
... def __init__(self):
... pass
...
```
On many books and even the official documents, it seems that many authors prefer to call `__init__`
as a "method" rather than a "function".
The book PYTHON CRASH COURSE mentioned that "A
On Mon, 18 Sept 2023 at 13:49, anthony.flury via Python-list
wrote:
>
>
>
> To me __init__ is a method, but that is implemented internally as
> function associated to a class
>
What is a method, if it is not a function associated with a class?
ChrisA
--
attributes would be reset to whatever the __init__
sets them to - if you need to do that it might be better to have a reset
method.
Regards,
Tony
-- Original Message --
From: "scruel tao via Python-list"
To: "python-list@python.org"
Sent: Friday, 15 Sep, 23 At 11
On 15/09/2023 11:49, scruel tao via Python-list wrote:
> ```python
class A:
> ... def __init__(self):
> ... pass
> On many books and even the official documents, it seems that
> many authors prefer to call `__init__` as a "method" rather
> than a "function".
That' because in OOP
` A.__init__` tells that `__init__` is a
> function...
>
> I wonder how can I call `__init__` as? Consider the output above.
> Maybe both are OK? If you prefer or think that we must use one of the two,
> please explain the why, I really want to know, thanks!
> --
> https://mail
ells that `__init__` is a
> function...
I always call __init__ "the initializer." YMMV.
> I wonder how can I call `__init__` as? Consider the output above.
> Maybe both are OK? If you prefer or think that we must use one of the two,
> please explain the why, I really want
uot;function".
The book PYTHON CRASH COURSE mentioned that "A function that’s part of a class
is a method.", however, ` A.__init__` tells that `__init__` is a function...
I wonder how can I call `__init__` as? Consider the output above.
Maybe both are OK? If you prefer or think th
Alan Gauld wrote:
> On 31/08/2023 22:15, Chris Green via Python-list wrote:
>
> > class Gpiopin:
> >
> > def __init__(self, pin):
> > #
> > #
> > # scan through the GPIO chips to find the line/pin we want
> > #
> > for
On 31/08/2023 22:15, Chris Green via Python-list wrote:
> class Gpiopin:
>
> def __init__(self, pin):
> #
> #
> # scan through the GPIO chips to find the line/pin we want
> #
> for c in ['gpiochip0', 'gpiochip1',
line.name())
>
> def set(self):
> self.line.set_value(1)
>
> def clear(self):
> self.line.set_value(0)
>
>
> This is by no means the final code, the print() in the __init__() is
> just a diagnostic for example. However I really can't understand why I
>
_init__() is
just a diagnostic for example. However I really can't understand why I
see the following when I try it:-
>>> import ngp
>>> ngp.Gpiopin("P9_23")
Found: P9_23
Traceback (most recent call last):
File "", line 1, in
File "/h
Chris Green wrote:
[snip code and question]
Sorry folks, it was a caching problem, I wasn't running the code I
thought I was running! When I made sure I had cleared everything out
and tried again it all worked as I expected.
--
Chris Green
·
--
On Tuesday, May 30th, 2023 at 10:18 PM, Chris Angelico wrote:
> Yep, what you're seeing there is the namespace and nothing else. But
> if you mess with an actual builtin object, it'll be changed for the
> other interpreter too.
>
> > > > import ctypes
> > > > ctypes.cast(id(42),
On Wed, 31 May 2023 at 12:03, James Schaffler via Python-list
wrote:
>
> On Tuesday, May 30th, 2023 at 9:14 PM, Greg Ewing wrote:
> > Globals you create by executing code in the REPL have their own
> > namespace. But everything else is shared -- builtins, imported
> > Python modules, imported C
On Tuesday, May 30th, 2023 at 9:14 PM, Greg Ewing wrote:
> Globals you create by executing code in the REPL have their own
> namespace. But everything else is shared -- builtins, imported
> Python modules, imported C extension modules, etc. etc.
Thanks for the explanation. Could you elaborate on
On 29/05/23 8:10 am, James Schaffler wrote:
However, some minimal testing of InteractiveInterpreter leads me to believe
that the Interpreter object has its own view of local/global variables and
therefore shouldn't be able to affect the calling interpreter
Globals you create by executing
On Wed, 31 May 2023 at 08:16, Barry wrote:
> I don’t think it security but robustness that needs the subprocess.
>
> Also if your code use tk then it would conflict with idle’s use of tk.
>
From my memory, it's precisely this - it's much MUCH easier to allow
you to use Tk in your own program
iew of
> local/global variables and therefore shouldn't be able to affect the calling
> interpreter (please correct me if I'm wrong).
>
> So my question is a combination of "Why does IDLE use a subprocess?" and "Why
> is InteractiveInterpreter not secureuldenough?"
tself." However, some minimal testing of InteractiveInterpreter
leads me to believe that the Interpreter object has its own view of
local/global variables and therefore shouldn't be able to affect the calling
interpreter (please correct me if I'm wrong).
So my question is a combination o
of Peter J. Holzer
Date: Saturday, February 25, 2023 at 5:21 PM
To: python-list@python.org
Subject: Re: Why doesn't Python (error msg) tell me WHAT the actual (arg)
values are ?
On 2023-02-25 21:58:18 +, Weatherby,Gerard wrote:
> I only use asserts for things I know to be true.
Yeah, tha
On 2023-02-25 21:58:18 +, Weatherby,Gerard wrote:
> I only use asserts for things I know to be true.
Yeah, that's what assers are for. Or rather for things that you *think*
are true.
> In other words, a failing assert means I have a hole in my program
> logic.
Yes, if you include your
, February 25, 2023 at 9:22 AM
To: python-list@python.org
Subject: Re: Why doesn't Python (error msg) tell me WHAT the actual (arg)
values are ?
On 2023-02-25 09:10:06 -0500, Thomas Passin wrote:
> On 2/25/2023 1:13 AM, Peter J. Holzer wrote:
> > On 2023-02-24 18:19:52 -0500, Thomas Pas
On 2023-02-25 09:10:06 -0500, Thomas Passin wrote:
> On 2/25/2023 1:13 AM, Peter J. Holzer wrote:
> > On 2023-02-24 18:19:52 -0500, Thomas Passin wrote:
> > > Sometimes you can use a second parameter to assert if you know what kind
> > > of
> > > error to expect:
[...]
> > > With type errors,
On 2/25/2023 1:13 AM, Peter J. Holzer wrote:
On 2023-02-24 18:19:52 -0500, Thomas Passin wrote:
On 2/24/2023 2:47 PM, dn via Python-list wrote:
On 25/02/2023 08.12, Peter J. Holzer wrote:
On 2023-02-24 16:12:10 +1300, dn via Python-list wrote:
In some ways, providing this information seems
On 2023-02-24 18:19:52 -0500, Thomas Passin wrote:
> On 2/24/2023 2:47 PM, dn via Python-list wrote:
> > On 25/02/2023 08.12, Peter J. Holzer wrote:
> > > On 2023-02-24 16:12:10 +1300, dn via Python-list wrote:
> > > > In some ways, providing this information seems appropriate.
> > > > Curiously,
On 2/24/2023 2:47 PM, dn via Python-list wrote:
On 25/02/2023 08.12, Peter J. Holzer wrote:
On 2023-02-24 16:12:10 +1300, dn via Python-list wrote:
In some ways, providing this information seems appropriate.
Curiously, this
does not even occur during an assert exception - despite the
On 2023-02-25 08:47:00 +1300, dn via Python-list wrote:
> That said, have observed coders 'graduating' from other languages, making
> wider use of assert - assumed to be more data (value) sanity-checks than
> typing, but ...
>
> Do you use assert frequently?
Not very often, but I do use it.
On 25/02/2023 08.12, Peter J. Holzer wrote:
On 2023-02-24 16:12:10 +1300, dn via Python-list wrote:
In some ways, providing this information seems appropriate. Curiously, this
does not even occur during an assert exception - despite the
value/relationship being the whole point of using the
On 2023-02-24 16:12:10 +1300, dn via Python-list wrote:
> In some ways, providing this information seems appropriate. Curiously, this
> does not even occur during an assert exception - despite the
> value/relationship being the whole point of using the command!
>
> x = 1
> assert x == 2
>
On 2023-02-23 20:32:26 -0700, Michael Torrie wrote:
> On 2/23/23 01:08, Hen Hanna wrote:
> > Python VM is seeing an "int" object (123) (and telling me that)
> > ... so it should be easy to print that "int" object What does
> > Python VMknow ? and when does it know it ?
> It knows
r: can only concatenate str (not "int") to str
> >
> >
> > Why doesn't Python (error msg) do the obvious thing and tell me
> > WHAT the actual (offending, arg) values are ?
> >
> > In many cases, it'd help to know what string the var A had , when t
We have been supplying many possible reasons or consequences for why the
implementation of python does not do what the OP wants and even DEMANDS.
I am satisfied with knowing it was because they CHOSE NOT TO in some places
and maybe not in others. It is nice to see some possible reasons
On 2/23/23 01:08, Hen Hanna wrote:
> Python VM is seeing an "int" object (123) (and telling me that) ...
> so it should be easy to print that "int" object
> What does Python VMknow ? and when does it know it ?
It knows there is an object and its name and type. It knows this from
On 23/02/2023 09.05, Hen Hanna wrote:
> py bug.py
Traceback (most recent call last):
File "C:\Usenet\bug.py", line 5, in
print( a + 12 )
TypeError: can only concatenate str (not "int") to str
Why doesn't
wn.
-Original Message-
From: Python-list On
Behalf Of Rob Cliffe via Python-list
Sent: Wednesday, February 22, 2023 4:31 PM
To: python-list@python.org
Subject: Re: Why doesn't Python (error msg) tell me WHAT the actual (arg)
values are ?
On 22/02/2023 20:05, Hen Hanna wrote:
> P
On 22/02/2023 20:05, Hen Hanna wrote:
Python makes programming (debugging) so easy
I agree with that!
Rob Cliffe
--
https://mail.python.org/mailman/listinfo/python-list
na wrote:
> >>>> py bug.py
> >>> Traceback (most recent call last):
> >>> File "C:\Usenet\bug.py", line 5, in
> >>> print( a + 12 )
> >>> TypeError: can only concatenate str (not "int") to str
> >>>
&
>>> File "C:\Usenet\bug.py", line 5, in
>>> print( a + 12 )
>>> TypeError: can only concatenate str (not "int") to str
>>>
>>>
>>> Why doesn't Python (error msg) do the obvious thing and tell me
>>> WHAT the act
print( a + 12 )
> > TypeError: can only concatenate str (not "int") to str
> >
> >
> > Why doesn't Python (error msg) do the obvious thing and tell me
> > WHAT the actual (offending, arg) values are ?
> >
> > In many cases, it'd help to know what s
On 2/22/2023 6:46 PM, Hen Hanna wrote:
On Wednesday, February 22, 2023 at 12:05:34 PM UTC-8, Hen Hanna wrote:
py bug.py
Traceback (most recent call last):
File "C:\Usenet\bug.py", line 5, in
print( a + 12 )
TypeError: can only concatenate str (not "int") to str
Why doesn
On Wednesday, February 22, 2023 at 12:05:34 PM UTC-8, Hen Hanna wrote:
> > py bug.py
> Traceback (most recent call last):
> File "C:\Usenet\bug.py", line 5, in
> print( a + 12 )
> TypeError: can only concatenate str (not "int") to str
>
>
>
Hen or Hanna,
You keep asking WHY which may be reasonable but hard or irrelevant in many
cases.
I find the traceback perfectly informative.
It says you asked it to print NOT just "a" but "a + 12" and the error is
coming not from PRINT but from trying to invoke addition
> py bug.py
Traceback (most recent call last):
File "C:\Usenet\bug.py", line 5, in
print( a + 12 )
TypeError: can only concatenate str (not "int") to str
Why doesn't Python (error msg) do the ob
On 2/20/23 18:01, Hen Hanna wrote:
> is Comp.Lang.Python very active
Fairly. Apparently the cool kids are using the Python Discourse forum.
> why is a linear search thru a Tuple slower
> (than thru a (corresponding) List ) ???
I cannot say, unfo
is Comp.Lang.Python very active
why is a linear search thru a Tuple slower
(than thru a (corresponding) List ) ???
sometimes, i 'd like to put meaningless indentations
like i do (twice) below
( how
FWIW, it wasn’t too difficult to build a logging handler to send messages to
Slack.
https://pypi.org/project/slack-webclient-logger/
--
https://mail.python.org/mailman/listinfo/python-list
On 2023-01-05 12:29:33 -0800, Grant Edwards wrote:
> On 2023-01-05, Thomas Passin 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 usually copy the working example from my previous project
On 1/5/2023 7:52 PM, Stefan Ram wrote:
Thomas Passin writes:
On 1/5/2023 4:24 PM, Stefan Ram wrote:
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
On 1/5/2023 4:24 PM, Stefan Ram wrote:
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
ogging.basicConfig(level=logging.DEBUG)
>>> logging.info('So should this')
INFO:root:So should this
: Finally!
Not quite straightforward, though it is in the Howto. Now about those
handlers ...
From: Python-list on behalf of
Grant Edwards
Date: Thursday, January 5, 2023 at 3:31 P
On 2023-01-05, Weatherby,Gerard wrote:
> logging.basicConfig()
> logging.info(“Nice to know”)
> logging.debug(“Details for when things are funky”)
> logging.warn(“Trouble is brewing”)
I always seem to need something slightly more complex. Usually something like:
* Specify a log level on the
/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 wrote:
> The logging system is so configurable that...
I find it almost impossible to use unles
On 1/5/2023 3:29 PM, Grant Edwards wrote:
On 2023-01-05, Thomas Passin 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
On 2023-01-05, Thomas Passin 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,
On 1/5/2023 2:18 PM, Peter J. Holzer wrote:
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
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
>
o 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".
--
https://mail.python.org/mailman/listinfo/python-list
On 2023-01-04 12:32:40 -0500, Thomas Passin wrote:
> On 1/3/2023 10:35 AM, c.bu...@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
ke 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
> >
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:
wr
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?
It is up to you, th
On 1/3/2023 10:35 AM, c.bu...@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. There is a HOW-TO page
that explains this and how to get the logging package to log everything
to a file, along
On 2023-01-03 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 doesn't.
The Python logging system provides a plethora of handlers to log to lots
of different places. Only the StreamHandler defaults to w
On 2023-01-04 16:46:37 +1100, Chris Angelico wrote:
> 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.
Maybe I'm overly lax in my terminology, but I frequently use the term
On 04/01/2023 06:46, Chris Angelico wrote:
I've known some systems to have a trigger of "reading on FD 0 flushes
FD 1"
C++ has this feature:
Quote from https://en.cppreference.com/w/cpp/io/cin
"Once |std::cin| is constructed, std::cin.tie() returns ::cout
On 04/01/2023 02:26, Chris Angelico wrote:
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.
I think the logic is more like checking that stdin is a tty then using
the tty it
On 2023-01-04 at 12:02:55 +,
"Weatherby,Gerard" wrote:
> Dealing with stdout / stderr is bash is just syntax. I don’t always
> remember it off the top of my head but … stackoverflow.com.
https://tldp.org/LDP/abs/html/io-redirection.html
> On Linux at least it’s possible to pipe to
nuary 3, 2023 at 5:18 PM
To: 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. ***
Maybe some day an interface and
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
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
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
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 idea. Probably. It's definitely possible that someone tries it with
stdout redirected and goes "
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
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
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$"
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
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
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
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
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 log
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
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 workaroun
uld expect.
Error messages to stderr. _Requested output_ to stdout. Good with me.
Why does logging behave different? DEBUG and INFO imho should go to
stdout not stderr.
I entirely disagree.
Consider a shell pipeline:
cmd1 | cmd2 | cmd3
where `cmd2` and `cmd3` parse data coming down the pipe
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
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
s
From: Python-list on
behalf of Eryk Sun
Date: Tuesday, January 3, 2023 at 1:33 PM
To: c.bu...@posteo.jp
Cc: 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,
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
1 - 100 of 10368 matches
Mail list logo
