Re: TypeError: ord() expected a character, but string of length 3 found (Was: Updated python-uncertainties)
On Fri, Oct 12, 2018 at 06:19:00PM +0200, Piotr Ożarowski wrote:
> [PICCA Frederic-Emmanuel, 2018-10-12]
> > to my opinion, the code is modify in place with 2to3.
> > So the code on the source after the configuration is already converted to
> > python3.
> > And during the build process, with python2 the code is copied as it in the
> > .pybuild place for python2
> > with python3 we see that the RefactoringTool, does nothing, it means the
> > code is already converted to python3.
>
> try adding python3-setuptools to Build-Depends
To follow this hint I did:
diff --git a/debian/control b/debian/control
index c66846a..12dfd7d 100644
--- a/debian/control
+++ b/debian/control
@@ -10,10 +10,12 @@ Build-Depends: debhelper (>= 11~),
python-all,
python-nose,
python-numpy,
+ python-setuptools,
python3-sphinx,
python3-all,
python3-nose,
python3-numpy,
+ python3-setuptools,
2to3
Standards-Version: 4.2.1
Vcs-Browser: https://salsa.debian.org/debian/python-uncertainties
diff --git a/debian/rules b/debian/rules
index 9a27f86..59d4cf5 100755
--- a/debian/rules
+++ b/debian/rules
@@ -17,14 +17,14 @@ override_dh_auto_build:
dh_auto_build
PYTHONPATH=`pybuild --print build_dir --interpreter python3`
http_proxy='http://127.0.0.1:9/' sphinx-build -N -bhtml doc debian/html
-override_dh_auto_test:
+__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 || true # FIXME: Ignore errors for the moment but at least
document these in logs
endif
-override_dh_auto_install:
+__override_dh_auto_install:
dh_auto_install
# we need the same means as for the tests again before installing the
files
find debian -name core.py -exec sed -i
"s/^\([[:space:]]\+0x[0-9a-f]\{2\}: \)'/\1u'/" \{\} \;
which results in:
PYTHONPATH=`pybuild --print build_dir --interpreter python3`
http_proxy='http://127.0.0.1:9/' sphinx-build -N -bhtml doc debian/html
Running Sphinx v1.7.9
Configuration error:
There is a syntax error in your configuration file: invalid syntax (core.py,
line 2882)
Did you change the syntax from 2.x to 3.x?
make[1]: *** [debian/rules:18: override_dh_auto_build] Error 2
If I try in the pbuilder chroot
/build/uncertainties-3.0.2.github# python3
Python 3.6.7rc1 (default, Sep 27 2018, 09:51:25)
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from uncertainties import core
Traceback (most recent call last):
File "", line 1, in
File "/build/uncertainties-3.0.2.github/uncertainties/__init__.py", line 224,
in
from .core import *
File "/build/uncertainties-3.0.2.github/uncertainties/core.py", line 2882
POSITIVE_DECIMAL_UNSIGNED_OR_NON_FINITE =
ur'((\d*)(\.\d*)?|nan|NAN|inf|INF)'
^
SyntaxError: invalid syntax
So this a different issue and I admit that the changes in core.py are
different from the ones without python3-setuptools. Any hint how I
could solve the latter issue since I'd prefer to ship the package
without the ugly hack?
Kind regards
Andreas.
--
http://fam-tille.de
RE:TypeError: ord() expected a character, but string of length 3 found (Was: Updated python-uncertainties)
I found in the code a string with a ur'' This is the problematic line. I do not know if this is a valid string construction. I also dound that you need to remove the sys.path modifications from the conf.py. this can cause some troubles during the build. Cheers. Fred
Re: TypeError: ord() expected a character, but string of length 3 found (Was: Updated python-uncertainties)
On Mon, Oct 15, 2018 at 09:40:27AM +, PICCA Frederic-Emmanuel wrote: > I found in the code a string with a ur'' > > This is the problematic line. > > I do not know if this is a valid string construction. Under Python 2 it is. Under Python 3 it is not. u'test' is valid but extraneous r'test' is valid but extraneous Since this is about reguular expressions I would suggest just using 'the regex' under Python 3. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
Re: TypeError: ord() expected a character, but string of length 3 found (Was: Updated python-uncertainties)
Hi, On Mon, Oct 15, 2018 at 09:40:27AM +, PICCA Frederic-Emmanuel wrote: > I found in the code a string with a ur'' > > This is the problematic line. > > I do not know if this is a valid string construction. Patches are welcome (I have no idea what the construct is doing neither how to replace it with something valid). > I also dound that you need to remove the sys.path modifications from the > conf.py. > > this can cause some troubles during the build. Patch welcome as well - preferably as commit to Git. Kind regards Andreas. -- http://fam-tille.de
RE:TypeError: ord() expected a character, but string of length 3 found (Was: Updated python-uncertainties)
I think that the real problem with the current build is that the conf.py file change the sys.path. this is why we see this syntax eror. sphinx pick the wrong path. I can not work on this now..., I am not in fron of a Debian box nor have access to one todays... Cheers Fred
RE:TypeError: ord() expected a character, but string of length 3 found (Was: Updated python-uncertainties)
Hello Andreas, > Patches are welcome (I have no idea what the construct is doing neither > how to replace it with something valid). > Patch welcome as well - preferably as commit to Git. done but now, we need to understand why lintian complain about python module at the wrong place before uploading. I amnot sure thet the test run as installed... Fred
RE:TypeError: ord() expected a character, but string of length 3 found (Was: Updated python-uncertainties)
Hello, here a diff between the python3.6 and python3.7 modules once updated via 2to3. r:/tmp$ diff core* 174c174 < for (variance, tag) in zip(variances, tags)) --- > for (variance, tag) in list(zip(variances, tags))) 181c181 < for (coords, value) in zip(transform, nom_values)) --- > for (coords, value) in list(zip(transform, nom_values))) 946c946 < ord(sup): normal for (normal, sup) in TO_SUPERSCRIPT.items()} --- > ord(sup): normal for (normal, sup) in iter(TO_SUPERSCRIPT.items())} 1776c1776 < delta**2 for delta in self.error_components().values( --- > delta**2 for delta in iter(self.error_components().values() can python expert explain if this seems correct or not ? thanks for your help. Frederic
Re: TypeError: ord() expected a character, but string of length 3 found (Was: Updated python-uncertainties)
Picca, Hi PICCA Frederic-Emmanuel, > Hello, here a diff between the python3.6 and python3.7 modules Please use "unified" (ie. diff -u, possibly diff -urNad) over old-style diffs in future > < ord(sup): normal for (normal, sup) in TO_SUPERSCRIPT.items()} > > ord(sup): normal for (normal, sup) in iter(TO_SUPERSCRIPT.items())} No expert and I assume it works, but this doesn't "smell" right to me. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Matplotlib 3.0 - update ok?
Hello, I am keeping me busy packaging the Orange machine learning library that seems nice (https://orange.biolab.si/#Orange-Features). Now, the test routines demand a matplotlib.pyplot module that is not in version 2 that we feature. Version 3 is the current stable release. Now, I am tempted to create a package matplotlib3 instead of forcing everyone to update from this long term release (see https://matplotlib.org/). Any opinions from your sides? Cheers, Steffen
Re: Matplotlib 3.0 - update ok?
On Mon, 2018-10-15 at 22:44 +0200, Steffen Möller wrote: > Hello, > > I am keeping me busy packaging the Orange machine learning library > that > seems nice (https://orange.biolab.si/#Orange-Features). Now, the > test > routines demand a matplotlib.pyplot module that is not in version 2 > that > we feature. Version 3 is the current stable release. Ack. Thank you for explaining the context. > Now, I am tempted to create a package matplotlib3 instead of forcing > everyone to update from this long term release (see > https://matplotlib.org/). > > Any opinions from your sides? How is that going to work without creating package conflicts? I suppose the main module is still named "matplotlib" not "matplotlib3" in version 3 onwards? So using python3-matplotlib3 would be a breach of policy. Let me ask you this: where is the rush to package this machine learning library? Could it wait after the Buster release cycle, where we might be in a more comfortable position to upgrade matplotlib? Cheers, Ghis
Re: Matplotlib 3.0 - update ok?
On Tue, Oct 16, 2018 at 07:30:55AM +0100, ghisv...@gmail.com wrote: > > Any opinions from your sides? > > How is that going to work without creating package conflicts? > > I suppose the main module is still named "matplotlib" not > "matplotlib3" in version 3 onwards? So using python3-matplotlib3 would > be a breach of policy. Probably. > Let me ask you this: where is the rush to package this machine learning > library? Could it wait after the Buster release cycle, where we might > be in a more comfortable position to upgrade matplotlib? I'm not sure what might be the difference between: 3.0.0 Stable version 2.2.3 LTS LTS version We have some months left until freeze so may be right now it is not to late to package what upstream considers stable. Kind regards Andreas. -- http://fam-tille.de
Re: Matplotlib 3.0 - update ok?
On Tue, 2018-10-16 at 08:46 +0200, Andreas Tille wrote: > On Tue, Oct 16, 2018 at 07:30:55AM +0100, ghisv...@gmail.com wrote: > > > Any opinions from your sides? > > > > How is that going to work without creating package conflicts? > > > > I suppose the main module is still named "matplotlib" not > > "matplotlib3" in version 3 onwards? So using python3-matplotlib3 > > would > > be a breach of policy. > > Probably. Described in Section 2.2 of the Debian Python policy. > > Let me ask you this: where is the rush to package this machine > > learning > > library? Could it wait after the Buster release cycle, where we > > might > > be in a more comfortable position to upgrade matplotlib? > > I'm not sure what might be the difference between: > >3.0.0 Stable version >2.2.3 LTS LTS version > > We have some months left until freeze so may be right now it is not > to > late to package what upstream considers stable. > > Kind regards > > Andreas. >From the upstream homepage: "Matplotlib 3.0 is Python 3 only." Afaik, Python 2 is still considered relevant for the Buster release cycle. Hence why I am suggesting to wait for the next release cycle before upgrading key scientific packages, such as matplotlib, to Python 3 only. Cheers, Ghis
