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:

PythonInstanceMethod { args, kwargs in ... }

But functions without keyword arguments must use less ergonomic syntax:

PythonInstanceMethod { (`self`: PythonObject) in ... }
PythonInstanceMethod ( (args: [PythonObject]) in ... }

This pull request uses @_disfavoredOverload to enable a new behavior: concise use of the args: [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.

PythonInstanceMethod { args in ... }

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 mirrors args, kwargs. The single-argument convention symbolizes self in equivalent Python code. But it only holds that meaning for PythonInstanceMethod and not PythonFunction, which cannot bind to an object. Also, having to type `self` as the most ergonomic option possible more complex than typing args, 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:

• single-argument: 6, including one that is not a PythonInstanceMethod
• multiple-argument: 4
• multiple-argument + keyword arguments: 1

Examining PythonFunctionTests.swift in PythonKit's tests, before #53:

• single-argument: 3
• multiple-argument: 7
• multiple-argument + keyword arguments: 0

Ergonomics data:

• Preferring one convention means the alternative must retain the old syntax. The phrase (args: [PythonObject]) has the same number of non-alphanumeric symbols as (`self`: PythonObject). From my viewpoint, the args phrase seems more complex.
• Either convention will allow for more ergonomic ignoring of parameters, which means { (_: [PythonObject]) in ... } becomes { _ in ... }.