Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bpo-37207: Use vectorcall for range() #18464

Merged
merged 5 commits into from Feb 18, 2020

Conversation

@encukou
Copy link
Member

encukou commented Feb 11, 2020

This continues the range() part of #13930. The complete pull request is stalled on discussions around dicts, but range() should not be controversial. (And I plan to open PRs for other parts if this is merged.)
On top of Mark's change, I unified range_new and range_vectorcall, which had a lot of duplicate code.

https://bugs.python.org/issue37207

Automerge-Triggered-By: @encukou

range_vectorcall(PyTypeObject *type, PyObject *const *args,
size_t nargsf, PyObject *kwnames)
{
size_t nargs = PyVectorcall_NARGS(nargsf);

This comment has been minimized.

Copy link
@vstinner

vstinner Feb 11, 2020

Member

Oh, I didn't expect a size_t here. I opened an issue to discuss PyVectorcall_NARGS() return type: https://bugs.python.org/issue39611

This comment has been minimized.

Copy link
@encukou

encukou Feb 18, 2020

Author Member

The return type already is Py_ssize_t. The bug was only in this patch.
(When Mark was originally writing the patch, there was a discussion of Py_ssize_t vs. size_t. Mark is a big proponent of the unsigned type, which is more correct. But also much less compatible with the existing codebase.)

@@ -71,43 +72,35 @@ make_range_object(PyTypeObject *type, PyObject *start,
range(0, 5, -1)
*/
static PyObject *
range_new(PyTypeObject *type, PyObject *args, PyObject *kw)
range_from_array(PyTypeObject *type, PyObject *const *args, size_t num_args)

This comment has been minimized.

Copy link
@vstinner

vstinner Feb 11, 2020

Member

I would prefer to use Py_ssize_t type for num_args. Usually, it's called "nargs", but I'm fine with "num_args" ;-)

This comment has been minimized.

Copy link
@encukou

encukou Feb 18, 2020

Author Member

Right, Py_ssize_t is more consistent.
But I find num_args more descriptive, so I'll keep that name.

@codecov

This comment has been minimized.

Copy link

codecov bot commented Feb 11, 2020

Codecov Report

Merging #18464 into master will increase coverage by 1.08%.
The diff coverage is n/a.

Impacted file tree graph

@@             Coverage Diff             @@
##           master   #18464       +/-   ##
===========================================
+ Coverage   82.11%   83.20%    +1.08%     
===========================================
  Files        1955     1571      -384     
  Lines      588958   414749   -174209     
  Branches    44428    44456       +28     
===========================================
- Hits       483632   345077   -138555     
+ Misses      95677    60024    -35653     
+ Partials     9649     9648        -1     
Impacted Files Coverage Δ
Lib/distutils/tests/test_bdist_rpm.py 30.00% <0.00%> (-65.00%) ⬇️
Lib/distutils/command/bdist_rpm.py 7.63% <0.00%> (-56.88%) ⬇️
Lib/test/test_urllib2net.py 76.92% <0.00%> (-13.85%) ⬇️
Lib/test/test_smtpnet.py 78.57% <0.00%> (-7.15%) ⬇️
Lib/ftplib.py 63.85% <0.00%> (-6.06%) ⬇️
Lib/test/test_ftplib.py 87.11% <0.00%> (-4.72%) ⬇️
Tools/scripts/db2pickle.py 17.82% <0.00%> (-3.97%) ⬇️
Tools/scripts/pickle2db.py 16.98% <0.00%> (-3.78%) ⬇️
Lib/test/test_socket.py 71.94% <0.00%> (-3.77%) ⬇️
Lib/test/test_asyncio/test_base_events.py 91.84% <0.00%> (-3.30%) ⬇️
... and 465 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f3e7ea5...b4559ce. Read the comment docs.

@@ -122,14 +115,14 @@ range_new(PyTypeObject *type, PyObject *args, PyObject *kw)
return NULL;
default:
PyErr_Format(PyExc_TypeError,
"range expected at most 3 arguments, got %zd",
"range expected at most 3 arguments, got %zu",
num_args);

This comment has been minimized.

Copy link
@vstinner

vstinner Feb 18, 2020

Member

It should be reset to %zd, since num_args is signed, no?

This comment has been minimized.

Copy link
@encukou

encukou Feb 18, 2020

Author Member

You're right.

Copy link
Member

vstinner left a comment

LGTM.

@miss-islington miss-islington merged commit 6e35da9 into python:master Feb 18, 2020
10 of 11 checks passed
10 of 11 checks passed
Docs
Details
Windows (x86)
Details
Windows (x64)
Details
macOS macOS
Details
Ubuntu
Details
Azure Pipelines PR #20200218.17 succeeded with issues
Details
bedevere/issue-number Issue number 37207 found
Details
bedevere/news News entry found in Misc/NEWS.d
codecov/patch Coverage not affected when comparing f3e7ea5...b4559ce
Details
codecov/project 83.20% (+1.08%) compared to f3e7ea5
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@encukou encukou deleted the encukou:vectorcall-newrange branch Feb 18, 2020
petdance added a commit to petdance/cpython that referenced this pull request Feb 19, 2020
This continues the `range()` part of python#13930. The complete pull request is stalled on discussions around dicts, but `range()` should not be controversial. (And I plan to open PRs for other parts if this is merged.)
On top of Mark's change, I unified `range_new` and `range_vectorcall`, which had a lot of duplicate code.


https://bugs.python.org/issue37207
petdance added a commit to petdance/cpython that referenced this pull request Feb 19, 2020
This continues the `range()` part of python#13930. The complete pull request is stalled on discussions around dicts, but `range()` should not be controversial. (And I plan to open PRs for other parts if this is merged.)
On top of Mark's change, I unified `range_new` and `range_vectorcall`, which had a lot of duplicate code.


https://bugs.python.org/issue37207
petdance added a commit to petdance/cpython that referenced this pull request Feb 20, 2020
This continues the `range()` part of python#13930. The complete pull request is stalled on discussions around dicts, but `range()` should not be controversial. (And I plan to open PRs for other parts if this is merged.)
On top of Mark's change, I unified `range_new` and `range_vectorcall`, which had a lot of duplicate code.


https://bugs.python.org/issue37207
petdance added a commit to petdance/cpython that referenced this pull request Feb 20, 2020
This continues the `range()` part of python#13930. The complete pull request is stalled on discussions around dicts, but `range()` should not be controversial. (And I plan to open PRs for other parts if this is merged.)
On top of Mark's change, I unified `range_new` and `range_vectorcall`, which had a lot of duplicate code.


https://bugs.python.org/issue37207
petdance added a commit to petdance/cpython that referenced this pull request Feb 20, 2020
This continues the `range()` part of python#13930. The complete pull request is stalled on discussions around dicts, but `range()` should not be controversial. (And I plan to open PRs for other parts if this is merged.)
On top of Mark's change, I unified `range_new` and `range_vectorcall`, which had a lot of duplicate code.


https://bugs.python.org/issue37207
petdance added a commit to petdance/cpython that referenced this pull request Feb 21, 2020
This continues the `range()` part of python#13930. The complete pull request is stalled on discussions around dicts, but `range()` should not be controversial. (And I plan to open PRs for other parts if this is merged.)
On top of Mark's change, I unified `range_new` and `range_vectorcall`, which had a lot of duplicate code.


https://bugs.python.org/issue37207
petdance added a commit to petdance/cpython that referenced this pull request Feb 21, 2020
This continues the `range()` part of python#13930. The complete pull request is stalled on discussions around dicts, but `range()` should not be controversial. (And I plan to open PRs for other parts if this is merged.)
On top of Mark's change, I unified `range_new` and `range_vectorcall`, which had a lot of duplicate code.


https://bugs.python.org/issue37207
petdance added a commit to petdance/cpython that referenced this pull request Feb 21, 2020
This continues the `range()` part of python#13930. The complete pull request is stalled on discussions around dicts, but `range()` should not be controversial. (And I plan to open PRs for other parts if this is merged.)
On top of Mark's change, I unified `range_new` and `range_vectorcall`, which had a lot of duplicate code.


https://bugs.python.org/issue37207
petdance added a commit to petdance/cpython that referenced this pull request Feb 21, 2020
This continues the `range()` part of python#13930. The complete pull request is stalled on discussions around dicts, but `range()` should not be controversial. (And I plan to open PRs for other parts if this is merged.)
On top of Mark's change, I unified `range_new` and `range_vectorcall`, which had a lot of duplicate code.


https://bugs.python.org/issue37207
petdance added a commit to petdance/cpython that referenced this pull request Feb 21, 2020
This continues the `range()` part of python#13930. The complete pull request is stalled on discussions around dicts, but `range()` should not be controversial. (And I plan to open PRs for other parts if this is merged.)
On top of Mark's change, I unified `range_new` and `range_vectorcall`, which had a lot of duplicate code.


https://bugs.python.org/issue37207
petdance added a commit to petdance/cpython that referenced this pull request Feb 21, 2020
This continues the `range()` part of python#13930. The complete pull request is stalled on discussions around dicts, but `range()` should not be controversial. (And I plan to open PRs for other parts if this is merged.)
On top of Mark's change, I unified `range_new` and `range_vectorcall`, which had a lot of duplicate code.


https://bugs.python.org/issue37207
petdance added a commit to petdance/cpython that referenced this pull request Feb 21, 2020
This continues the `range()` part of python#13930. The complete pull request is stalled on discussions around dicts, but `range()` should not be controversial. (And I plan to open PRs for other parts if this is merged.)
On top of Mark's change, I unified `range_new` and `range_vectorcall`, which had a lot of duplicate code.


https://bugs.python.org/issue37207
petdance added a commit to petdance/cpython that referenced this pull request Feb 21, 2020
This continues the `range()` part of python#13930. The complete pull request is stalled on discussions around dicts, but `range()` should not be controversial. (And I plan to open PRs for other parts if this is merged.)
On top of Mark's change, I unified `range_new` and `range_vectorcall`, which had a lot of duplicate code.


https://bugs.python.org/issue37207
petdance added a commit to petdance/cpython that referenced this pull request Feb 21, 2020
This continues the `range()` part of python#13930. The complete pull request is stalled on discussions around dicts, but `range()` should not be controversial. (And I plan to open PRs for other parts if this is merged.)
On top of Mark's change, I unified `range_new` and `range_vectorcall`, which had a lot of duplicate code.


https://bugs.python.org/issue37207
petdance added a commit to petdance/cpython that referenced this pull request Feb 21, 2020
This continues the `range()` part of python#13930. The complete pull request is stalled on discussions around dicts, but `range()` should not be controversial. (And I plan to open PRs for other parts if this is merged.)
On top of Mark's change, I unified `range_new` and `range_vectorcall`, which had a lot of duplicate code.


https://bugs.python.org/issue37207
petdance added a commit to petdance/cpython that referenced this pull request Feb 21, 2020
This continues the `range()` part of python#13930. The complete pull request is stalled on discussions around dicts, but `range()` should not be controversial. (And I plan to open PRs for other parts if this is merged.)
On top of Mark's change, I unified `range_new` and `range_vectorcall`, which had a lot of duplicate code.


https://bugs.python.org/issue37207
petdance added a commit to petdance/cpython that referenced this pull request Feb 21, 2020
This continues the `range()` part of python#13930. The complete pull request is stalled on discussions around dicts, but `range()` should not be controversial. (And I plan to open PRs for other parts if this is merged.)
On top of Mark's change, I unified `range_new` and `range_vectorcall`, which had a lot of duplicate code.


https://bugs.python.org/issue37207
petdance added a commit to petdance/cpython that referenced this pull request Feb 21, 2020
This continues the `range()` part of python#13930. The complete pull request is stalled on discussions around dicts, but `range()` should not be controversial. (And I plan to open PRs for other parts if this is merged.)
On top of Mark's change, I unified `range_new` and `range_vectorcall`, which had a lot of duplicate code.


https://bugs.python.org/issue37207
petdance added a commit to petdance/cpython that referenced this pull request Feb 21, 2020
This continues the `range()` part of python#13930. The complete pull request is stalled on discussions around dicts, but `range()` should not be controversial. (And I plan to open PRs for other parts if this is merged.)
On top of Mark's change, I unified `range_new` and `range_vectorcall`, which had a lot of duplicate code.


https://bugs.python.org/issue37207
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

6 participants
You can’t perform that action at this time.