Stefan Behnel added the comment:
Let's close this as outdated. New bugs for the new project should be reported
in github anyway.
--
resolution: -> out of date
status: open -> closed
___
Python tracker
STINNER Victor added the comment:
The new https://github.com/python/performance benchmark suite has a very
different design than the old https://hg.python.org/benchmarks benchmark suite:
* it now only runs benchmarks in a virtual environment
* dependencies are installed in the venv by pip
*
Stefan Behnel added the comment:
*bump* - patch pending review.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19108
___
___
Python-bugs-list
R. David Murray added the comment:
The patch looks good to me, but since I'm not familiar with perf.py I'm not a
good person to do a final review and commit it.
One trivial question: why do you check for tupleness in PythonRuntime's init?
Don't you control the input on both code paths to
Stefan Behnel added the comment:
Here's a patch that replaces the current simplistic Python executable command
config with a dedicated PythonRuntime config class. That makes it easy to
properly pass around the program specific configuration. Part of that is the
Python executable path, the
Brett Cannon added the comment:
I should mention any solution for the command-line should take a N.N value
*only* and not just 2/3 for instances where tests do not work with the latest
version of Python yet.
--
___
Python tracker
Stefan Behnel added the comment:
I'm having trouble understanding your last comment. Are you saing that you want
the exact value to be a two digits version and therefore use separate arguments
for both Pythons (e.g. --basever 2.7 --cmpver 3.3), or that you want it to
accept two digit versions
Brett Cannon added the comment:
I want to only accept major.minor version specifications; how that is done on
the command-line I don't care and leave up to you.
And yes, the version may be used in the future to disable tests that e.g. don't
work on Python 3.4 like Chameleon.
--
Stefan Behnel added the comment:
What about this: by default, we assume all runtimes to have the same major
version as the Python runtime that executes the benchmark runner. If that's not
the case, users must override it explicitly with a command line option, say,
--pyversions 2:3 for a
Brett Cannon added the comment:
If you want to propose a patch to add specifying the version on the
command-line to avoid inferring the version I would be fine with that.
--
stage: - needs patch
___
Python tracker rep...@bugs.python.org
Stefan Behnel added the comment:
Antoine, I really don't like this attitude of adding code and then saying
well, it's there, I won't change it when others complain about breakage.
Please undo your change that broke the ability of using (non-trivial) wrapper
scripts for the Python runtimes. If
Antoine Pitrou added the comment:
Antoine, I really don't like this attitude of adding code and then
saying well, it's there, I won't change it when others complain
about breakage.
Well, I don't care whether you like this attitude. Your own
attitude has irked several developers enough that
Antoine Pitrou added the comment:
Brett, I'm leaving you with this, if you're wanting to do anything about it :-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19108
___
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: -pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19108
___
___
Python-bugs-list mailing
Stefan Behnel added the comment:
I'm leaving you with this, if you're wanting to do anything about it
Sorry, but weren't you just asking *me* to be constructive?
I'm aware that getting this change right isn't trivial. But that doesn't mean
we should happily break other people's code and then
Marc-Andre Lemburg added the comment:
Wouldn't it be possible to use the old version as fallback solution
in case the -c switch approach fails or have a command line option
to pass in the version in order to bypass all of this ?
Stefan: Why don't you propose a patch which implements this ?
Roundup Robot added the comment:
New changeset 921177a65386 by Antoine Pitrou in branch 'default':
Issue #19108: fix str/bytes mismatch when raising exception under Python 3
http://hg.python.org/benchmarks/rev/921177a65386
--
nosy: +python-dev
___
Antoine Pitrou added the comment:
Ok, I've fixed the str/bytes mismatch. I don't have any strong feelings about
the rest, other than whoever wants perf.py to work with wrapper scripts should
probably propose a patch. I'll let Brett decide.
--
___
Stefan Behnel added the comment:
Well, it worked before, so the current state is clearly a regression.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19108
___
New submission from Stefan Behnel:
In changeset 88b6ef9aa9e9, a new function ported_lib() was added that crashes
on error reporting in Py3 because it tries to do this:
raise RuntimeError(Benchmark died: + err)
err is a bytes object that comes straight from the subprocess pipe.
The
20 matches
Mail list logo