[lxml-dev] Work on branch "lxml-scoder1"

Stefan Behnel wrote:
I forgot to say that these two depend on each other.
Then: (r18899) support for namespace classes
(r18903) incorporates a change from patch in 18899: I removed the class registry from ElementTree to keep it only at module level. This is actually more of a preparation for (r18907), where I saw that it doesn't really make sense to keep that functionality in _ElementTree. The next one is independent of the other patches: (r18904/5) (fix for a) fix for the bug reported by Carlos Pita And finally, I applied my big final patch that does the restructuring for ElementTree compliance. I first applied a partial patch with the test cases that compare ElementTree and etree to motivate the change. That's in (r18906). (r18907) contains the changes. It is so big because the structural modification required a significant bit of refactoring to adapt the rest of the implementation to the semantic changes. This revision passes the original test cases as well as the ones added in (r18906). I cc-ed the mailing list as I would really appreciate it if other people could test this branch, especially the final modifications. I'm specifically concerned about memory handling and this kind of stuff. There are not really any test cases for this, but I guess they are rather tricky to write. So please, test! :) For the volunteers: svn co http://codespeak.net/svn/lxml/branch/scoder1 lxml-scoder1 gives you a checkout of my branch into the directory lxml-scoder1. Stefan

Stefan Behnel a écrit :
I've just checked it out, ran the tests and used it on some toy test cases with no problem. Don't have the time to dig further though. About memory handling you might be interested in the following Google Summer of Code project about memory profiling: https://codespeak.net/svn/user/nick8325/sizer/ Best, -- Olivier

Olivier Grisel schrieb:
Thanks for testing. It's important for me to know if the new code breaks anything in the way people use it in their projects.
And thanks for the link, but according to the tutorial page: ---------------- What the profiler does: It can record information about all reachable objects at some point in time, and has functions to analyse that information. It knows about all built-in types, but none that are defined in extension modules. ---------------- ... so the last line means it doesn't help to debug C extensions like lxml.etree. Thanks anyway, Stefan

Hey Stefan, Finally getting around to looking through your patches -- the simple ones first. Stefan Behnel wrote:
Okay, committed to the trunk now.
(r18894) _Element.getparent()
Committed to the trunk, with the difference that I made it a property 'parent', not a 'getparent()' function. I think a property is a bit nicer here. Regards, Martijn

Martijn Faassen wrote:
We actually had this discussion on the list recently and I argued that getchildren() returns nodes just like getparent(), while all properties of _Element return actual properties of the element itself, i.e. attributes, tag name, etc. So just for consistency I'd relly prefer a function here. Stefan

Stefan Behnel a écrit :
I've just checked it out, ran the tests and used it on some toy test cases with no problem. Don't have the time to dig further though. About memory handling you might be interested in the following Google Summer of Code project about memory profiling: https://codespeak.net/svn/user/nick8325/sizer/ Best, -- Olivier

Olivier Grisel schrieb:
Thanks for testing. It's important for me to know if the new code breaks anything in the way people use it in their projects.
And thanks for the link, but according to the tutorial page: ---------------- What the profiler does: It can record information about all reachable objects at some point in time, and has functions to analyse that information. It knows about all built-in types, but none that are defined in extension modules. ---------------- ... so the last line means it doesn't help to debug C extensions like lxml.etree. Thanks anyway, Stefan

Hey Stefan, Finally getting around to looking through your patches -- the simple ones first. Stefan Behnel wrote:
Okay, committed to the trunk now.
(r18894) _Element.getparent()
Committed to the trunk, with the difference that I made it a property 'parent', not a 'getparent()' function. I think a property is a bit nicer here. Regards, Martijn

Martijn Faassen wrote:
We actually had this discussion on the list recently and I argued that getchildren() returns nodes just like getparent(), while all properties of _Element return actual properties of the element itself, i.e. attributes, tag name, etc. So just for consistency I'd relly prefer a function here. Stefan
participants (3)
-
Martijn Faassen
-
Olivier Grisel
-
Stefan Behnel