Some components raise unrelated exceptions during rpdb session due to
unaware attribute handling of file-like objects
Change-Id: I04dd5a7d0f6ec2920671dfa612439427dffefd52
Closes-bug: #1791104
I have improved the readability of the code by fixing the
problems that flake8 reported.
The type of errors that are fixed are:
* H302 - Import only module
* H305 - Import not grouped correctly
* H307 - Like imports shoud be grouped together
* H402 - One line docstring needs punctation
* F821 - Undefined name
Change-Id: I3a7f12120b6a99342a3d2025206edcdc0f6a4a93
Signed-off-by: Costin Galan <cgalan@cloudbasesolutions.com>
Rather than have the tests guess how many times
sys.getfilesystemencoding is going to be called, narrow the mock to
just the encodeutils module.
Change-Id: Ia52d4f380e4053e8962ce9dfc674e732baa167fb
The function replaces a very common pattern in code base supporting
Python 2 and Python 3:
if isinstance(text, six.text_type):
text = text.encode('utf-8')
to_utf8() accepts subtypes of bytes and six.text_type. For example,
oslo.i18n Message objects are accepted and encoded to UTF-8 as
expected.
Using encodeutils.safe_encode(text) is not reliable because it relies
on the current locale encoding which can be ASCII, whereas UTF-8 is
expected. Having to write encodeutils.safe_encode(text,
incoding='utf-8') is not obvious and error-prone (it's easy to forget
the incoming parameter).
Change-Id: I00463716b6012cbef383855999f63f99f2f52540
Some parts of the code have been annoted with "# nosec" as they made bandit
raise false positives.
Change-Id: I9d8a8ab79e8b5de98e7d291ac132f8971a44216d
Document in which version new types and functions were added using
".. versionadded:: x.y". Document changes using
".. versionchanged:: x.y."
For new modules, add the versionadded tag in the module top
docstring, not on each type/function.
Add fileutils to documentation. The doc part was forgotten during the
graduation.
Add docstrings to convert versions of versionutils.
I used "git blame" + "git tag --contains=SHA1" to find these version,
and then I checked manually each version.
Change-Id: Ia2f00aa29eb36410a49fc1d350896a569a7737a1
Message instances created by oslo_i18n are subclasses of the Unicode
type (unicode on Python 2, str on Python 3) and have no __unicode__()
method. exception_to_unicode() raises an AttributeError when trying to
convert it to Unicode.
This change fixes this issue and adds an unit test.
Change-Id: Ica67429ac64f74e5c636b6d74d71910a26511378
There is no simple way working on Python 2 and Python 3 to get the
message of an exception as a Unicode string. This new functions uses an
heuristic to get the encoding of the exception message. It tries UTF-8
(which is a superset of ASCII), the locale encoding, or fallback to
ISO-8859-1 (which never fails).
This function is required to log exceptions using the logging module
when the exception message contains non-ASCII characters.
- logging.log() only works with non-ASCII characters on Python 2 and
Python 3 if the message is formatted as Unicode. For example,
logging.log(b'error: %s', b'\xe9') fails in most cases.
- unicode % bytes doesn't work with non-ASCII characters
- logging.log(u'error: %s', exc) doesn't work if the exception message
contains a non-ASCII character
Only logging.log(u'error: %s', exception_to_unicode(exc)) works in all
cases: ASCII or non-ASCII exception message, Python 2 and Python 3.
Co-Authored-By: Joshua Harlow <harlowja@gmail.com>
Change-Id: I241b7c81c7ae3d26f81790e9180678dc9af81e22
Move the public API out of oslo.utils to oslo_utils. Retain the ability
to import from the old namespace package for backwards compatibility for
this release cycle.
bp/drop-namespace-packages
Change-Id: Ic6dd62097399bf75e3d11b4d8a6400971069c415
