subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Troy Curtis Jr <>
Subject Re: commit says TypeError: must be unicode, not str
Date Thu, 08 Feb 2018 03:29:50 GMT
On Wed, Feb 7, 2018 at 8:53 PM Kenneth Porter <> wrote:

> --On Thursday, February 08, 2018 2:30 AM +0000 Troy Curtis Jr
> <> wrote:
> > If that package was being imported, I'd definitely expect that kind of
> > behavior, but merely it's presence on your system should not be enough to
> > actually cause your python scripts to use the "future" behavior within
> > python 2.7.  Has the been changed, or is it being imported by
> > some other script as a module that does import the future module?
> It happens at the top of with this sequence:
> try:
>   # Python >=3.0
>   import builtins
> except ImportError:
>   # Python <3.0
>   import __builtin__ as builtins
> The code should be taking the except clause but the presence of the
> compatibility package fools into thinking it's on a 3.0 system. This
> might work except for the improper Unicode assumption about the kind of
> object returned by open().

Egads! You are right!  I had in mind the 'import __future__ <blah>'
statement, thinking you'd be
safe as long as you didn't do that, but sure enough, a 'rpm -ql
python2-future' reveals:

That was certainly unexpected..and presumably a bad way to detect
python3/python2.  Though the case could be
made that if the code was py3 compatible, and python2-futures brought the
py3 features, all should be well.  In this case the py3
compat was only starting to happen, but hadn't finished yet.

It certainly seems like something to address, the mere presence of the
compat library causes the bindings to misbehave.

I'll take a look at it tonight or tomorrow night unless someone beats me to


View raw message