This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients brett.cannon, pitrou, scoder
Date 2013-03-29.18:12:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1364580511.3616.8.camel@localhost.localdomain>
In-reply-to <1364580525.46.0.514763310375.issue17573@psf.upfronthosting.co.za>
Content
> I'm ok with the conditional import for ET, although I don't see a
> reason to exclude it. Why not be able to compare the performance of
> both implementations as well? There's a slowpickle benchmark, for
> example.

It made sense in 2.7 where both implementations were visibly selectable
(and the pure Python ones were arguably the "default" choice since their
names were less obtuse). But in 3.3 the C accelerator is automatically
enabled when importing xml.etree. So I don't think making a difference
makes much sense anymore.

> So, what about only testing cET by default and adding an explicit
> option "--etree-module=package.module" to change the imported module,
> e.g. "--etree-module=lxml.etree" to benchmark lxml or
> "--etree-module=cElementTree" to benchmark a separately installed 3rd
> party cET package?

Well, we could still add a "lxml" benchmark but disable it by default (I
mean not make it part of the main sub-suites). That way people can run
it explicitly if they want.

(also, since it's a "lxml" benchmark, it may test other things than
simply the etree API, if you like)
History
Date User Action Args
2013-03-29 18:12:59pitrousetrecipients: + pitrou, brett.cannon, scoder
2013-03-29 18:12:59pitroulinkissue17573 messages
2013-03-29 18:12:59pitroucreate