Hi,

I suggest adding __float__, __int__ etc. methods

to lxml.objectify StringElement, to enable things like

>>> float(objectify.DataElement("234"))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: float() argument must be a string or a number
>>>

These will just try to invoke the very same operation on the

underlying pyval. 

Maybe there are other classes where such methods would

be helpful (BoolElement comes to mind, but I'll have to look).

Any objections? I can add this plus some tests otherwise.

Holger 

Hi,

Checked in as revision 53527:

$ svn diff -r 53526
Index: src/lxml/tests/test_objectify.py
===================================================================
--- src/lxml/tests/test_objectify.py    (revision 53526)
+++ src/lxml/tests/test_objectify.py    (working copy)
<at> <at> -815,7 +815,27 <at> <at>
         el = objectify.DataElement(s)
         val = 5
         self.assertRaises(TypeError, el.__mod__, val)
+
+    def test_type_str_as_int(self):
+        v = "1"
+        el = objectify.DataElement(v)
+        self.assertEquals(int(el), 1)
 
+    def test_type_str_as_long(self):
+        v = "1"
+        el = objectify.DataElement(v)
+        self.assertEquals(long(el), 1)
+
+    def test_type_str_as_float(self):
+        v = "1"
+        el = objectify.DataElement(v)
+        self.assertEquals(float(el), 1)
+
+    def test_type_str_as_complex(self):
+        v = "1"
+        el = objectify.DataElement(v)
+        self.assertEquals(complex(el), 1)
+
     def test_type_str_mod_data_elements(self):
         s = "%d %f %s %r"
         el = objectify.DataElement(s)
Index: src/lxml/lxml.objectify.pyx
===================================================================
--- src/lxml/lxml.objectify.pyx (revision 53526)
+++ src/lxml/lxml.objectify.pyx (working copy)
<at> <at> -773,6 +773,18 <at> <at>
     def __mod__(self, other):
         return _strValueOf(self) % other
 
+    def __int__(self):
+        return int(textOf(self._c_node))
+
+    def __long__(self):
+        return long(textOf(self._c_node))
+
+    def __float__(self):
+        return float(textOf(self._c_node))
+
+    def __complex__(self):
+        return complex(textOf(self._c_node))
+
 cdef class NoneElement(ObjectifiedDataElement):
     def __str__(self):
         return "None"


> You mean because of the int/bool duality in Python, but I don't think that's
> something we should easily enable without a compelling use case. Remember that
> it would mean converting the string value "true" to int(1), I don't think
> that's obvious behaviour.

Yes, I was referring to that:

>>> int(True)
1
>>> float(True)
1.0
>>> long(True)
1L
>>> complex
<type 'complex'>
>>> complex(True)
(1+0j)
>>>

I actually wasn't aware of that behaviour of Python booleans.
And this is definitely no priority for me. Then again, one could argue
that BoolElement should behave as much as a native bool in Python,
only that its XML representation is the string value "true".

And there are already subtleties for BoolElement:

>>> root = etree.fromstring("<root><x>true</x></root>")
>>> type(root.x)
<type 'lxml.objectify.BoolElement'>
>>> root.x.text
'true'
>>> str(root.x)
'True'
>>>


Cheers,

Holger

> I actually wasn't aware of that behaviour of Python booleans.
> And this is definitely no priority for me. Then again, one could argue
> that BoolElement should behave as much as a native bool in Python,
> only that its XML representation is the string value "true".

Hmm, I buy that. As long as the conversion is explicit, I think objectify
Elements /should/ behave as their Python counter types.

I'll check if inheriting from IntElement does the right thing.

Maybe the __int__, __float__ etc. methods should even go the

the ObjectifiedDataElement class? So basically every explicit to-number

conversion for data elements would work right out of the box, if the

corresponding pyval class supports it.

For BoolElement, you'd need t override it anyway, as str(textOf(self._c_node)) 

will not work for "true".

Holger