homepage

The submit methods of concurrent.futures.ThreadPoolExecutor and concurrent.futures.ProcessPoolExectutor raise TypeError when submitting a callable with a keyword argument named 'fn' or 'self':
 Python 3.3.0rc2+ (default:3a880d640981, Sep 18 2012, 16:29:28) 
 [GCC 4.2.1 (Apple Inc. build 5664)] on darwin
 Type "help", "copyright", "credits" or "license" for more information.
 >>> import concurrent.futures
 >>> def awkward(*, fn): return fn * 1729
 ... 
 >>> with concurrent.futures.ThreadPoolExecutor(1) as e:
 ... e.submit(awkward, fn=3)
 ... 
 Traceback (most recent call last):
 File "<stdin>", line 2, in <module>
 TypeError: submit() got multiple values for argument 'fn'
An obvious solution is to change the declarations of the submit methods from:
 def submit(self, fn, *args, **kwargs):
 ...
to
 def submit(*args, **kwargs):
 self, fn, *args = args
I don't think this is quite good enough, since it'll introduce a regression for anyone who was doing executor.submit(fn=...).

Here's a patch. The solution is ugly enough that I'm wondering whether this is even worth fixing.

The patch looks ok to me. At least passing "fn" as keyword arg should be fixed. Passing "self" as keyword arg admittedly sounds a bit awkward.

Ah, I added the wrong Brian to the nosy. Sorry, Brian C.

This has come up before. Did you actually bang into this? Because the fix seems pretty ugly to me and the work-around (using functools.partial) is pretty easy.
But, if people are actually hitting this, then your is probably the best that we can do.

> Did you actually bang into this?
No directly, no: I'd hit a similar problem in some of our own code, leading to a signature change from "def do_later(fn, *args, **kwargs)" to "def do_later(fn, arg, kwargs)". Then it occurred to me to wonder how Executor.submit handled the issue.
The workaround seems fine; feel free to close as "won't fix".

There are many other cases of such issue: collections.namedtuple, contextlib.contextmanager, profile.Profile.runcall, etc.

Closing this.