astropy/astropy — pull request #222 by mdboom (2012-05-04 17:06:40+00:00)
Title: Various logging fixes

This is a number of bugfixes for the `logging_helper` module that were hard to unbundle. Sorry for the lack of individual commits. @astropy: You may want to vet this.

1) Use our compat `inspect_getmodule` to get around a bug in py 3.1, 3.2

2) Display the warning class in the log message as suggested by @eteq in #221. Adds a new test `test_warnings_logging_with_custom_class` to test that functionality.

3) Correctly extract the source of the warning when logging it. Since `warnings.warn` may have been called with a `stacklevel` argument, the logical source of the warning may not be the first "different" module up the call stack (as found by `find_current_module`'s `finddiff` functionality). Instead, the third argument passed to `showwarning`, the file path is used. There doesn't seem to be a direct way to get from a file path to a module name, so it iterates through sys.modules to find a module that matches the given path. On Python 3 this is trivial. On Python 2, we need to ignore the file extension, since module.__file__ is set to the .pyc file, but `showwarnings`'s file argument gives us the path to the source file. That hacky mess could be eliminated if we'd rather display the file path to the source rather than the module path (and the exception logger should be updated to match, but that's easy since going from module to file is much easier than file to module).

4) A minor refactoring to call `self.warnings_logging_enabled()`/`self.exception_logging_enabled()` rather than duplicating the test for that everywhere.

5) Fix the determination of origin in the exception logger. The traceback passed to excepthook starts pointing at the outermost stack frame, but I believe what we want to log is the innermost stack frame. It's been changed so it recurses into the stack until reaching the innermost stack frame and getting the module name from that. A test has been added (`test_exception_loggin_origin`) to test that the origin of exceptions is correctly determined over in disparate parts of the source tree.

6) Since `io.vo.exceptions.VOWarning` has been fixed, there is no longer a need to special case those warnings in `logging_helper`. A test has been added, (`test_warning_logging_with_io_vo_warning`), to make sure that remains the case.

7) The warning utilities in `io.vo` now use `warnings.warn`'s `stacklevel` kwarg to show that the warning comes from the source of the warning and not the `exceptions` utilities module. This required cleaning out the `__warningregistry__` in more modules in order for `io.vo.validate` to continue working.