Skip to content
Merged
Changes from 1 commit
Commits
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
Prev Previous commit
Next Next commit
paramspec isn't actually keyword only
  • Loading branch information
Fidget-Spinner committed Jan 9, 2021
commit 65c17cbe90691babd671cfc2bf1e9823fe64800e
2 changes: 1 addition & 1 deletion Doc/library/typing.rst
Original file line number Diff line number Diff line change
Expand Up @@ -1000,7 +1000,7 @@ These are not used in annotations. They are building blocks for creating generic
for the type variable must be a subclass of the boundary type,
see :pep:`484`.

.. class:: ParamSpec(name, *, bound=None, covariant=False, contravariant=False)
.. class:: ParamSpec(name, bound=None, covariant=False, contravariant=False)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Hm. I would rather add the star to the code.

@Fidget-Spinner Fidget-Spinner Jan 10, 2021

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Hmm after giving it some thought, I agree. I realized ParamSpec and TypeVar have different init signatures, (TypeVar has *constraints and ParamSpec doesn't). And PEP 612 states that

However, enforcing these constraints would require enough additional implementation work that we judged this extension to be out of scope of this PEP. Fortunately the design of ParamSpecs are such that we can return to this idea later if there is sufficient demand.

so to prevent any backwards incompatibility in the future, we should enforce it, so that if we do add constraints in the future, existing code won't break.

Edit: bounds -> constraints


Parameter specification variable. A specialized version of
:class:`type variables <TypeVar>`.
Expand Down