[issue10918] **kwargs unnecessarily restricted in concurrent.futures 'submit' API

Brian Quinlan added the comment: I think that we are happy to not fix this. -- resolution: accepted -> wont fix status: open -> closed ___ Python tracker ___

[issue10918] **kwargs unnecessarily restricted in concurrent.futures 'submit' API

Mark Dickinson added the comment: #15966 is related. I suggest closing this issue as "won't fix", too. -- nosy: +mark.dickinson ___ Python tracker ___ __

[issue10918] **kwargs unnecessarily restricted in concurrent.futures 'submit' API

Georg Brandl added the comment: Sure, a change to 3.2 is out of the question anyway right now. -- ___ Python tracker ___ ___ Python-b

[issue10918] **kwargs unnecessarily restricted in concurrent.futures 'submit' API

Brian Quinlan added the comment: Sorry for taking so long to reply - I was on holidays until today. This is an incompatible API change (since people may be providing "fn" by keyword) so we should probably hold off until 3.3. I also don't really like that the signature for submit will become l

[issue10918] **kwargs unnecessarily restricted in concurrent.futures 'submit' API

Georg Brandl added the comment: It could be changed, as it is not an incompatible API change. However, I'd like Brian to ok it. -- ___ Python tracker ___ _

[issue10918] **kwargs unnecessarily restricted in concurrent.futures 'submit' API

Adrian Dries added the comment: Have your cake and eat it: def submit(self, fn, args, kw): # submit implementation def sugar(*args, **kw): return args[0].submit(args[1], args[2:], kw) -- ___ Python tracker

[issue10918] **kwargs unnecessarily restricted in concurrent.futures 'submit' API

Ron Adam added the comment: Yes, you are correct. Pulling the first value off of args would work. This is new for 3.2, can it still be changed? One more thing to consider... One of the things I look at for functions like these is, how easy is it to separate the data from the program interf

[issue10918] **kwargs unnecessarily restricted in concurrent.futures 'submit' API

Georg Brandl added the comment: > The current submit definition doesn't allow that, and pulling out self, and > fn, would not be correct either. It would if they are pulled from *args. The only difference to now is that you cannot give the self and fn args as keyword args anymore (but that

[issue10918] **kwargs unnecessarily restricted in concurrent.futures 'submit' API

Ron Adam added the comment: Change... "are never unpacked within submit." to... Are completely separate. It's the attempt to mix two function signatures together as one, that was/is the problem. -- ___ Python tracker

[issue10918] **kwargs unnecessarily restricted in concurrent.futures 'submit' API

Ron Adam added the comment: Here is the whole method for reference... def submit(self, fn, *args, **kwargs): with self._shutdown_lock: if self._shutdown_thread: raise RuntimeError('cannot schedule new futures after shutdown') f = _base.Future

[issue10918] **kwargs unnecessarily restricted in concurrent.futures 'submit' API

R. David Murray added the comment: Adrian: you are correct of course, I was misremembering and did not check the docs. I prefer the other solution, though. -- ___ Python tracker _

[issue10918] **kwargs unnecessarily restricted in concurrent.futures 'submit' API

Adrian Dries added the comment: No, private mangling applies to any identifier in class-scope: Python 2.6.4 (r264:75706, Dec 7 2009, 18:45:15) [GCC 4.4.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class C: ... def f(__x): pass ... >>> import ins

[issue10918] **kwargs unnecessarily restricted in concurrent.futures 'submit' API

Georg Brandl added the comment: def submit(*args, **kwds): and picking out self and fn from *args might indeed be the most sensible solution here. -- nosy: +georg.brandl ___ Python tracker __

[issue10918] **kwargs unnecessarily restricted in concurrent.futures 'submit' API

R. David Murray added the comment: Name mangling applies only to attributes of classes, and so does not enter in to this issue. -- ___ Python tracker ___ __

[issue10918] **kwargs unnecessarily restricted in concurrent.futures 'submit' API

Adrian Dries added the comment: The futures case is one example of a broader API design issue. Note also that 'self' is similarly restricted. You might think these are 'corner cases', but to me it is poor API design. There may well be a reasonable case for passing 'self' as a keyword arg; w

[issue10918] **kwargs unnecessarily restricted in concurrent.futures 'submit' API

R. David Murray added the comment: Yes, it's about the concurrent.futures 'submit' method: http://docs.python.org/dev/py3k/library/concurrent.futures.html#executor-objects I've updated the title to reflect this. There are other places in the stdlib affected by this, but they should be opened