[lxml-dev] objectify parses 't' and 'f' as BoolElement?

[Stefan Behnel]

Hi Holger,

jholg at gmx.de wrote:
> somewhere on the way between lxml 2.0 and 2.1.5 objectify changed to
> accept 't' and 'f' as values recognized as BoolElements:
> 
> 2.0.alpha4:
> 0 $ python2.4 -i -c 'from lxml import etree, objectify;  objectify.enableRecursiveStr(); print etree.__version__; print etree.LIBXML_VERSION, etree.LIBXSLT_VERSION'
> 2.0.alpha4
> (2, 6, 27) (1, 1, 20)
>>>> root = objectify.fromstring('<root><bool>f</bool></root>')
>>>> print root
> root = None [ObjectifiedElement]
>     bool = 'f' [StringElement]
>>>> root.bool.text
> 'f'
> 
> 2.1.5:
> 0 $ python2.4 -i -c 'from lxml import etree, objectify; objectify.enable_recursive_str(); print etree.__version__; print etree.LIBXML_VERSION, etree.LIBXSLT_VERSION'
> 2.1.5
> (2, 6, 32) (1, 1, 23)
>>>> root = objectify.fromstring('<root><bool>f</bool></root>')
>>>> print root
> root = None [ObjectifiedElement]
>     bool = False [BoolElement]
> 
> 
> I consider this a bug, XML Schema datatypes spec says
> "
> 3.2.2 boolean
> 
> [Definition:]  boolean has the ·value space· required to support the mathematical concept of binary-valued logic: {true, false}.
> 
> 3.2.2.1 Lexical representation
> 
> An instance of a datatype that is defined as ·boolean· can have the following legal literals {true, false, 1, 0}. 
> ...
> "
> 
> Objections to restricting this to said literals, again?

No. I don't think something as short as 'f' and 't' is worth being
considered a boolean value by default.

Note that '0' and '1' will never be considered boolean unless there is a
type hint, so the only literals that will become boolean by default are
'true' and 'false'.

If there really is code that depends on t/f, you can get the old behaviour
by registering a custom PyType for BoolElement before the "bool" type. This
is a global configuration and is backwards compatible, so this isn't much
of a problem for users.

Can you do the change and add a comment on this to the changelog?

Stefan