On Sat, Jul 25, 2009 at 07:38:57PM +0200, John Wright wrote: > I'm actually inclined to turn off using apt_pkg by default. It's > definitely faster, typically by a factor between 2 and 2.5, but we > keep running into weird corner cases with the way apt_pkg parses > things. <snip> > Clearly, using shared storage (which basically just means using > apt_pkg's parser.Section directly) is blazingly fast compared to > without. But this is aready not the default, since it has the > confusing side-effect of making the object returned by each > iteration (each of which has a different id) actually share the same > data. > > Is anybody strongly opposed to making iter_paragraphs not use > apt_pkg by default? I'm still trying to figure out a way to salvage > the output from apt_pkg in this case, but I'm not having much luck.
I'm not against changing the default. However, I'm against making it difficult / undocumented how to use apt_pkg + shared storage. I do care about runtimes but I want to retain the nice data structures of deb822 nevertheless (i.e. please not make me use python-apt all alone). What it might make sense then is to have different top level functions, with one maybe marked "fast" and well documenting that it has potential drawback. The other can safely be our, slower, default. Just my 0.02€ -- Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7 z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature