[issue14119] Ability to adjust queue size in Executors

Brian Quinlan added the comment: The queue that you identified i.e. self._call_queue = multiprocessing.Queue(self._max_workers + EXTRA_QUEUED_CALLS) does not get considered during submit() - are you sure that it somehow causes submit() to block

[issue14119] Ability to adjust queue size in Executors

Brian Quinlan added the comment: I've had people request that they be able control the order of processed work submissions. So a more general way to solve your problem might be to make the two executors take an optional Queue argument in their constructors. You'd have to explain in

[issue13785] Make concurrent.futures.Future state public

Brian Quinlan added the comment: My current thinking is that adding a "state" property probably isn't worth it given the fact that you can construct this yourself and the requirement for a "history" property is too specialized. The callback idea seams reasonable an

[issue16284] concurrent.futures ThreadPoolExecutor keeps unnecessary references to worker functions.

Brian Quinlan added the comment: The concurrent.futures stuff looks good to me. Could you add a comment explaining why the delete is necessary? And, as Antoine said, the test should be CPython only. -- ___ Python tracker <http://bugs.python.

[issue15966] concurrent.futures: Executor.submit keyword arguments may not be called 'fn' (or 'self')

Brian Quinlan added the comment: 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

[issue13785] Make concurrent.futures.Future state public

Changes by Brian Quinlan : -- stage: -> needs patch ___ Python tracker <http://bugs.python.org/issue13785> ___ ___ Python-bugs-list mailing list Unsubscri

[issue8792] Support Apache extensions to XML-RPC in xmlrpclib

Brian Quinlan added the comment: I'm closing this since the filer hasn't specified exactly what they want. -- status: open -> closed ___ Python tracker <http://bugs.pyth

[issue11271] concurrent.futures.ProcessPoolExecutor.map() doesn't batch function arguments by chunks

Changes by Brian Quinlan : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue11271> ___ ___ Python-bugs-list mailing list Unsubscri

[issue21362] concurrent.futures does not validate that max_workers is proper

Brian Quinlan added the comment: The patch looks good to me too. I'll commit it soon. -- assignee: -> bquinlan ___ Python tracker <http://bugs.python.org

[issue21362] concurrent.futures does not validate that max_workers is proper

Brian Quinlan added the comment: Committed, thanks for the fix! -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/i

[issue7200] multiprocessing deadlock on Mac OS X when queue collected before process terminates

Brian Quinlan added the comment: OK, working as intended. -- resolution: -> invalid ___ Python tracker <http://bugs.python.org/issue7200> ___ ___ Python-

