Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Story Points:1
-
Epic Link:
-
Team:Data Release Production
Description
The lsstDebug documentation claims:
It is always safe to interrogate lsstDebug; for example lsstDebug.Info("Robert.Hugh.Lupton").isBadPerson will return False.
In fact, this is only true if a Robert.Hugh.Lupton module has been imported. Otherwise, we get:
In [1]: import lsstDebug
|
|
|
In [2]: lsstDebug.Info("Robert.Hugh.Lupton")
|
---------------------------------------------------------------------------
|
KeyError Traceback (most recent call last)
|
<ipython-input-2-7b61e1f45b97> in <module>()
|
----> 1 lsstDebug.Info("Robert.Hugh.Lupton")
|
|
|
/ssd/lsstsw/stack_20170409/Linux64/base/13.0-5-g77abda3+2/python/lsstDebug.pyc in __init__(self, modname)
|
51 def __init__(self, modname):
|
52 import sys
|
---> 53 self.__dict__["_dict"] = sys.modules[modname].__dict__
|
54 self._modname = modname
|
55
|
|
|
KeyError: 'Robert.Hugh.Lupton'
|
Thanks to Michael Wood-Vasey on CLO for spotting this.
Attachments
Activity
There's confusion here about levels of indirection. In your package create an LsstDebug object:
import lsstDebug
|
|
|
debugInfo= lsstDebug.Info(__name__)
|
then you can ask debugInfo about me:
print(debugInfo.RobertHughLupton)
|
and it'll say that I'm a false knave (or False anyway)
So it's a documentation bug – that example's in package Robert.Hugh.Lupton.
Doc strings in mainpage.dox and lsstDebug.py have been updated to more accurately reflect the behaviour of lsstDebug. Successfully completed Jenkins.
I think it might be clearer to say that you may interrogate lsstDebug for any string in sys.modules, i.e. for the _name_ of any package that has been imported. I suspect that I didn't support any random string to reduce the probability of typos.
Otherwise, good to merge.
Thank you for the review and comments. I've made the changes you suggest and merged to master.
Robert Lupton — I think you understand the design of this system better than anybody (since you produced it). What's the intended behaviour here? Is this a code or a documentation bug?