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-29548: Recommend PyObject_Call APIs over PyEval_Call APIs. #75

Merged
merged 1 commit into from
Mar 14, 2017

Conversation

methane
Copy link
Member

@methane methane commented Feb 13, 2017

PyEval_Call* APIs are not documented and they doesn't respect PY_SSIZE_T_CLEAN.
So add comment block to recommend them where PyEval_Call APIs are declared.

This commit also changes PyEval_CallMethod and PyEval_CallFunction implementation
same to PyObject_CallMethod and PyObject_CallFunction.

PyEval_CallFunction(callable, "i", (int)i) now calls callable(i) instead of raising TypeError.

I expect this allows compiler to share some code between PyEval_CallFunction and PyObject_CallFunction. But I'm not sure.


[bpo-29548]

Include/ceval.h Outdated

/* Inline this */
/* Deprecated from Python 3.7: Use PyObject_CallObject() instead. */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

did you ment Use PyObject_Call() it seem like this patch remove PyObject_CallObject ... Autocompleter got a bit overzealous ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This patch deprecates PyEval_CallObject, not PyObject_CallObject.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, sorry, I got confused with the unified diff and above comment, the proximity of PyObject_Call() and PyObject_CallObject() made me think you had an Object too much in the comment.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are so many similar call APIs.
That's why I think we should deprecate undocumented and less used APIs.

@methane methane changed the title bpo-29548: deprecate PyEval_Call APIs. bpo-29548: Stop using PyEval_Call* APIs. Feb 14, 2017
@codecov
Copy link

codecov bot commented Feb 14, 2017

Codecov Report

❗ No coverage uploaded for pull request base (master@c33ee85). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #75   +/-   ##
=========================================
  Coverage          ?   82.38%           
=========================================
  Files             ?     1428           
  Lines             ?   351138           
  Branches          ?        0           
=========================================
  Hits              ?   289281           
  Misses            ?    61857           
  Partials          ?        0

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 c33ee85...76737a6. Read the comment docs.

@methane methane force-pushed the deprecate-evalcall branch 2 times, most recently from 04111c1 to 7b1dd6e Compare February 14, 2017 15:13
@vstinner
Copy link
Member

Sorry but I'm confused by the PR title and the commit messages. They don't describe exactly what I see in the code. Can you please update them?

@methane methane changed the title bpo-29548: Stop using PyEval_Call* APIs. bpo-29548: Recomend PyObject_Call APIs over PyEval_Call* APIs. Feb 16, 2017
@methane
Copy link
Member Author

methane commented Feb 16, 2017

I updated pull request title and body.

@ncoghlan ncoghlan changed the title bpo-29548: Recomend PyObject_Call APIs over PyEval_Call* APIs. bpo-29548: Recommend PyObject_Call APIs over PyEval_Call* APIs. Feb 19, 2017
Copy link
Contributor

@ncoghlan ncoghlan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the PyEval_*/PyObject_* functions that are now duplicates, it would be useful to have block comments explaining the equivalence, and the fact the redundant definitions are being kept around for backwards compatibility reasons.

@methane
Copy link
Member Author

methane commented Feb 28, 2017

@Haypo Would you review this again?

Objects/call.c Outdated
return PyObject_Call(callable, args, kwargs);
}


PyObject *
PyObject_CallObject(PyObject *callable, PyObject *args)
{
return PyEval_CallObjectWithKeywords(callable, args, NULL);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand why you change the code in this commit, and 2 commits later reverts this change. You should practice git rebase -i HEAD~4 to merge the two commits maybe?

Objects/call.c Outdated
}

if (!PyTuple_Check(args)) {
if (args != NULL && !PyTuple_Check(args)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please update the commit message which doesn't make sense compared to the modified code.

This commit fixes a bug, no? It makes sure that a TypeError is raised if kwargs is not a dictionary, right? Please explain it in the commit message.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I remove this bugfix for now and update #87 instead.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done. I created split issue for #87.

Objects/call.c Outdated
if (kwargs != NULL && !PyDict_Check(kwargs)) {
PyErr_SetString(PyExc_TypeError,
"keyword list must be a dictionary");
return NULL;
}

if (args == NULL) {
return _PyObject_FastCallDict(callable, NULL, 0, kwargs);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe use an else here?

@@ -942,22 +948,14 @@ PyObject_CallFunction(PyObject *callable, const char *format, ...)
PyObject *
PyEval_CallFunction(PyObject *callable, const char *format, ...)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

commit message: this change also optimizes PyEval_CallFunction() and PyEval_CallMethod() to avoid temporary tuple when possible.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Main purpose is reducing maintenance cost rather than optimization.
There are very few callers in the world.

I hope compiler can remove duplicated code too, but I'm not sure.

Include/ceval.h Outdated
@@ -7,6 +7,10 @@ extern "C" {

/* Interface to random parts in ceval.c */

/* PyObject_Call(), PyObject_CallFunction(), and PyObject_CallMethod()
* are documented and recommended API to call callable objects.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand the "are documented" part, maybe remove it?

I suggest to be more explicit:

" PyEval_CallObjectWithKeywords() is kept for backward compatibility: PyObject_Call(), PyObject_CallFunction() and PyObject_CallMethod() are recommended to call a callable object."

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@vstinner
Copy link
Member

I'm not confortable yet with GitHub to review commit messages :-/ It's not easy to comment the commit message: I also suggest to add "bpo-29548" to commit messages (at least to one commit message).

@methane methane changed the title bpo-29548: Recommend PyObject_Call APIs over PyEval_Call* APIs. bpo-29548: Recommend PyObject_Call APIs over PyEval_Call APIs. Mar 1, 2017
@methane
Copy link
Member Author

methane commented Mar 1, 2017

I'm not confortable yet with GitHub to review commit messages :-/ It's not easy to comment the commit message:

I agree. I like Gerrit for this.

I also suggest to add "bpo-29548" to commit messages (at least to one commit message).

Final commit message is written when pushing "Squash and merge" button.
So I updated pull request title and body. The title will be first line of commit message, and the body follows.

I hope it works as poor man's Gerrit for a while, until we have new tool to build Misc/NEWS.

@methane methane force-pushed the deprecate-evalcall branch 2 times, most recently from 3272dba to e17b495 Compare March 1, 2017 09:26
PyEval_Call* APIs are not documented and they doesn't respect PY_SSIZE_T_CLEAN.
So add comment block to recommend PyObject_Call* APIs where they are declared.

This commit also changes PyEval_CallMethod and PyEval_CallFunction
implementation same to PyObject_CallMethod and PyObject_CallFunction
to reduce future maintenance cost.  Optimization to avoid temporary
tuple are copied too.

PyEval_CallFunction(callable, "i", (int)i) now calls callable(i) instead of
raising TypeError.  But accepting this edge case is backward compatible.
@methane methane force-pushed the deprecate-evalcall branch from e17b495 to 4a3c0d5 Compare March 1, 2017 09:32
@methane
Copy link
Member Author

methane commented Mar 1, 2017

I squashed all commit and modified commit message.

@methane methane merged commit aa289a5 into python:master Mar 14, 2017
@methane methane deleted the deprecate-evalcall branch March 14, 2017 09:01
jaraco pushed a commit that referenced this pull request Dec 2, 2022
oraluben pushed a commit to oraluben/cpython that referenced this pull request Jul 15, 2023
Co-authored-by: Jules <julia.poo.poo.poo@gmail.com>
lysnikolaou pushed a commit to lysnikolaou/cpython that referenced this pull request May 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants