1.0.0 Porting Guide¶
The 0.1 through 1.0.0 releases focused on bringing in functions from yum and python-fedora. This porting guide tells how to port from those APIs to their kitchen replacements.
python-fedora¶
python-fedora |
kitchen replacement |
|
|
|
|
|
- 1
isiterable()
has changed slightly in kitchen. Theinclude_string
attribute has switched its default value fromTrue
toFalse
. So you need to change code like:>>> # Old code >>> isiterable('abcdef') True >>> # New code >>> isiterable('abcdef', include_string=True) True
yum¶
yum |
kitchen replacement |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- 2(1,2)
These yum methods provided fallback support for
gettext
functions in case eithergaftonmode
was set orgettext
failed to return an object. In kitchen, we can use thekitchen.i18n.DummyTranslations
object to fulfill that role. Please see Initializing Yum i18n for more suggestions on how to do this.- 3
The yum version of these functions returned a byte
str
. The kitchen version listed here returns aunicode
string. If you need a bytestr
simply callkitchen.text.converters.to_bytes()
on the result.- 4(1,2)
The yum version of these functions would return either a byte
str
or aunicode
string depending on what the input value was. The kitchen version always returnsunicode
strings.- 5
yum.i18n.utf8_width_chop()
performed two functions. It returned the piece of the message that fit in a specified width and the width of that message. In kitchen, you need to call two functions, one for each action:>>> # Old way >>> utf8_width_chop(msg, 5) (5, 'く ku') >>> # New way >>> from kitchen.text.display import textual_width, textual_width_chop >>> (textual_width(msg), textual_width_chop(msg, 5)) (5, u'く ku')
- 6(1,2,3)
If the yum version of
to_unicode()
orto_utf8()
is given an object that is not a string, it returns the object itself.kitchen.text.converters.to_unicode()
andkitchen.text.converters.to_bytes()
default to returning thesimplerepr
of the object instead. If you want the yum behaviour, set thenonstring
parameter topassthru
:>>> from kitchen.text.converters import to_unicode >>> to_unicode(5) u'5' >>> to_unicode(5, nonstring='passthru') 5
- 7
yum.i18n.to_str()
could return either a bytestr
. or aunicode
string In kitchen you can get the same effect but you get to choose whether you want a bytestr
or aunicode
string. Useto_bytes()
forstr
andto_unicode()
forunicode
.- 8
yum.misc.to_xml()
was buggy as written. I think the intention was for you to be able to pass a bytestr
orunicode
string in and get out a bytestr
that was valid to use in an xml file. The two kitchen functionsbyte_string_to_xml()
andunicode_to_xml()
do that for each string type.- 9
When porting
yum.i18n.exception2msg()
to use kitchen, you should setup two wrapper functions to aid in your port. They’ll look like this:from kitchen.text.converters import EXCEPTION_CONVERTERS, \ BYTE_EXCEPTION_CONVERTERS, exception_to_unicode, \ exception_to_bytes def exception2umsg(e): '''Return a unicode representation of an exception''' c = [lambda e: e.value] c.extend(EXCEPTION_CONVERTERS) return exception_to_unicode(e, converters=c) def exception2bmsg(e): '''Return a utf8 encoded str representation of an exception''' c = [lambda e: e.value] c.extend(BYTE_EXCEPTION_CONVERTERS) return exception_to_bytes(e, converters=c)
The reason to define this wrapper is that many of the exceptions in yum put the message in the
value
attribute of theException
instead of adding it to theargs
attribute. So the defaultEXCEPTION_CONVERTERS
don’t know where to find the message. The wrapper tells kitchen to check thevalue
attribute for the message. The reason to define two wrappers may be less obvious.yum.i18n.exception2msg()
can return aunicode
string or a bytestr
depending on a combination of what attributes are present on theException
and what locale the function is being run in. By contrast,kitchen.text.converters.exception_to_unicode()
only returnsunicode
strings andkitchen.text.converters.exception_to_bytes()
only returns bytestr
. This is much safer as it keeps code that can only handleunicode
or only handle bytestr
correctly from getting the wrong type when an input changes but it means you need to examine the calling code when porting fromyum.i18n.exception2msg()
and use the appropriate wrapper.
Initializing Yum i18n¶
Previously, yum had several pieces of code to initialize i18n. From the
toplevel of yum/i18n.py
:
try:.
'''
Setup the yum translation domain and make _() and P_() translation wrappers
available.
using ugettext to make sure translated strings are in Unicode.
'''
import gettext
t = gettext.translation('yum', fallback=True)
_ = t.ugettext
P_ = t.ungettext
except:
'''
Something went wrong so we make a dummy _() wrapper there is just
returning the same text
'''
_ = dummy_wrapper
P_ = dummyP_wrapper
With kitchen, this can be changed to this:
from kitchen.i18n import easy_gettext_setup, DummyTranslations
try:
_, P_ = easy_gettext_setup('yum')
except:
translations = DummyTranslations()
_ = translations.ugettext
P_ = translations.ungettext
Note
In Overcoming frustration: Correctly using unicode in python2, it is mentioned that for some
things (like exception messages), using the byte str
oriented
functions is more appropriate. If this is desired, the setup portion is
only a second call to kitchen.i18n.easy_gettext_setup()
:
b_, bP_ = easy_gettext_setup('yum', use_unicode=False)
The second place where i18n is setup is in yum.YumBase._getConfig()
in
yum/__init_.py
if gaftonmode
is in effect:
if startupconf.gaftonmode:
global _
_ = yum.i18n.dummy_wrapper
This can be changed to:
if startupconf.gaftonmode:
global _
_ = DummyTranslations().ugettext()