Python 2.7 build failing due to Unicode characters...

jklymak1 · September 8, 2017, 5:49pm

Hi all,

Very sorry to be ignorant, but my python 2.7 build of the
[constrained_layout
manager](https://github.com/matplotlib/matplotlib/pull/9082) is failing
because the underlying functions don?t accept unicode strings. i.e.
`boo(?test?)` fails with a warning: `TypeError: Expected object of
type `float, int, or long`. Got object of type unicode instead.` OK,
the warning is a little confused - strings get converted to floats
inside this fcn, but you get the idea?

Am I supposed to put `# -*- coding: utf-8 -*-` at the top of every
source that might create a string that calls these functions? Or should
I convert the string somehow in my wrappers before passing down? Or
does `from __future__ import unicode_literals` do this?

Thanks for bearing with me, Jody
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170908/ab495c8a/attachment.html>

ben.v.root · September 8, 2017, 6:07pm

as a general rule, we have a set of __future__'s that we put at the top of
every python source:

from __future__ import (absolute_import, division, print_function,
                        unicode_literals)

Now, whether or not this would fix your problem or not, I haven't a clue.

···

On Fri, Sep 8, 2017 at 1:49 PM, Jody Klymak <jklymak at uvic.ca> wrote:

Hi all,

Very sorry to be ignorant, but my python 2.7 build of the constrained_layout
manager <https://github.com/matplotlib/matplotlib/pull/9082> is failing
because the underlying functions don?t accept unicode strings. i.e.
boo(?test?) fails with a warning: TypeError: Expected object of typefloat,
int, or long. Got object of type unicode instead. OK, the warning is a
little confused - strings get converted to floats inside this fcn, but you
get the idea?

Am I supposed to put # -*- coding: utf-8 -*- at the top of every source
that might create a string that calls these functions? Or should I convert
the string somehow in my wrappers before passing down? Or does from
__future__ import unicode_literals do this?

Thanks for bearing with me, Jody

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170908/ea933799/attachment.html>

jklymak1 · September 8, 2017, 9:11pm

as a general rule, we have a set of __future__'s that we put at the
top of
every python source:
from __future__ import (absolute_import, division, print_function,
                        unicode_literals)

Thanks!

Unfortunately, that is the problem. kiwi, which is written in CPP,
has a check for python version:

\#if PY\_MAJOR\_VERSION &gt;= 3
\#define FROM\_STRING PyUnicode\_FromString
\#else
\#define FROM\_STRING PyString\_FromString
\#endif

So it can handle Unicode, but has no way to know it should handle
Unicode if we are using python 2.7 and unicode_literals. I?ve
opened an issue with them,
though of course if someone here had expertise in this it?d be very
helpful. Worst case scenario I can just cast every call to str, it
just makes the code a bit of a mess.

Thanks a lot, Jody


Now, whether or not this would fix your problem or not, I haven&#39;t a 
clue\.

> Hi all,
>
> Very sorry to be ignorant, but my python 2\.7 build of the 
> constrained\_layout
> manager &lt;https://github.com/matplotlib/matplotlib/pull/9082&gt; is 
> failing
> because the underlying functions don?t accept unicode strings\. i\.e\.
> boo\(?test?\) fails with a warning: TypeError: Expected object of 
> typefloat,
> int, or long\. Got object of type unicode instead\. OK, the warning is 
> a
> little confused \- strings get converted to floats inside this fcn, 
> but you
> get the idea?
>
> Am I supposed to put \# \-\*\- coding: utf\-8 \-\*\- at the top of every 
> source
> that might create a string that calls these functions? Or should I 
> convert
> the string somehow in my wrappers before passing down? Or does from
> \_\_future\_\_ import unicode\_literals do this?
>
> Thanks for bearing with me, Jody
>
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
> Matplotlib\-devel mailing list
> Matplotlib\-devel at python\.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170908/12300f77/attachment.html>

···

On 8 Sep 2017, at 11:07, Benjamin Root wrote:

On Fri, Sep 8, 2017 at 1:49 PM, Jody Klymak <jklymak at uvic.ca> wrote:

chris.barker · September 11, 2017, 8:56pm

Unfortunately, that is the problem. kiwi, which is written in CPP, has a
check for python version:

#if PY_MAJOR_VERSION >= 3
#define FROM_STRING PyUnicode_FromString
#else
#define FROM_STRING PyString_FromString
#endif

ouch! IMHO, they made a major mistake here -- they should have used

Unicode in both versions, and cast a py2 string to unicode if need be.

So it can handle Unicode, but has no way to know it *should* handle
Unicode if we are using python 2.7 and unicode_literals.

actually, this looks like it can't handle unicode in the CPP code under py2
at all

I?ve opened an issue with them,
<Issues · nucleic/kiwi · GitHub; though of course if someone
here had expertise in this it?d be very helpful. Worst case scenario I can
just cast every call to str, it just makes the code a bit of a mess.

unless they change the cpp, I think you'll have to do that. Then prepare
yourself for mysterious encoding errors to pop up later on ....

-CHB

Now, whether or not this would fix your problem or not, I haven't a clue.

the error is:

TypeError: Expected object of typefloat,
int, or long. Got object of type unicode instead.

are you sure this is a unicode instead of string problem? MAybe you need to
call float() or int() on the value before passing it in.

-CHB

Am I supposed to put # -*- coding: utf-8 -*- at the top of every source
that might create a string that calls these functions?

that will make no difference.

Or should I convert
the string somehow in my wrappers before passing down?

yeah, probably.

Or does from
__future__ import unicode_literals do this?

what that does is make text literals, like:

"this is some text"

a unicode object, rather than a py2string object -- but if the string comes
from somewhere else, it makes no difference.

But if that IS in the source, then you will get a lot more unicode objects
getting passed around.

-CHB

···

On Fri, Sep 8, 2017 at 2:11 PM, Jody Klymak <jklymak at uvic.ca> wrote:

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170911/95a3377d/attachment.html>

jklymak1 · September 11, 2017, 9:00pm

Hi Chris,

We (they) are fixing it, though it quickly got out of my depth? If
you had any suggestions for them, I?m sure they would listen. They
are actively interested in addressing this.

github.com/nucleic/kiwi

Fix to allow unicode py2.7

nucleic:master ← jklymak:fixpy27unicode

opened 09:31PM - 09 Sep 17 UTC

jklymak

+79 -44

This is to fix https://github.com/nucleic/kiwi/issues/39. It works on the test …I have. I admit I didn't run the other tests. It basically allows `from __future__ import unicode_literals` to be used in python 2.7. I tested in Python 2.7 with and with out that line at the top for the test, and in python 3 w/ that line. ```python from __future__ import unicode_literals import kiwisolver as kiwi Variable = kiwi.Variable solver = kiwi.Solver() top = Variable('boo') c = (top == 1.0) solver.addConstraint(c | 'strong') solver.dump() ``` @sccolbert @MatthieuDartiailh Thanks!

Thanks! Jody

···

On 11 Sep 2017, at 13:56, Chris Barker wrote:

On Fri, Sep 8, 2017 at 2:11 PM, Jody Klymak <jklymak at uvic.ca> wrote:

Unfortunately, that is the problem. kiwi, which is written in CPP,
has a
check for python version:

#if PY_MAJOR_VERSION >= 3
#define FROM_STRING PyUnicode_FromString
#else
#define FROM_STRING PyString_FromString
#endif

ouch! IMHO, they made a major mistake here -- they should have used

Unicode in both versions, and cast a py2 string to unicode if need be.

So it can handle Unicode, but has no way to know it *should* handle
Unicode if we are using python 2.7 and unicode_literals.

actually, this looks like it can't handle unicode in the CPP code
under py2
at all

I?ve opened an issue with them,
<Issues · nucleic/kiwi · GitHub; though of course if
someone
here had expertise in this it?d be very helpful. Worst case
scenario I can
just cast every call to str, it just makes the code a bit of a mess.

unless they change the cpp, I think you'll have to do that. Then
prepare
yourself for mysterious encoding errors to pop up later on ....

-CHB

Now, whether or not this would fix your problem or not, I haven't a
clue.

the error is:

TypeError: Expected object of typefloat,
int, or long. Got object of type unicode instead.

are you sure this is a unicode instead of string problem? MAybe you
need to
call float() or int() on the value before passing it in.

-CHB

Am I supposed to put # -*- coding: utf-8 -*- at the top of every
source
that might create a string that calls these functions?

that will make no difference.

Or should I convert
the string somehow in my wrappers before passing down?

yeah, probably.

Or does from
__future__ import unicode_literals do this?

what that does is make text literals, like:

"this is some text"

a unicode object, rather than a py2string object -- but if the string
comes
from somewhere else, it makes no difference.

But if that IS in the source, then you will get a lot more unicode
objects
getting passed around.

-CHB

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker at noaa.gov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170911/a0176bed/attachment-0001.html>