Gentoo Archives: gentoo-catalyst

From: Mike Frysinger <vapier@g.o>
To: gentoo-catalyst@l.g.o
Subject: Re: [gentoo-catalyst] standardizing output
Date: Fri, 09 Oct 2015 16:01:38
Message-Id: 20151009160132.GA4625@vapier.lan
In Reply to: Re: [gentoo-catalyst] standardizing output by Brian Dolbec
1 On 09 Oct 2015 08:26, Brian Dolbec wrote:
2 > On Fri, 9 Oct 2015 02:04:10 -0400 Mike Frysinger wrote:
3 > > i have noticed that DeComp calls print() and that's bad juju --
4 > > modules should never call print().
5 > >
6 > > if you do want to expose details like that in a module, you should use
7 > > the logging module and tie it to a specific logger. something like:
8 > > logger = logging.getLogger('DeComp')
9 > > logger.setLevel(logging.CRITICAL)
10 > > and then DeComp would only ever call logger.xxx to log output.
11 > >
12 > > if people want to get logging details from DeComp, then they'd do:
13 > > import DeComp
14 > > DeComp.logger.setLevel(logging.DEBUG)
15 > > assuming you put the logger into __init__.py of course. i have no
16 > > opinion on how you want to structure that logic.
17 >
18 > Yeah, I had every intention for it to use logging, I just needed
19 > catalyst to get to using it. So catalyst would provide a logger for
20 > it. I didn't have any intention for DeComp to create it's own. I's
21 > just a small module that will live in other apps.
22
23 if you call any logging function, you're picking a logger. even if you
24 just call logging.log(...), you're implicitly picking the root logger.
25 the advantage of DeComp creating its own logger is that people don't
26 have to filter out messages from it. so while we might want catalyst
27 to run in verbose mode, i don't think we want modules it pulls in like
28 DeComp also cluttering up the output. if we did actually want messages
29 from DeComp, we can configure the logger it's using to have a higher
30 level.
31 -mike

Attachments

File name MIME type
signature.asc application/pgp-signature