[lxml-dev] 2.1beta questions: objectify.XML, objectify.parse base_url arg, deprecate enableRecursiveStr, etree.tounicode()
Hi, I guess the module functions XML() and parse() should also support the base_url arg? Also, I suppose enableRecursiveStr() could be removed? Btw I realized that etree.tounicode() is bound to be deprecated in favor of tostring(..., encoding=unicode). I suppose this is owed to ElementTree API compat which doesn't have tounicode() - or is this a py3k issue? IMHO unicode is not an encoding and from my experience it confuses people starting out with unicode to think of unicode as an encoding. That said, I rather like the tostring()/tounicode() distinction API-wise, if purely for documentational purposes. I'm not at all questioning the possibility to produce a unicode serialization of an XML tree: This is really helpful in lxml as it enables one to fallback to python encoding capabilities if libxml2 does not support some intended target encoding. Holger -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
Hi Holger, looks like you started cleaning up. :) Holger Joukl wrote:
I guess the module functions XML() and parse() should also support the base_url arg?
Yes.
Also, I suppose enableRecursiveStr() could be removed?
I never really liked it, but why would you want to remove it?
Btw I realized that etree.tounicode() is bound to be deprecated in favor of tostring(..., encoding=unicode).
Yes. Having a second function for a more limited functional scope is just superfluous. BTW, does that affect objectify in any way or is it just curiosity (or users interest) on your side?
I suppose this is owed to ElementTree API compat which doesn't have tounicode() - or is this a py3k issue?
Actually, the "encoding=unicode" bit has a Py3k issue. In Py3, you have to say "encoding=str" instead...
IMHO unicode is not an encoding and from my experience it confuses people starting out with unicode to think of unicode as an encoding.
If you start with unicode, I think this is your smallest problem. You are right that it's not an encoding and I admit that this might look a little hackish if you think about it. However, a unicode string is a well-defined way of representing the data, and it replaces the byte encoding that you'd normally get from the tostring() function. So it fits into the existing API quite well.
I'm not at all questioning the possibility to produce a unicode serialization of an XML tree:
This is really helpful in lxml as it enables one to fallback to python encoding capabilities if libxml2 does not support some intended target encoding.
... although you'd have to take care that you strip the encoding declaration. My favourite use case are actually doctests. Stefan
Hi Stefan,
looks like you started cleaning up. :)
Quite right. I started having a bad conscience for never really looking at 2.1 for quite a while. Works smoothly for me for all I can tell.
Holger Joukl wrote:
I guess the module functions XML() and parse() should also support the base_url arg?
Yes.
Implemented on trunk, revision 56201. I stole the unittests from test_etree and noticed that I also had to special case 'base' in objectify's __setattr__ magic.
Also, I suppose enableRecursiveStr() could be removed?
I never really liked it, but why would you want to remove it?
I put it the wrong way: There's already enable_recursive_str() which should be used instead. I for one actually *need* it, so I do like it :) But some other of the old CamelCase method/function names went away, so I figured this can also go.
Btw I realized that etree.tounicode() is bound to be deprecated in favor of tostring(..., encoding=unicode).
Yes. Having a second function for a more limited functional scope is just superfluous.
BTW, does that affect objectify in any way or is it just curiosity (or users interest) on your side?
No, just curiosity. I currently use tounicode() for what I outlined (fallback to python encoding capabilities) but can just as well switch to the new conventions.
I suppose this is owed to ElementTree API compat which doesn't have tounicode() - or is this a py3k issue?
Actually, the "encoding=unicode" bit has a Py3k issue. In Py3, you have to say "encoding=str" instead...
How do you specify which actual encoding, e.g 'ISO-8859-15', here?
IMHO unicode is not an encoding and from my experience it confuses people starting out with unicode to think of unicode as an encoding.
If you start with unicode, I think this is your smallest problem.
You are right that it's not an encoding and I admit that this might look a little hackish if you think about it. However, a unicode string is a well-defined way of representing the data, and it replaces the byte encoding that you'd normally get from the tostring() function. So it fits into the existing API quite well.
lxml is just a fine design. So even smallest deviations in the realms of hackishness provoke protest storms ;). Just joking, and maybe I'm being anal about it but it still feels a little uncomfortable to hand in s.th. that it isn't an encoding to a parameter that is named 'encoding', if only from an educational perspective. Not that I can't live with it, especially since I can't think of an good alternative... Yet another parameter to tostring() feels awkward, and renaming the parameter conflicts with ElementTree compatibility. Holger -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
Hi Holger, jholg@gmx.de wrote:
I started having a bad conscience for never really looking at 2.1 for quite a while.
Works smoothly for me for all I can tell.
Glad to hear that.
I guess the module functions XML() and parse() should also support the base_url arg?
Implemented on trunk, revision 56201. I stole the unittests from test_etree and noticed that I also had to special case 'base' in objectify's __setattr__ magic.
Thanks!
Also, I suppose enableRecursiveStr() could be removed? I never really liked it, but why would you want to remove it?
some other of the old CamelCase method/function names went away, so I figured this can also go.
Yep, please do so.
I suppose this is owed to ElementTree API compat which doesn't have tounicode() - or is this a py3k issue? Actually, the "encoding=unicode" bit has a Py3k issue. In Py3, you have to say "encoding=str" instead...
How do you specify which actual encoding, e.g 'ISO-8859-15', here?
Same as before. You get a byte string when you pass an encoding name, and a unicode string (str type) when you pass str. That's also something I like about the new interface.
Yet another parameter to tostring() feels awkward, and renaming the parameter conflicts with ElementTree compatibility.
It would also require a bit more parameter checking and exception raising. The unicode option and the encoding are mutually exclusive, and unicode is not so far from an encoding that it would really merit an option on its own. Note also that you do not pass "Unicode" as a string but the unicode type, and you get a unicode object back. Stefan
Also, I suppose enableRecursiveStr() could be removed? I never really liked it, but why would you want to remove it?
some other of the old CamelCase method/function names went away, so I figured this can also go.
Yep, please do so.
Done, revision 56229. -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
Hi Stefan,
It would also require a bit more parameter checking and exception raising. The unicode option and the encoding are mutually exclusive, and unicode is not so far from an encoding that it would really merit an option on its own.
Note also that you do not pass "Unicode" as a string but the unicode type, and you get a unicode object back.
I took the liberty to modify the documentation a tiny little bit to reward this behaviour: $ svn diff -rPREV doc/parsing.txt Index: doc/parsing.txt =================================================================== --- doc/parsing.txt (revision 56229) +++ doc/parsing.txt (working copy) @@ -675,8 +675,8 @@ >>> etree.tostring(root, encoding='UTF-8', xml_declaration=False) b'<test> \xef\xa3\x91 + \xef\xa3\x92 </test>' -As an extension, lxml.etree recognises the unicode type as encoding to -build a Python unicode representation of a tree: +As an extension, lxml.etree recognises the unicode type as an argument to the +encoding parameter to build a Python unicode representation of a tree: .. sourcecode:: pycon I think this subtly documents that unicode is not an encoding, strictly speaking. Holger -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
participants (3)
-
Holger Joukl -
jholg＠gmx.de
-
Stefan Behnel