Re: [stdlib-sig] [Python-Dev] core python tests
On Sat, Apr 4, 2009 at 11:52 AM, Collin Winter <collinw@gmail.com> wrote:
On Sat, Apr 4, 2009 at 7:33 AM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
Antoine Pitrou wrote:
Nick Coghlan <ncoghlan <at> gmail.com> writes:
C. Titus Brown wrote:
I vote for a separate mailing list -- 'python-tests'? -- but I don't know exactly how splintered to make the conversation. It probably belongs at python.org but if you want me to host it, I can.
If too many things get moved off to SIGs there won't be anything left for python-dev to talk about ;)
There is already an stdlib-sig, which has been almost unused.
stdlib-sig isn't *quite* right (the testing and benchmarking are as much about core python as the stdlib) - although we could view the benchmarks and tests themselves as part of the standard library...
Either way we should get it underway. Collin and Jeffrey - happy to use stdlib-sig?
Works for me.
Me too. bcc python-dev, -> stdlib-sig First question: Do people want the unladen-swallow performance tests in the CPython repository until the whole library gets moved out? If so, where? Tools/performance? Lib/test/benchmarks? Jeffrey
Le samedi 04 avril 2009 à 13:30 -0500, Jeffrey Yasskin a écrit :
bcc python-dev, -> stdlib-sig
First question: Do people want the unladen-swallow performance tests in the CPython repository until the whole library gets moved out? If so, where? Tools/performance?
Tools/performance sounds good. But it shouldn't include third-party software, otherwise I think a separate project in the sandbox would be better.
Antoine Pitrou wrote:
Le samedi 04 avril 2009 à 13:30 -0500, Jeffrey Yasskin a écrit :
bcc python-dev, -> stdlib-sig
First question: Do people want the unladen-swallow performance tests in the CPython repository until the whole library gets moved out? If so, where? Tools/performance?
Tools/performance sounds good. But it shouldn't include third-party software, otherwise I think a separate project in the sandbox would be better.
If the code can't all be contributed to the PSF it probably has to go in a separate repo. Michael
_______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
Le samedi 04 avril 2009 à 19:49 +0100, Michael Foord a écrit :
If the code can't all be contributed to the PSF it probably has to go in a separate repo.
By third party software I meant stuff such as Django. We already have external code in the repo which is probably not contributed to the PSF ;) (e.g. zlib, sqlite). My point is only that it would be bad to make the standard Python checkout much bigger only for performance testing.
hi, A possible benchmark addition could be json parsing/unparsing using the pure Python parts of the simplejson library. Other things which would be interesting to measure: - a production-grade HTTP implementation (some parts of Twisted? something else?) - something involving Unicode cheers Antoine.
Instead of benchmarking the kind of things we prefer to do in C, how about something like timing the sphinx build for the rst docs? This is something that represents a real and typical use of Python. ----- Original Message ----- From: "Antoine Pitrou" <solipsis@pitrou.net> To: "Michael Foord" <michael@voidspace.org.uk> Cc: "Collin Winter" <collinw@gmail.com>; "Michael Foord" <fuzzyman@voidspace.org.uk>; "stdlib-sig" <stdlib-sig@python.org> Sent: Saturday, April 04, 2009 5:52 PM Subject: [stdlib-sig] Benchmark suggestion
hi,
A possible benchmark addition could be json parsing/unparsing using the pure Python parts of the simplejson library.
Other things which would be interesting to measure: - a production-grade HTTP implementation (some parts of Twisted? something else?) - something involving Unicode
cheers
Antoine.
_______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
On Sat, Apr 4, 2009 at 9:01 PM, Raymond Hettinger <python@rcn.com> wrote:
Instead of benchmarking the kind of things we prefer to do in C,
CPython prefers to do some things in C because it can and doing so is faster. The other implementations can't, and I think it's a fair comparison to show the penalty that incurs. For that matter, it's useful to show how much of a win CPython gets from the extra complexity of the C extension module. If that win gets too small, it'd be nice to delete the C extension. The implication of this is that the benchmark should be able to run either the C or pure-Python implementation, independently for the two pythons being compared. The Unladen Swallow benchmarks currently aren't very good at that and should be extended. On the other hand, we already have the pickling tests, which can show some of the C/non-C difference.
how about something like timing the sphinx build for the rst docs? This is something that represents a real and typical use of Python.
Also a good benchmark.
----- Original Message ----- From: "Antoine Pitrou" <solipsis@pitrou.net> To: "Michael Foord" <michael@voidspace.org.uk> Cc: "Collin Winter" <collinw@gmail.com>; "Michael Foord" <fuzzyman@voidspace.org.uk>; "stdlib-sig" <stdlib-sig@python.org> Sent: Saturday, April 04, 2009 5:52 PM Subject: [stdlib-sig] Benchmark suggestion
hi,
A possible benchmark addition could be json parsing/unparsing using the pure Python parts of the simplejson library.
Other things which would be interesting to measure: - a production-grade HTTP implementation (some parts of Twisted? something else?) - something involving Unicode
cheers
Antoine.
_______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
_______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
-- Namasté, Jeffrey Yasskin http://jeffrey.yasskin.info/
Le samedi 04 avril 2009 à 19:01 -0700, Raymond Hettinger a écrit :
Instead of benchmarking the kind of things we prefer to do in C, how about something like timing the sphinx build for the rst docs? This is something that represents a real and typical use of Python.
Good idea indeed. We might want to only build a subset of the docs however, otherwise it's much too long :-)
participants (4)
-
Antoine Pitrou -
Jeffrey Yasskin -
Michael Foord -
Raymond Hettinger