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 &'
|
Attachments
Activity
I understand that Python 3 will be different; until we can convert the entire code base to be Unicode-agnostic, I'm hoping to limit the number of places that need to know about Unicode. We should always use UTF-8 internally.
OK with me, I guess I'll then close this ticket as wontfix and we let web layer do string conversion (should be done very close to flask layer).
I added jgates to watchers. John, it can bite you in imgserv, you are getting things like ra, decl, filter etc via rest as utf-8. I looked, and it is not too bad, you are often immediately converting to float etc, but keep this issue in mind.
yes, I am going to do the conversion very close to the flask layer.
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).