[issue13785] Make concurrent.futures.Future state public
Juan Javier added the comment: Hi Brian, No, no progress on this. I think this is not an interesting feature after all. You can close this. Juan Javier -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13785 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13785] Make concurrent.futures.Future state public
Changes by Juan Javier jjdomingu...@gmail.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13785 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13785] Make concurrent.futures.Future state public
Brian Quinlan added the comment: Any progress on this or can I close the bug? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13785 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13785] Make concurrent.futures.Future state public
Changes by Brian Quinlan br...@sweetapp.com: -- stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13785] Make concurrent.futures.Future state public
Changes by Juan Javier jjdomingu...@gmail.com: -- status: open - languishing ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13785] Make concurrent.futures.Future state public
Brian Quinlan br...@sweetapp.com 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 and sufficient for your use case. I think that you'd probably want to *not* specify that state change that you want i.e. any state change triggers the function. What do you think? (BTW, I'm on leave right now so it might take a while to respond) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13785] Make concurrent.futures.Future state public
Juan Javier jjdomingu...@gmail.com added the comment: I totally agree, I'm going to take a look at the code and I'll write back with some comments. That will be next week, work is currently very demanding. -- status: languishing - open versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13785] Make concurrent.futures.Future state public
Juan Javier jjdomingu...@gmail.com added the comment: I'm writting an application where users can submit long running jobs and I want to disply a list of those jobs and the state of each one. My idea is to use an executor and use the futures to display information about the jobs: not started, cancelled, running, etc. Think of a table with these headers: ID, Start date, Last state change date, State, Info -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13785] Make concurrent.futures.Future state public
Brian Quinlan br...@sweetapp.com added the comment: I guess the question is: why do you need to know the state in that form? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13785] Make concurrent.futures.Future state public
Juan Javier jjdomingu...@gmail.com added the comment: The use case is to know the state of a future without having to do something like this @property def state(self): if self.future.running(): return Process.States.Running elif self.future.cancelled(): return Process.States.Cancelled elif self.future.done(): return Process.States.Done return Process.States.Pending -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13785] Make concurrent.futures.Future state public
Juan Javier jjdomingu...@gmail.com added the comment: Hello, You're right, explaining the difference between CANCELLED and CANCELLED_AND_NOTIFIED is gong to be hard and might be confusing. I also agree that there is no precedent for storing the history of something, and I don't like either the idea of having a futures factory (that was my first idea). But, what about using callbacks? it is possible to add done callbacks, why can't we have a list of callbacks attached to each public state. Something like: Future.append_callback(self, state: One of PENDING, RUNNING, CANCELLED, FINISHED, fn) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13785] Make concurrent.futures.Future state public
Antoine Pitrou pit...@free.fr added the comment: The idea is to have access to the current state of the Future using a property instead of calling several methods (done, cancelled, etc.). I think one point of having methods is that querying is decoupled from implementation. The internal states could for example be finer-grained than what is exposed by the API. Also, a history property that returns a list of Event(state, timestamp) objects is written, the list stores the timestamp every time the state of a future changes. Uh, what is the use case exactly? -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13785] Make concurrent.futures.Future state public
New submission from Juan Javier jjdomingu...@gmail.com: Hello, This is a proposal to make the state of Future objects public. The idea is to have access to the current state of the Future using a property instead of calling several methods (done, cancelled, etc.). Also, a history property that returns a list of Event(state, timestamp) objects is written, the list stores the timestamp every time the state of a future changes. There is a patch attached to the issue. Regards. -- components: Library (Lib) files: concurrent.futures.Future.state_public.patch keywords: patch messages: 151259 nosy: bquinlan, jjdominguezm priority: normal severity: normal status: open title: Make concurrent.futures.Future state public type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file24237/concurrent.futures.Future.state_public.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13785] Make concurrent.futures.Future state public
Brian Quinlan br...@sweetapp.com added the comment: Thanks for the patch! 1. The fetching the state feature seems reasonable but I think that explaining the difference between CANCELLED and CANCELLED_AND_NOTIFIED is going to be hard. Maybe you could look at how Doc/library/concurrent.futures.rst would need to be updated to see if we can provide a reasonable description of the different states? 2. Having the future record the history of its state transitions seems potentially useful but there is no precedent for this in other Python objects where it would also be useful. Maybe you could make the executors take a Futures factory and then provide a subclass that does that? Not sure that I like that either but... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
