Message10079

Also applies to other methods on Condition.

We see here that two argument parsing schemes come in conflict in Jython: support in the ExposedMethod annotation processing for Java code itself; and in Python functions, which handle kwargs as expected. As in CPython 2.7, except for some specific cases, perhaps most native-defined functions in Jython 2.7.0 do not take keyword args.

In CPython 2.7, threading.Condition is written in Python; in Jython 2.7.0, it is in Java. So now we see this difference come in, per msg10078, whereas in both Jython and in CPython, this is the case, since str is native:

>>> " a\nb\nc".splitlines(keepends=True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: splitlines() takes no keyword arguments

However in CPython 3.4, this holds:

>>> " a\nb\nc".splitlines(keepends=True)
[' a\n', 'b\n', 'c']

Clearly less surprising in CPython 3.4!

CPython 3.4 began the implementation of Argument Clinic (https://www.python.org/dev/peps/pep-0436/) in part to remove this type of surprise in using native-defined functions. Jython's expose annotations and corresponding annotation processing is the counterpart of Argument Clinic. So the obvious thing to do here is implement direct support of kwargs in Jython's expose support. Then we should choose whether to make it always available (so bring in Python 3.4 functionality and not throw TypeError, as the case above with str); or turn it on selectively (so for support of Condition, Lock, etc). I would favor making it always available: there may be compliance unit tests that check that kwargs do not parse, but I doubt there is user code that does. We can do selective turnoff if that really is an issue.