Test case: https://gist.github.com/2225789
You will see first schema does not have selected value in output html, while second example does.
From SelectWidget doctstring:
A sequence of two-tuples (both values must be **string** or
**unicode** values) indicating allowable, displayed values,
e.g. ``( ('true', 'True'), ('false', 'False') )``. The first
element in the tuple is the value that should be returned when
the form is posted. The second is the display value.
I guess it'd be helpful to add a type check in SelectWidget.__init__. I've been bitten by this myself.
What would be the reason not to convert it to unicode if parameter is not instance of basestring?
I wouldn't be against converting a subset of types to str automagically (int is the only one I can really think of right now), but I wouldn't want the thing to try to convert any-old-thing to str, because that logic gets really desperate after a while and would end up causing even more confusion.
Allow the use of Integer values with SelectWidget. Fixes #81.
Added a test to deformdemo in Pylons/deformdemo@740ae1f
Argh, silly. My fix will break when first value is non-ascii unicode. Will fix tomorrow.
I will nevertheless accept the compliment. ;-)
A better fix for #81: don't break with non-ascii strings as values.
Allows use of Integer values with RadioChoiceWidget. Related to commit …
…494db2b and #81.
Note there was a similar problem with RadioChoiceWidget, that the above commit patches.
This turned out to be a bad idea, because for template code like this:
<option tal:repeat="(value, description) values"
tal:attributes="selected value in cstruct and 'selected';
the 'value' above will be a string after normalization while the item in cstruct might be an integer. This is kind of a clusterfuck at this point because it was done so long ago, but I may need to revert it, because I can't think of a sane way to leave it the way it is.
Nope, it's even more clusterfucked than just reverting. I'll keep it as-is for now and cope.