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_stringattribute has switched its default value fromTruetoFalse. 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
gettextfunctions in case eithergaftonmodewas set orgettextfailed to return an object. In kitchen, we can use thekitchen.i18n.DummyTranslationsobject 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 aunicodestring. If you need a bytestrsimply callkitchen.text.converters.to_bytes()on the result.- 4(1,2)
The yum version of these functions would return either a byte
stror aunicodestring depending on what the input value was. The kitchen version always returnsunicodestrings.- 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 thesimplereprof the object instead. If you want the yum behaviour, set thenonstringparameter 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 aunicodestring In kitchen you can get the same effect but you get to choose whether you want a bytestror aunicodestring. Useto_bytes()forstrandto_unicode()forunicode.- 8
yum.misc.to_xml()was buggy as written. I think the intention was for you to be able to pass a bytestrorunicodestring in and get out a bytestrthat 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
valueattribute of theExceptioninstead of adding it to theargsattribute. So the defaultEXCEPTION_CONVERTERSdon’t know where to find the message. The wrapper tells kitchen to check thevalueattribute for the message. The reason to define two wrappers may be less obvious.yum.i18n.exception2msg()can return aunicodestring or a bytestrdepending on a combination of what attributes are present on theExceptionand what locale the function is being run in. By contrast,kitchen.text.converters.exception_to_unicode()only returnsunicodestrings andkitchen.text.converters.exception_to_bytes()only returns bytestr. This is much safer as it keeps code that can only handleunicodeor only handle bytestrcorrectly 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()