Troy Curtis Jr wrote on Sun, 11 Feb 2018 02:28 +0000:
> I committed the fix to the bindings in
> https://svn.apache.org/viewvc?view=revision&revision=1823802 . In addition
> to Kenneth's suggestion of opening in binary mode, I switched the imports
> so that the python2-future's implementation would not get inadvertently
> pulled in. Everything looked fine with the how python2-future's open
> worked (since it did in fact use the Python 3's open() semantics), but I
> think it best that on the intended modules are included. I also added a
> test which duplicated the issue (with python2-future installed at least),
> and confirms the fix.
>
> This is a relatively isolated change, but fixes surprising behavior (as
> Kenneth can attest to), does something like this make sense to propose for
> the 1.10 branch?
The change is non-invasive, backwards-compatible, fixes a user-visible
bug, is unlikely to introduce new ones, and has a test. That makes it a
good backport candidate.
Usually we have just two 'live' branches in addition to trunk, but currently
we have three (1.8 under security support, 1.9 supported, 1.10 in beta), so
you might consider nominating this to 1.9 in addition to 1.10.
That said, I'm a bit puzzled at changing the order of imports. Our
practise throughout the codebase appears to be 'try: import py3name;
except ImportError: import py2name', and I don't understand why this one
case should be different. Secondly, if I understand correctly, the
'past' package makes 'import __builtins__' work on py3, so changing the
order of imports simply trades one potential problem for another,
doesn't it? And thirdly, why would it be a problem if 'from builtins import
open' worked under py2, so long as it had the same semantics as it
does under py3? (I.e., so long as it set locals()['open'] to a function with
the same semantics as py3's open() function)
Cheers,
Daniel
Received on 2018-02-11 09:38:38 CET