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
Changes by Juan Javier jjdomingu...@gmail.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13785
___
___
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
___
___
Changes by Brian Quinlan br...@sweetapp.com:
--
stage: - needs patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13785
___
___
Python-bugs-list
Changes by Juan Javier jjdomingu...@gmail.com:
--
status: open - languishing
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13785
___
___
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
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
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,
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
___
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():
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
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
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
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
14 matches
Mail list logo
