[issue35530] Counter-intuitive logging API

Change by Vinay Sajip : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bu

[issue35530] Counter-intuitive logging API

Vinay Sajip added the comment: > If this behaviour can't be changed for backwards compatibility reasons, then > so be it. It can't be changed for this reason. > But I think it would be disingenuous to claim it's not a design flaw. Do you think *I'm* being disingenuous, Mark? I don't mean to

[issue35530] Counter-intuitive logging API

Change by Raymond Hettinger : -- assignee: -> vinay.sajip ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue35530] Counter-intuitive logging API

Karthikeyan Singaravelan added the comment: > If you have 3.8 installed, feel free to test the code yourself and report > what happens. I tested it on master and it's the same as per the original report. ➜ cpython git:(master) cat ../backups/bpo35530_1.py import logging logger = logging.getL

[issue35530] Counter-intuitive logging API

Emmanuel Arias added the comment: > What would the exception say? > >FatalError: no error occurred haha, I mean a message that tell you something to avoid have some weird behave (like here). :-) > If you have 3.8 installed, feel free to test the code yourself and report > what happens.

[issue35530] Counter-intuitive logging API

Mark Dickinson added the comment: > I completely missed it. You're not alone. Authors of many of the libraries that we work with on a day-to-day basis missed it, too. And that results in logging being accidentally configured as a side-effect halfway through a long test run, when one of those

[issue35530] Counter-intuitive logging API

Steven D'Aprano added the comment: On Wed, Dec 19, 2018 at 10:37:22AM +, Mark Dickinson wrote: > > Mark Dickinson added the comment: > > The call to `logging.error` is *not* irrelevant here. It's causing an > implicit, and surprising (albeit documented), call to > `logging.basicConfig`

[issue35530] Counter-intuitive logging API

Steven D'Aprano added the comment: > That's true. Maybe and warning or Exception can be raise? Why would we raise a warning or exception for expected behaviour? logging.error() and some_instance.error() don't necessarily produce the same output. What would the exception say? FatalError:

[issue35530] Counter-intuitive logging API

Mark Dickinson added the comment: The call to `logging.error` is *not* irrelevant here. It's causing an implicit, and surprising (albeit documented), call to `logging.basicConfig`. https://bugs.python.org/issue34350 is essentially the same issue. That issue was closed as "not a bug", though

[issue35530] Counter-intuitive logging API

Karthikeyan Singaravelan added the comment: The output is the same in 3.8. I think this is due to propagation to the root logger after logging.error call. When logger.error is called with no handler attached to it then root logger handler is called and root handler's format is used. The fix

[issue35530] Counter-intuitive logging API

Emmanuel Arias added the comment: > The call to logging.error() is irrelevant, since there's no expectation that > the module-level function will necessarily output the same as a method of a > specific instance logger.error(). That's true. Maybe and warning or Exception can be raise? > It

[issue35530] Counter-intuitive logging API

Steven D'Aprano added the comment: The call to logging.error() is irrelevant, since there's no expectation that the module-level function will necessarily output the same as a method of a specific instance logger.error(). I agree that is it quite curious that the first call to logger.error o

[issue35530] Counter-intuitive logging API

New submission from Victor Porton : The following script: #/usr/bin/env python3 import logging logger = logging.getLogger(name='main') logger.setLevel(logging.INFO) logger.error('XXX') logging.error('ZZZ') logger.error('XXX') outputs XXX ERROR:root:ZZZ ERROR:main:XXX That is counter-intuitiv