On Sat, 1 Sep 2012 18:10:34 -0400 Brett Cannon <br...@python.org> wrote: > True, but having to carry around multiple copies of libraries just becomes > a pain.
Apart from the initial pain of adding code to deal with multiple copies, I don't see how painful "carrying" copies can be. It's not like you have to physically carry the files :) > > > If we can't find a reasonable way to handle all of this then what I will > > do > > > is branch the unladen benchmarks for 2.x/3.x benchmarking, and then > > create > > > another branch of the benchmark suite to just be for Python 3.x so that > > we > > > can start fresh with a new set of benchmarks that will never change > > > themselves for benchmarking Python 3 itself. > > > > Why not simply add Python 3-specific benchmarks to the mix? > > You can then create a "py3" benchmark suite in perf.py (and perhaps > > also a "py2" one). > > > > To avoid historical baggage and to start from a clean slate. I don't > necessarily want to carry around Python 2 benchmarks forever. It's not a > massive concern, just a nicety. We can decide to remove some benchmarks when they become too old. It's no reason to fork a separate development branch, though. Most of the current benchmarks already run under 3.x so you would just duplicate maintenance work. Regards Antoine. -- Software development and contracting: http://pro.pitrou.net _______________________________________________ Speed mailing list Speed@python.org http://mail.python.org/mailman/listinfo/speed
