Skip to content

bpo-6761: Fix __call__ documentation #7987

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.

Sign up for GitHub

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

Merged
merged 8 commits into from
Oct 27, 2020
Merged

bpo-6761: Fix __call__ documentation #7987

Changes from 7 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
c0da865
bpo-6761: Fix __call__ documentation
andresdelfino Jun 28, 2018
6a4e251
Minor fix
andresdelfino Jun 28, 2018
b4880e0
Minor change
andresdelfino Jun 28, 2018
6235331
Minor change
andresdelfino Jun 28, 2018
a671714
Update datamodel.rst
andresdelfino Jun 28, 2018
860857d
Address comment from Victor
andresdelfino Feb 25, 2019
73b5422
Address comment from Cheryl
andresdelfino Mar 5, 2019
26cebc5
Update datamodel.rst
andresdelfino Oct 23, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion Doc/reference/datamodel.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2108,7 +2108,7 @@ Emulating callable objects
.. index:: pair: call; instance

Called when the instance is "called" as a function; if this method is defined,
``x(arg1, arg2, ...)`` is a shorthand for ``x.__call__(arg1, arg2, ...)``.
the class receives the instance and all arguments of the call.
Copy link
Contributor

Choose a reason for hiding this comment

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

I know what is supposed to be conveyed here, and I find this more confusing than the original. Diving into the internals of how calls to instance methods work is detracting from the discussion of what call does.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for your insight! Before doing any changes, I'll wait for @bitdancer to give his input.

Copy link
Member

Choose a reason for hiding this comment

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

This current version don't work for me, "if this method is defined, the class receives the instance and all arguments of the call." looks wrong, It's not the class that receives the instance and all arguments.

I'd propose something like:

Called when the instance is "called" as a function. Receives the instance and the function parameters.

If you want to almost keep the example you could add something like:

So ``obj(arg1, arg2, ...)`` calls ``__call__(arg1, arg2, ...)`` on ``obj``.

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 think that last suggestion (from Julien) works (call on obj?).

type(x).__call__(x, arg1, ...) is closer to what happens, and the call matches the way the method is defined (with a self parameter).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@merwok I agree. Made a change based on your suggestion, what do you think?

Copy link
Member

Choose a reason for hiding this comment

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

@vstinner You said «I would prefer to [not] use type() in the doc, since technically the builtin function can be overriden» → that’s what we say «roughly»! Is the latest version good for you or you would prefer obj.__class__.__call__(obj, etc)?

@csabella I’m not sure I understand your review; could you comment on the latest version? Thanks!



.. _sequence-types:
Expand Down