Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't piggyback on oauthlib's log scope #85

Closed
shazow opened this issue Oct 3, 2013 · 7 comments
Closed

Don't piggyback on oauthlib's log scope #85

shazow opened this issue Oct 3, 2013 · 7 comments

Comments

@shazow
Copy link
Contributor

shazow commented Oct 3, 2013

This happens here and possibly other places:

from oauthlib.common import log

...
log.debug(...)

This is bad because all the logs show up as coming from oauthlib, whereas some happen actually in oauthlib and some in requests_oauthlib. Differentiating them would be useful for debugging where things are happening.

I suggest using...

import logging

log = logging.getLogger(__name__)

...
log.debug(...)

This will also allow the user to turn off oauthlib logs but keep requests_oauthlib logs, and vice versa.

@ib-lundgren
Copy link
Member

+1.

Not sure whether I prefer getLogger(__name__) over a central getLogger('requests-oauthlib').

In either case we should make sure it is disabled by default witha null handler similar to https://github.com/idan/oauthlib/blob/master/oauthlib/common.py#L46.

@shazow fancy sending a PR?

@shazow
Copy link
Contributor Author

shazow commented Oct 3, 2013

If you want to be really hardcore, this is how you do it: https://github.com/shazow/urllib3/blob/master/urllib3/__init__.py#L29

I'm -0.5 on using a hardcoded scope because it breaks when you have multiple vendored copies of the module (e.g. requests vendors urllib3). Also, by using __name__, you get a proper dotted-name throughout your module which lets the user granularly configure the logging to whatever level they want. I can apply logging settings to requests_oauthlib.oauth2 without touching requests_oauthlib.oauth1 if i wanted to.

@ib-lundgren
Copy link
Member

@shazow True, I like that I have just avoided doing by name since I've not looked up how to easily turn all those loggers on/off for a particular module set.

Also if a logger is defined in many places that would call for a util method to init the logger, which is no problem, just have not happened yet.

@shazow
Copy link
Contributor Author

shazow commented Oct 3, 2013

Also if a logger is defined in many places that would call for a util method to init the logger, which is no problem, just have not happened yet.

What do you mean?

Defining a logger is still two lines (including the import), either way.

@ib-lundgren
Copy link
Member

Unless I am missing something every logger might need the whole

import logging
try:  # Python 2.7+
    from logging import NullHandler
except ImportError:
   class NullHandler(logging.Handler):
       def emit(self, record):
           pass

logging.getLogger(__name__).addHandler(NullHandler())

which might call for a util method create_logger(name) to do that for you.

@shazow
Copy link
Contributor Author

shazow commented Oct 3, 2013

Nope, only the root namespace needs it.

That is, if you apply settings for logging.getLogger(),
it applies for everything. (Naughty thing to do in a lib. Don't do it.)

If you do it for logging.getLogger('requests_oauthlib'),
it will apply to anything under requests_oauthlib, including requests_oauthlib.oauth2.

If you do it for logging.getLogger('requests_oauthlib.oauth2'),
... you get the idea. :P

Not many people know this for some reason. Handy feature.

This is why the snippet you copypasta'd is done in urllib3/__init__.py, so it applies to the root namespace of the urllib3 module, wherever it might live.

@ib-lundgren
Copy link
Member

@shazow including me. Thanks that is great to know. Definitely go with the name approach then.

Will refactor oauthlib to do the same in due time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants