Details
-
Type:
Bug
-
Status: Won't Fix
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: log
-
Labels:None
-
Story Points:1
-
Team:Data Access and Database
Description
Log is currently failing if we pass unicode string, it is easy to reproduce by doing: log.info(u"hello"). It fails with:
File "/home/becla/dataArchDev/Linux64/log/master-gfab0203bd3+3/python/lsst/log/log.py", line 103, in info
|
log("", INFO, fmt, *args, depth=2)
|
File "/home/becla/dataArchDev/Linux64/log/master-gfab0203bd3+3/python/lsst/log/log.py", line 94, in log
|
_getFuncName(depth), frame.f_lineno, fmt % args)
|
File "/home/becla/dataArchDev/Linux64/log/master-gfab0203bd3+3/python/lsst/log/logLib.py", line 648, in forcedLog_iface
|
return _logLib.forcedLog_iface(*args)
|
TypeError: in method 'forcedLog_iface', argument 6 of type 'std::string const &'
|
Hmm, this kind of contradicts my understanding of Python unicode evolution towards Python3. Converting unicode to string (or rather bytes) needs an agreement on encoding and/or passing encoding information around. Is there a LSST guideline for how to treat conversion and different encodings, or a subset of unicode is acceptable as input (i.e. we accept only "latin-1" as input data).