[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 <http://bugs.python.org/i

[issue11161] futures.ProcessPoolExecutor hangs

Changes by Brian Quinlan : -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue11161> ___ ___ Python-bugs-list

[issue13785] Make concurrent.futures.Future state public

Brian Quinlan added the comment: Any progress on this or can I close the bug? -- ___ Python tracker <http://bugs.python.org/issue13785> ___ ___ Python-bugs-list m

[issue18699] What is Future.running() for in PEP 3148 / concurrent.futures.Future?

Brian Quinlan added the comment: The only thing that I've used .running() for is for UI reasons. But it is easier to just iterative over your futures and call a method than to install a callback and handle the state yourself. -- nosy: +bqu

[issue17874] ProcessPoolExecutor in interactive shell doesn't work in Windows

Brian Quinlan added the comment: Take a look at http://bugs.python.org/issue11161 and its fix. Do you think that just saying that ProcessPoolExecutor will not work from the interactive shell is sufficient? -- nosy: +bquinlan ___ Python tracker

[issue14119] Ability to adjust queue size in Executors

Brian Quinlan added the comment: Hi Victor, I don't understand your problem. Could you be very specific in your description? -- ___ Python tracker <http://bugs.python.org/is

[issue14119] Ability to adjust queue size in Executors

Brian Quinlan added the comment: Can't you accomplish what you want using add_done_callback? e.g. # Pseudocode class MyExecutor(ThreadPoolExecutor): def __init__(self): self._count = 0 def _decrement(self): with self._some_lock: self._count -= 1 def submit(self, fn,

[issue20319] concurrent.futures.wait() can block forever even if Futures have completed

Brian Quinlan added the comment: I'm not currently working on concurrent.futures but I do look at patches and bug reports. I'll take a look at this and Issue20297 sometime this week. -- ___ Python tracker <http://bugs.python.o

[issue20319] concurrent.futures.wait() can block forever even if Futures have completed

Brian Quinlan added the comment: I'm looking at "futures.patch". I don't understand why these blocks are helpful -"_create_and_install_waiters" has two call sites and both ("as_completed" and "wait") call "_create_and_install_

[issue20319] concurrent.futures.wait() can block forever even if Futures have completed

Changes by Brian Quinlan : -- assignee: -> bquinlan ___ Python tracker <http://bugs.python.org/issue20319> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue20319] concurrent.futures.wait() can block forever even if Futures have completed

Brian Quinlan added the comment: Thanks very much for the patch Glenn! -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue20319> ___ _

[issue20319] concurrent.futures.wait() can block forever even if Futures have completed

Brian Quinlan added the comment: Oops, no. That was junk due to my sloppiness. I’ll fix it in a minute. On Jan 31, 2014, at 5:03 PM, STINNER Victor wrote: > > STINNER Victor added the comment: > >> New changeset 0bcf23a52d55 by Brian Quinlan in branch 'defau

[issue7200] multiprocessing deadlock on Mac OS X when queue collected before process terminates

New submission from Brian Quinlan : This code: import multiprocessing import queue def _process_worker(q): while True: try: something = q.get(block=True, timeout=0.1) except queue.Empty: return else: pass # print

[issue5040] Bug of CGIXMLRPCRequestHandler

Brian Quinlan added the comment: It turns out that there are a bunch of issues with the py3k XML-RPC client and server. Attached as some tests that demonstrate them. -- keywords: +patch nosy: +bquinlan Added file: http://bugs.python.org/file13442/xmlrpc-test.diff

[issue5040] Bug of CGIXMLRPCRequestHandler

Changes by Brian Quinlan : Added file: http://bugs.python.org/file13444/xmlrpc-fix.diff ___ Python tracker <http://bugs.python.org/issue5040> ___ ___ Python-bugs-list m

[issue5040] Bug of CGIXMLRPCRequestHandler

Changes by Brian Quinlan : -- type: performance -> behavior ___ Python tracker <http://bugs.python.org/issue5040> ___ ___ Python-bugs-list mailing list Un

[issue5687] Docstring typo in _io

Changes by Brian Quinlan : -- components: Extension Modules files: docstring.diff keywords: patch nosy: bquinlan severity: normal status: open title: Docstring typo in _io versions: Python 3.1 Added file: http://bugs.python.org/file13611/docstring.diff

[issue5700] io.FileIO calls flush() after file closed

New submission from Brian Quinlan : >>> import io >>> class MyIO(io.FileIO): ... def flush(self): ... print('closed:', self.closed) ... >>> f = MyIO('test.out', 'wb') >>> f.close() closed: True IMHO, calling flu

[issue5700] io.FileIO calls flush() after file closed

Brian Quinlan added the comment: Discussion about this bug is ongoing in python-dev. -- ___ Python tracker <http://bugs.python.org/issue5700> ___ ___ Python-bug

[issue5734] BufferedRWPair broken

New submission from Brian Quinlan : The C implementation: - doesn't correctly initialize its reader and writer instances - incorrectly maps its "readinto" method to another class - incorrectly delegates its "closed" property to its base class i.e. this class can

[issue5734] BufferedRWPair broken

Changes by Brian Quinlan : -- components: +Library (Lib) type: -> behavior ___ Python tracker <http://bugs.python.org/issue5734> ___ ___ Python-bugs-list mai

[issue5734] BufferedRWPair broken

Brian Quinlan added the comment: Hey Antoine, Will do - but first I'll finish up my reason for needing a working version of this class in the first place ;-) Cheers, Brian -- ___ Python tracker <http://bugs.python.org/i

[issue5700] io.FileIO calls flush() after file closed

Changes by Brian Quinlan : Added file: http://bugs.python.org/file13677/cooperation.diff ___ Python tracker <http://bugs.python.org/issue5700> ___ ___ Python-bugs-list m

[issue5700] io.FileIO calls flush() after file closed

Brian Quinlan added the comment: cooperation.diff: - change the close method to call .flush() and then ._close() - only IOBase implements close() (though a subclass can override close without causing problems - so long as it calls super().close()) - .flush() invokes super().flush() - ._close

[issue5700] io.FileIO calls flush() after file closed

Brian Quinlan added the comment: >> - FileIO is implemented in Python in _pyio.py so that it can have the >>same base class as the other Python-implemented files classes > Is it really necessary (e.g. to pass the tests)? It is necessary to make MI work. With out it the in

[issue5700] io.FileIO calls flush() after file closed

Brian Quinlan added the comment: Antoine Pitrou wrote: > Antoine Pitrou added the comment: > >> It is necessary to make MI work. With out it the inheritance graph looks >> like this (using _pyio): >> >> >> io.IOBase_pyio.IOBase >> |

[issue5700] io.FileIO calls flush() after file closed

Brian Quinlan added the comment: Antoine Pitrou wrote: > Antoine Pitrou added the comment: > >> I think that this linearization is probably more useful: >> >> MyClass -> io.FileIO -> MyMixin -> IOBase > > But why not simply: > > MyClass ->

[issue5700] io.FileIO calls flush() after file closed

Brian Quinlan added the comment: Antoine Pitrou wrote: > Antoine Pitrou added the comment: > >> No, doing this is trivial. But shouldn't it be up to the implementor of >> MyClass to decide whether MyMixin or io.FileIO methods are evaluated first? > > Is there a

[issue5700] io.FileIO calls flush() after file closed

Brian Quinlan added the comment: Oops, I didn't finish my thought: >> No, doing this is trivial. But shouldn't it be up to the implementor of >> MyClass to decide whether MyMixin or io.FileIO methods are evaluated first? > > Is there a concrete use case, though?

[issue5734] Fix BufferedRWPair

Changes by Brian Quinlan : Added file: http://bugs.python.org/file13716/rwpair2.diff ___ Python tracker <http://bugs.python.org/issue5734> ___ ___ Python-bugs-list mailin

[issue5734] Fix BufferedRWPair

Brian Quinlan added the comment: http://codereview.appspot.com/40126/diff/1/2 File Lib/_pyio.py (left): http://codereview.appspot.com/40126/diff/1/2#oldcode370 Line 370: def _checkReadable(self, msg=None): On 2009/04/17 21:11:15, Antoine Pitrou wrote: > Not sure why you're rem

[issue5788] datetime.timedelta is inconvenient to use...

New submission from Brian Quinlan : ...in seconds-based library functions (e.g. time.sleep) and calculations (e.g. distance = velocity * ?). -- components: Library (Lib) messages: 86132 nosy: bquinlan severity: normal status: open title: datetime.timedelta is inconvenient to use

[issue5788] datetime.timedelta is inconvenient to use...

Changes by Brian Quinlan : -- keywords: +patch Added file: http://bugs.python.org/file13719/totalseconds.diff ___ Python tracker <http://bugs.python.org/issue5

[issue5788] datetime.timedelta is inconvenient to use...

Brian Quinlan added the comment: I did add a patch description: "Adds a datetime.total_seconds attribute" - is that unclear? The idea is that you should be able to extract the total number of seconds in the duration i.e. >>> dt = datetime.timedelta(seconds=1234567.89) &

[issue5788] datetime.timedelta is inconvenient to use...

Brian Quinlan added the comment: OK, a bit on motivation: 1. datetime.timedelta instances are a convenient way of representing durations 2. datetime.timedelta instances cannot be conveniently used in many calculations e.g. calculating distance based on velocity and time 3

[issue5788] datetime.timedelta is inconvenient to use...

Changes by Brian Quinlan : Added file: http://bugs.python.org/file13721/totalseconds2.diff ___ Python tracker <http://bugs.python.org/issue5788> ___ ___ Python-bugs-list m

[issue5788] datetime.timedelta is inconvenient to use...

Brian Quinlan added the comment: Attached is a patch that implements .total_seconds as an instance method -- ___ Python tracker <http://bugs.python.org/issue5

[issue8792] xmlrpclib compatibility issues with Apache XML-RPC library

Brian Quinlan added the comment: A few notes: 1. these types are *not* part of the XML-RPC specification, they are Apache extensions 2. these types seem designed to accommodate Java 3. some of these types would be very possible to accommodate e.g. ex:serializable which contains a serialized

[issue24195] Add `Executor.filter` to concurrent.futures

Brian Quinlan added the comment: Actually it immediately converts the iterable into a list. Recall: def filter(self, fn, iterable, timeout=None): l = list(iterable) # iterable => list return (item for (item, keep) in zip(l, self.map(fn, l, timeout)) if k

[issue24195] Add `Executor.filter` to concurrent.futures

Brian Quinlan added the comment: This feature seems unnecessary to me but couldn't the implementation be simplified to work in terms of map? i.e. (pseudocode): def filter(self, fn, iterable, timeout=None): l = list(iterable) return (item for (item, keep) in zip(l, self.map(fn, l, ti

[issue24195] Add `Executor.filter` to concurrent.futures

Brian Quinlan added the comment: Ethan: I'm -0 so I'd happily go with the consensus. Does anyone have a strong opinion? Ram: What did you mean by "Possible issues"? Did you mean that to be an example using the exec

<    1   2