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 |