[lxml-dev] 2.0 ElementTree 1.3 compat: getiterator

FWIW I just took a quick look at ElementTree 1.3alpha, and: # compatibility (FIXME: preserve list behaviour too? see below) getiterator = iter getiterator() is (currently) an iterator (generator), just as it was in lxml pre-2.0. I remember some discussion on this list with regard to that. I for one think it counter-intuitive for getiterator() to return a list, so I think lxml got that right in the first place. Holger -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

jholg@gmx.de wrote:
According to Fredrik's SVN, he hasn't been working on ET 1.3 since our last discussion. The idea was that getiterator() returned a list in older ET versions, while the docs said something like "returns an iterable: either an iterator or a list". lxml always returned an iterator here. Since we now have iter() in place, Fredrik suggested that reverting getiterator() to the original behaviour would be the cleanest solution. I actually agree with that, but I am still waiting for Fredrik to actually make that change official.
I for one think it counter-intuitive for getiterator() to return a list, so I think lxml got that right in the first place.
I would agree from the point of view of the method name, but disagree for reasons of API redundancy and backwards compatibility. Stefan

Thanks for the clarification. I see, but from an lxml point of view we are actually losing backwards compatibility, aren't we ;-) Holger -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

jholg@gmx.de wrote:
Sure, but this is 2.0 :) I actually hope that the change isn't as big as it sounds. In most cases, a list behaves as good as any other iterable, think of for child in el.getiterator() Obviously, the performance is different in some use cases, but that will only matter if you are interested in, say, 5 out of 100 elements, or if you iterate over really big trees where you cannot afford having all proxies in memory. Fredriks original intention was to deprecate getiterator() in favour of iter() and I think reverting it to returning a list (as ET did for ages) is a better alternative here. Anyway, as I said, I'm currently waiting for Fredrik to implement this in ET to make the change official in a new release - then we can say: sorry, we're only following ET's evolution... :) Stefan

jholg@gmx.de wrote:
According to Fredrik's SVN, he hasn't been working on ET 1.3 since our last discussion. The idea was that getiterator() returned a list in older ET versions, while the docs said something like "returns an iterable: either an iterator or a list". lxml always returned an iterator here. Since we now have iter() in place, Fredrik suggested that reverting getiterator() to the original behaviour would be the cleanest solution. I actually agree with that, but I am still waiting for Fredrik to actually make that change official.
I for one think it counter-intuitive for getiterator() to return a list, so I think lxml got that right in the first place.
I would agree from the point of view of the method name, but disagree for reasons of API redundancy and backwards compatibility. Stefan

Thanks for the clarification. I see, but from an lxml point of view we are actually losing backwards compatibility, aren't we ;-) Holger -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

jholg@gmx.de wrote:
Sure, but this is 2.0 :) I actually hope that the change isn't as big as it sounds. In most cases, a list behaves as good as any other iterable, think of for child in el.getiterator() Obviously, the performance is different in some use cases, but that will only matter if you are interested in, say, 5 out of 100 elements, or if you iterate over really big trees where you cannot afford having all proxies in memory. Fredriks original intention was to deprecate getiterator() in favour of iter() and I think reverting it to returning a list (as ET did for ages) is a better alternative here. Anyway, as I said, I'm currently waiting for Fredrik to implement this in ET to make the change official in a new release - then we can say: sorry, we're only following ET's evolution... :) Stefan
participants (2)
-
jholg@gmx.de
-
Stefan Behnel