bpo-29755: Fixed the lgettext() family of functions in the gettext module. by serhiy-storchaka · Pull Request #2266 · python/cpython (original) (raw)

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation8 Commits4 Checks0 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

They now always return bytes.

…dule.

They now always return bytes.

LGTM, and thanks for submitting this! Some thoughts:

I think the docs should explicitly discourage the l*() methods. I agree with your comment in the bpo-29755 that there's probably almost no utility for them in Python 3. I'm not sure we should go as far as deprecate them, but we should strong steer people clear of using them in favor of gettext() and Unicodes all the way down.
These methods should document that exceptions are now possible if the strings can't be encoded to bytes in the given codeset.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of additional suggestions were given, but I know you'll DTRT and what you have is already good, so I'll approve it in advance.

I'm interesting in your suggestions. In any case I'm going to rewrite the docs (group the l*() functions for avoiding duplications).

Grouping the l* methods sounds like a great idea. I'd probably just put a reST admonition at the top of that section. Draft text:

.. warning:
   These `l*()` methods should be avoided in Python 3, because they return encoded bytes.
   It's much better to use alternatives which return Unicode strings instead, since most Python
   applications will want to manipulate human readable text as strings instead of bytes.  Further,
   it's possible that you may get unexpected Unicode-related exceptions if there are encoding
   problems with the translated strings.  It is possible that the `l*()` methods will be deprecated
   in future Python versions due to their inherent problems and limitations.

Thank you for your review @warsaw. Please look at the updated documentation since I'm not sure about my English.

serhiy-storchaka added a commit to serhiy-storchaka/cpython that referenced this pull request

Jun 20, 2017