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>