Inconsistent argument name for function eval (“source” vs “expression”)

[dluschan]

The function signature and parameter description correctly use the argument name source:

.. function:: eval(source, /, globals=None, locals=None)

   :param source:
      A Python expression.
   :type source: :class:`str` | :ref:`code object <code-objects>`

However, further down in the same section the text suddenly refers to the argument as “expression”:

   The *expression* argument is parsed and evaluated as a Python expression
   (technically speaking, a condition list) using the *globals* and *locals*
   mappings as global and local namespace. ...

This creates a mismatch, as there is no parameter named expression in the signature. The text should refer to the argument as source, for consistency.

Suggested fixes (choose one):

1. Replace “The expression argument” with “The source argument” to match the function signature.
2. Rename the function parameter from source to expression in the signature, so it matches the descriptive text.

Linked PRs

• gh-142568: Fix eval() docs to use 'source' parameter name #142644
• [3.14] gh-142568: Fix eval() docs to use 'source' parameter name (GH-142644) #142669
• [3.13] gh-142568: Fix eval() docs to use 'source' parameter name (GH-142644) #142670

[Yashp002]

Looking at the issue, i feel like option 1 is a better fix due to it maintaining consistency with the actual C argument entered and the term source is more accurate i feel like because of itbeing able to accept both string and code objects?

I'd be happy to work on this

[Joshua-Ward1]

I’ve opened a PR implementing option 1 by updating the documentation to consistently use source, matching the function signature.