@serhiy-storchaka, thanks for your PR! By analyzing the history of the files in this pull request, we identified @birkenfeld, @warsaw and @loewis to be potential reviewers.

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.

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.

Looks great, thanks!

GH-2297 is a backport of this pull request to the 3.6 branch.

GH-2298 is a backport of this pull request to the 3.5 branch.