Re: [lxml] copy or deepcopy to detect changes?
----- Original Message ----- From: "Stefan Behnel" <stefan_ml@behnel.de> To: <lxml@lxml.de> Sent: Thursday, February 20, 2014 9:52 AM Subject: Re: [lxml] copy or deepcopy to detect changes?
Frank Millman, 20.02.2014 08:23:
I need to make a copy of an etree Element before calling a function, so that I can compare it on return to see if it has changed.
Normal assignment does not work, as the two names refer to the same object, so even if changes are made they still compare equal.
I tried copy.copy() and copy.deepcopy(), and they both seem to work. However, I ran a simple benchmark to compare the speed, and deepcopy() runs much faster than copy(), contrary to my expectation.
In lxml, copy() internally calls deepcopy(). That's an implementation detail, though, and is due to the split between the C level tree and the Python level view on it. The right thing to do is to write what you intend, not what happens to be faster in this case.
The speed difference you get might just be the internal call overhead. Deep copying is *very* fast, even though I guess you only benchmarked it with a fairly small tree anyway.
Thanks for the reply, Stefan. Actually I have just realised that everything I said above was rubbish - sorry about that. My benchmark was mistakenly copying the string version of the element, not the element itself. Ahem, I am still wrong - 'copying' a long string is quicker than 'deepcopying' it. What I was actually doing was copying a byte-encoded string. A simple test shows that python (3.3.2 in my case) is blindingly fast to 'deepcopy' a byte-encoded string, and comparatively slow to 'copy' it. Now that I am copying the actual etree Element, the speeds are fairly similar, but deepcopy is slightly slower, which is what I would expect. Sorry for the noise. Frank
participants (1)
-
Frank Millman