Message class shadows built-in 'translate'

[Ben Nemec]

Python's unicode types already define a function named 'translate'[0]. If someone tries to call that on a Message object, they get our version of it which generally takes a different type of input parameter. This results in bugs like [1].

Ideally we would just rename our version of it, but since it's part of the public API of the library that could be problematic (although we should look into it anyway). As a partial workaround we can check the type of the input parameter, and if it's a type we can't handle we can pass it to the superclass's version of translate.

0: https://docs.python.org/3/library/stdtypes.html#str.translate
1: https://storyboard.openstack.org/#!/story/2004657

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/679092

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/679321

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/679092
Committed: https://git.openstack.org/cgit/openstack/oslo.i18n/commit/?id=f8fa059c46fed84514004ece7dccacf6380cf263
Submitter: Zuul
Branch: master

commit f8fa059c46fed84514004ece7dccacf6380cf263
Author: Ben Nemec <email address hidden>
Date: Wed Aug 28 15:07:53 2019 +0000

    Allow Message.translate to handle unhashable inputs

    We made a mistake with the API of the Message class and shadowed the
    built-in function 'translate' from the unicode class that it inherits
    from. This means that our translate may be called with things like
    dicts and lists that are not hashable, which is problematic because
    we use that value as a dict key. Unhashable types are not allowed as
    dict keys so this fails.

    While ideally we would address this shadowing by renaming our version
    of translate, it is part of the public API of the library and thus
    we can't just change it arbitrarily. As a partial fix, this change
    adds a type check on the input parameter, and if it finds a type
    other than a string it calls the superclass's implementation of
    translate instead. This should handle most common uses of the stdlib
    translate, but since technically it is possible to use a string as
    input to that as well it doesn't fully address the problem.

    Change-Id: Ie68cba6af19d11de8968ee80ac10107f488acb92
    Partial-Bug: 1841796

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/679321
Committed: https://git.openstack.org/cgit/openstack/oslo.i18n/commit/?id=22499258465e4606e234f8aad99e56338b3e0722
Submitter: Zuul
Branch: master

commit 22499258465e4606e234f8aad99e56338b3e0722
Author: Ben Nemec <email address hidden>
Date: Thu Aug 29 19:10:42 2019 +0000

    Deprecate Message.translate in favor of Message.translation

    It shadows the unicode function of the same name, and there's no
    way to entirely disambiguate the two based on the parameter passed
    in. This change deprecates Message.translate and makes it a wrapper
    around the new function, Message.translation.

    Note that we never documented calling Message.translate directly.
    The documented way to get the translated form of a Message is to call
    the _translate.translate function in this project, so chances are
    that this public API change will have little actual impact on users.

    Change-Id: I0c617937f5af7467d1454f72acd0474ae2ce0293
    Closes-Bug: 1841796

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/oslo.i18n 3.25.0 release.