builtins.str (newstr) not fully PY2 compatible (str.translate)

[justinfx]

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 str.translate

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

py3 str.translate

S.translate(table) -> str

In the PY2 form, one can pass the table string and deletechars directly, while in the PY3 form one must pass an instance of str.maketrans,
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.

[jmadler]

I don't know if a design decision has been made here, and I'll defer to @edschofield.

My opinion is that the types and functions in future (not past) should mimic Py3 behavior as much as possible. Either cpython 3.7 explicitly (even as 3.8+ are released), or the latest stable version of Python.

This is because I interpret these as polyfills which are temporary shims that should be removed once the user's code can run under the newest version interpreter.

With that in mind, I'd suggest str.translate mirror the Py3 behavior, with an appropriate fixer created if needed to port the two-param use case.

[justinfx]

Based on feedback from the python porting mailing list, I ended up just making sure to never return the builtin str to the user and only use it internally in the library. Also, specifically for the use of str.translate(), I ended up doing a future.utils.PY2 check to perform the translate call for py2, and a for-loop and string replace for py3 since it apparently got slower to use translate.