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

Constrain calling convention for PyStub #5761

Merged
merged 3 commits into from
Feb 24, 2021
Merged

Constrain calling convention for PyStub #5761

merged 3 commits into from
Feb 24, 2021

Conversation

steven-johnson
Copy link
Contributor

There are two calling conventions that are sensible when calling a Generator from Python:

  • Inputs are specified via keyword arguments (verbose but more readable)
  • Inputs are specified via positional arguments (terse but more like C++)

However, the current PyStub implementation also allows for mixing positional and keyword forms of input (as long as no input is specified multiple times). This change removes that possibility (requiring either all-keyword or all-positional for inputs). I'm not sure why I thought this was a good option originally, but upon reflection (and examination of existing code), calls written in this way tend to be a confusing mess that require too much care when reading, and I think we'd be better off just forbidding this entirely.

Note that this technically is a breaking API change (thus the release_notes label); any user code that used this technique previously would now throw an exception and need a (trivial) update. That said, this is (AFAIK) a very rarely used API, and I rather suspect that existing code that relies on being able to mix positional and keyword inputs in this way is likely to be doing so inadvertently rather than deliberately.

There are two calling conventions that are sensible when calling a Generator from Python:
- Inputs are specified via keyword arguments (verbose but more readable)
- Inputs are specified via positional arguments (terse but more like C++)

However, the current PyStub implementation also allows for mixing positional and keyword forms of input (as long as no input is specified multiple times). This change removes that possibility (requiring either all-keyword or all-positional for inputs). I'm not sure why I thought this was a good option originally, but upon reflection (and examination of existing code), calls written in this way tend to be a confusing mess that require too much care when reading, and I think we'd be better off just forbidding this entirely.

Note that this technically is a breaking API change; any user code that used this technique previously would now throw an exception and need a (trivial) update. That said, this is (AFAIK) a very rarely used API, and I rather suspect that existing code that relies on being able to mix positional and keyword inputs in this way is likely to be doing so inadvertently rather than deliberately.
@steven-johnson steven-johnson added the release_notes For changes that may warrant a note in README for official releases. label Feb 19, 2021
@steven-johnson
Copy link
Contributor Author

Monday Morning Review Ping

@steven-johnson steven-johnson merged commit 14bab78 into master Feb 24, 2021
@steven-johnson steven-johnson deleted the srj/pystub2 branch February 24, 2021 19:14
@alexreinking alexreinking added this to the v12.0.0 milestone May 19, 2021
@alexreinking alexreinking removed the release_notes For changes that may warrant a note in README for official releases. label Apr 6, 2022
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.

3 participants