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
