Issue2359

classification
Title: Many Java-defined functions do not accept keyword arguments
Type: Severity: normal
Components: Library Versions: Jython 2.7
Milestone:
process
Status: open Resolution: accepted
Dependencies: Superseder:
Assigned To: Nosy List: jdemoor, zyasoft
Priority: Keywords:

Created on 2015-05-26.11:20:32 by jdemoor, last changed 2015-05-26.18:07:36 by zyasoft.

Messages
msg10078 (view) Author: Julien Demoor (jdemoor) Date: 2015-05-26.11:20:31
threading.Condition().timeout() should accept a keyword argument named `timeout`. It works in CPython. In Jython, only a positional argument is accepted.

>>> import threading
>>> c = threading.Condition(threading.Lock())
>>> c.acquire()
>>> c.wait(timeout=1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: wait() takes no keyword arguments
msg10079 (view) Author: Jim Baker (zyasoft) Date: 2015-05-26.18:07:35
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.
History
Date User Action Args
2015-05-26 18:07:36zyasoftsetresolution: accepted
messages: + msg10079
nosy: + zyasoft
title: threading.Condition().timeout() doesn't accept keyword arguments -> Many Java-defined functions do not accept keyword arguments
2015-05-26 11:20:32jdemoorcreate