Use @_disfavoredOverload to enable more ergonomic syntax for PythonFunction #54
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request makes the syntax for existing function conventions mirror that introduced in #53. For example, functions with keyword arguments can be called like so:
But functions without keyword arguments must use less ergonomic syntax:
This pull request uses
@_disfavoredOverload
to enable a new behavior: concise use of theargs: [PythonObject]
calling convention. It will have merge conflicts with #53 in its current incarnation, due to employment of this new syntax in the test suite.There can only be one calling convention that benefits from this behavior: either
PythonObject
(single argument) or[PythonObject]
(multiple arguments). I prefer multiple arguments because it is more general-purpose and more closely mirrorsargs, kwargs
. The single-argument convention symbolizesself
in equivalent Python code. But it only holds that meaning forPythonInstanceMethod
and notPythonFunction
, which cannot bind to an object. Also, having to type`self`
as the most ergonomic option possible more complex than typingargs
, due to backticks.After this is decided, reverting the decision will be a source-breaking change.
@liuliu I would like your opinion, since you authored #40. The following data may help you decide, but does not influence my opinion. @pvieito please weigh in as well, if you have a preference. If the three of us do not all agree, we may need to seek other users' feedback on Swift Forums.
Swift-Colab 2.0 has the following distribution of calling conventions:
PythonInstanceMethod
Examining PythonFunctionTests.swift in PythonKit's tests, before #53:
Ergonomics data:
(args: [PythonObject])
has the same number of non-alphanumeric symbols as(`self`: PythonObject)
. From my viewpoint, theargs
phrase seems more complex.{ (_: [PythonObject]) in ... }
becomes{ _ in ... }
.