From justinisrael at gmail.com  Sun Dec 16 04:56:38 2018
From: justinisrael at gmail.com (Justin Israel)
Date: Sun, 16 Dec 2018 22:56:38 +1300
Subject: [Python-porting] builtins.str return type in py2
Message-ID: <CAPGFgA1Qm7ORWMvzXgMODbqxN_9949TUWFcOw1peJXCMyJ=v-w@mail.gmail.com>

Hi,

I've just been digging into future for one of my existing python2 libraries
that needs py3 support. One thing I am wondering is about the compatability
of the builtins.str type on python2. I have reviewed the API documentation (
http://python-future.org/str_object.html)

It seems like part of the documentation describes the backported py2 class
as wanting to remain compatable with py2, while part of it says it follows
the py3 functionality. I have a usage of str.translate in my library, and
they have different signatures:

py2
S.translate(table [,deletechars]) -> string

py3
S.translate(table) -> str

with builtins.str following the py3 signature.
So it makes me wonder what I should be expecting if I import the
builtins.str type and allow it to be returned to users of the library. Is
it expected that a user of a library providing py2/3 support via future
might return string types that aren't fully compatible with python2 code?
What if a user tries to call str.translate on the returned string, or some
other method that happens to follow the py3 signature?

Looking for a little extra guidance on the best practices around returning
these backported builtins to py2 users.

Thanks!
Justin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-porting/attachments/20181216/2ed60dfd/attachment.html>

From regebro at gmail.com  Wed Dec 26 03:18:27 2018
From: regebro at gmail.com (Lennart Regebro)
Date: Wed, 26 Dec 2018 09:18:27 +0100
Subject: [Python-porting] builtins.str return type in py2
In-Reply-To: <CAPGFgA1Qm7ORWMvzXgMODbqxN_9949TUWFcOw1peJXCMyJ=v-w@mail.gmail.com>
References: <CAPGFgA1Qm7ORWMvzXgMODbqxN_9949TUWFcOw1peJXCMyJ=v-w@mail.gmail.com>
Message-ID: <CAL0kPAVqxptGFcZimNDTkH3jCxFHSGBbHYAtvH0+_OJ5AxzJ5A@mail.gmail.com>

At this point, I would not bother about backporting to Python 2. You
can either add Python 3 support to your existing Python 2 code to make
the library support both versions with the same code, or just move to
Python 3 and drop Python 2 support. All that means is that Python 2
users will have to stay on the current release for the remaining 370
days that Python 2 is still supported. By then they should have moved
off Python 2, and there is no reason to support Python 2 beyond that
at all.

My personal opinion and experience about the python-future package is
that it's best avoided. YMMV.

On Sun, Dec 23, 2018 at 1:23 PM Justin Israel <justinisrael at gmail.com> wrote:
>
> Hi,
>
> I've just been digging into future for one of my existing python2 libraries that needs py3 support. One thing I am wondering is about the compatability of the builtins.str type on python2. I have reviewed the API documentation (http://python-future.org/str_object.html)
>
> It seems like part of the documentation describes the backported py2 class as wanting to remain compatable with py2, while part of it says it follows the py3 functionality. I have a usage of str.translate in my library, and they have different signatures:
>
> py2
> S.translate(table [,deletechars]) -> string
>
> py3
> S.translate(table) -> str
>
> with builtins.str following the py3 signature.
> So it makes me wonder what I should be expecting if I import the builtins.str type and allow it to be returned to users of the library. Is it expected that a user of a library providing py2/3 support via future might return string types that aren't fully compatible with python2 code? What if a user tries to call str.translate on the returned string, or some other method that happens to follow the py3 signature?
>
> Looking for a little extra guidance on the best practices around returning these backported builtins to py2 users.
>
> Thanks!
> Justin
>
> _______________________________________________
> Python-porting mailing list
> Python-porting at python.org
> https://mail.python.org/mailman/listinfo/python-porting

From justinisrael at gmail.com  Wed Dec 26 13:42:39 2018
From: justinisrael at gmail.com (Justin Israel)
Date: Thu, 27 Dec 2018 07:42:39 +1300
Subject: [Python-porting] builtins.str return type in py2
In-Reply-To: <CAL0kPAVqxptGFcZimNDTkH3jCxFHSGBbHYAtvH0+_OJ5AxzJ5A@mail.gmail.com>
References: <CAPGFgA1Qm7ORWMvzXgMODbqxN_9949TUWFcOw1peJXCMyJ=v-w@mail.gmail.com>
 <CAL0kPAVqxptGFcZimNDTkH3jCxFHSGBbHYAtvH0+_OJ5AxzJ5A@mail.gmail.com>
Message-ID: <CAPGFgA0uhjjCZC__N0T2+c4u0sJO-otcYEd_tr_a2jym+KZFnQ@mail.gmail.com>

On Wed, Dec 26, 2018, 9:18 PM Lennart Regebro <regebro at gmail.com> wrote:

> At this point, I would not bother about backporting to Python 2. You
> can either add Python 3 support to your existing Python 2 code to make
> the library support both versions with the same code, or just move to
> Python 3 and drop Python 2 support. All that means is that Python 2
> users will have to stay on the current release for the remaining 370
> days that Python 2 is still supported. By then they should have moved
> off Python 2, and there is no reason to support Python 2 beyond that
> at all.
>
> My personal opinion and experience about the python-future package is
> that it's best avoided. YMMV.
>

That is good advice and it makes alot of sense considering how close the
support ends for py2. We do want to get people migrating at our company but
we also don't want to support two version streams for a year of possible.

I did find the six-style string_types, text_type, etc in the utills. Also
there is the native() call, so I am testing having my library convert to
native when it returns strings to the caller.


> On Sun, Dec 23, 2018 at 1:23 PM Justin Israel <justinisrael at gmail.com>
> wrote:
> >
> > Hi,
> >
> > I've just been digging into future for one of my existing python2
> libraries that needs py3 support. One thing I am wondering is about the
> compatability of the builtins.str type on python2. I have reviewed the API
> documentation (http://python-future.org/str_object.html)
> >
> > It seems like part of the documentation describes the backported py2
> class as wanting to remain compatable with py2, while part of it says it
> follows the py3 functionality. I have a usage of str.translate in my
> library, and they have different signatures:
> >
> > py2
> > S.translate(table [,deletechars]) -> string
> >
> > py3
> > S.translate(table) -> str
> >
> > with builtins.str following the py3 signature.
> > So it makes me wonder what I should be expecting if I import the
> builtins.str type and allow it to be returned to users of the library. Is
> it expected that a user of a library providing py2/3 support via future
> might return string types that aren't fully compatible with python2 code?
> What if a user tries to call str.translate on the returned string, or some
> other method that happens to follow the py3 signature?
> >
> > Looking for a little extra guidance on the best practices around
> returning these backported builtins to py2 users.
> >
> > Thanks!
> > Justin
> >
> > _______________________________________________
> > Python-porting mailing list
> > Python-porting at python.org
> > https://mail.python.org/mailman/listinfo/python-porting
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-porting/attachments/20181227/e1c3c25d/attachment.html>