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

DM-13155: Switch from log.getName() to log.name #196

Merged
merged 1 commit into from Aug 11, 2021
Merged

Conversation

laurenam
Copy link
Contributor

@laurenam laurenam commented Aug 8, 2021

No description provided.

@@ -1033,11 +1033,11 @@ def _solve(self, kernelCellSet, basisList, returnOnExcept=False):
except Exception as e:
self.log.error("ERROR: Unable to calculate psf matching kernel")

log.log("TRACE1." + self.log.getName() + "._solve", log.DEBUG, str(e))
log.log("TRACE1." + self.log.name + "._solve", log.DEBUG, str(e))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That str at the end looks suspect to me. Pre-existing of course but I think it probably wants to instead be a simple message as for the previous log entry with exc_info=True at the end to include the exception information in the standard way

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps I dove in too deep on this ticket. I was just hoping to get rid of a gazillion deprecation warnings...I really am totally ignorant when it comes to the details and best practices of the various ways of logging things, so I have no knowledge of the exc_info parameter (it doesn't come up in a search of the Dev Guide...), nor the "standard way" of using it. I did a search of the stack for it and found very few examples, and they include cases where both are used in the same file and I'm not totally sure where/why one would be preferred, e.g.
https://github.com/lsst/ctrl_mpexec/blob/master/python/lsst/ctrl/mpexec/singleQuantumExecutor.py#L427-L435

If you are able to fill me in on exactly how this should look in this case, I'm happy to change it here, but I don't want to make any guesses as potentially changing behavior was not meant to be an intention of this simple ticket!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The identical reporting should be something like:

log.log("TRACE1." + self.log.name + "._solve", log.DEBUG, "%s", e)

since that will defer the stringification until it's needed. Given that this only triggers in an exception block it's not overly important to change it and what you have now is fine.

The tweak would be:

log.log("TRACE1." + self.log.name + "._solve", log.DEBUG, "Unable to calculate psf matching kernel", exc_info=True)

and what that will do is include the stack trace in the log itself if this logger is enabled. That probably seems more inline with what a TRACE logger would be used for (rather than just seeing the stringified exception -- otherwise the trace would be in some other place outside the logging system).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PS Your changes can be merged here as is. My tweak is a slight improvement unrelated to your original goal so feel free to ignore.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I went with the "identical reporting" option. Thanks again for all your detailed explanations!

The former is now deprecated, so replace all instances.
@laurenam laurenam merged commit 2223694 into master Aug 11, 2021
@laurenam laurenam deleted the tickets/DM-31355 branch August 11, 2021 04:13
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

Successfully merging this pull request may close these issues.

None yet

2 participants