Hi again, On Fri, Oct 12, 2018 at 02:44:26PM +0200, Andreas Tille wrote: > > > > > > File "/usr/lib/python2.7/dist-packages/uncertainties/core.py", line > > > > 946, in <dictcomp> > > > > ord(sup): normal for (normal, sup) in list(TO_SUPERSCRIPT.items())} > > > > Please always provide a minimal testcase, otherwise people have to do a > > lot of work simply to get where you are.. > > Hmmm, I've thought the "test case" I've given in my first mail, just > doing > > from uncertainties import core > > would be sufficient. > > > Under Python 2.x, list(TO_SUPERSCRIPT.items()) is: > > > > [(43, '\xe2\x81\xba'), > > (45, '\xe2\x81\xbb'), > > (48, '\xe2\x81\xb0'), > > […] > > ] > > > > ie. strings with a length of 3 whilst ord() takes a single char. These > > should therefore be probably defined as: > > > > TO_SUPERSCRIPT = { > > 0x2b: u'⁺', > > 0x2d: u'⁻', > > […] > > > > .. instead, but I haven't tested or confirmed or anythinged that; I'll > > leave it with you and upstream. > > I will contact upstream but I wanted to hear the opinion of the > Uploaders of this package.
Before I discuss this with upstream I'd like to share another observation: There is some 2to3 magic applied to the source code which has the effect that the original source code file which has $ grep -A4 "^TO_SUPERSCRIPT = {" uncertainties/core.py TO_SUPERSCRIPT = { 0x2b: u'⁺', 0x2d: u'⁻', 0x30: u'⁰', 0x31: u'¹', is turned into grep -A4 "^TO_SUPERSCRIPT = {" uncertainties/core.py TO_SUPERSCRIPT = { 0x2b: '⁺', 0x2d: '⁻', 0x30: '⁰', 0x31: '¹', inside the pbuilder environment. I hacked around with the following code: + +override_dh_auto_test: +ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) + # for some very strange reason the RefactoringTool breaks the definions in TO_SUPERSCRIPT + find . -name core.py -exec sed -i "s/^\([[:space:]]\+0x[0-9a-f]\{2\}: \)'/\1u'/" \{\} \; + dh_auto_test +endif which left me with other test suite failures. Since I'm totally new to this package and I have no idea whether this is some Debian specific build (I had some quite unfriendly conversation with lmfit-py upstream[1]) so would like to make sure there is no Debian specific issue first. (Disclaimer: I'm totally new to this package as well as lmfit-py - a Debian Med package just depends from the latter and nobody else seem to have free time cycles to care. So please excuse my naivity.) Kind regards Andreas. [1] https://github.com/lmfit/lmfit-py/issues/502 -- http://fam-tille.de