[issue15634] Add serialized decorator to the threading module

Juan Javier added the comment: David, I think this doesn't deserve to be part of the library since it is trivial to write and it is just a particular use case. Adding it as an example in the threading module's documentation might be a good idea, what do

[issue13785] Make concurrent.futures.Future state public

Changes by Juan Javier : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue13785> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue15634] Add serialized decorator to the threading module

Juan Javier added the comment: It looks like this is not very interesting after all. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issu

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

[issue15634] synchronized decorator for the threading module

Juan Javier added the comment: What about this? def serialized(lock): def _serialized(func): def __serialized(*args, **kwds): with lock: return func(*args, **kwds) __serialized.__doc__ = func.__doc__ return __serialized return

[issue15634] synchronized decorator for the threading module

Juan Javier added the comment: Ok, you are right, serialized is the right name. Also, passing the lock to the decorator will the correct option. -- ___ Python tracker <http://bugs.python.org/issue15

[issue15634] synchronized decorator for the threading module

New submission from Juan Javier: I think it will be useful to have a decorator like this one on the threading module: def synchronized(func): """A decorator to make a function execution synchronized. Examples: @synchronized def foo(): pass class F

[issue13785] Make concurrent.futures.Future state public

Juan Javier 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.

[issue13785] Make concurrent.futures.Future state public

Changes by Juan Javier : -- status: open -> languishing ___ Python tracker <http://bugs.python.org/issue13785> ___ ___ Python-bugs-list mailing list Unsubscri

[issue13785] Make concurrent.futures.Future state public

Juan Javier 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, ru

[issue13785] Make concurrent.futures.Future state public

Juan Javier 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

[issue13785] Make concurrent.futures.Future state public

Juan Javier 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 o

[issue13785] Make concurrent.futures.Future state public

New submission from Juan Javier : 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

[issue6751] Default return value in ConfigParser

Juan Javier added the comment: I would like the method to have the exact same behavior as before if the "default" argument is not present, and return the given default value when "deafult" argument is present. If you simply add a "default" keyword, it will alway

[issue6751] Default return value in ConfigParser

Changes by Juan Javier : Added file: http://bugs.python.org/file18123/test_cfgparser.py.diff ___ Python tracker <http://bugs.python.org/issue6751> ___ ___ Python-bug

[issue6751] Default return value in ConfigParser

Juan Javier added the comment: I've applied the enhancement to the three parsers, actually I've made the change to RawconfigParser with a small change to ConfigParser. I've also created some unit tests. -- keywords: +patch Added file: http://bugs.pytho

[issue6751] Default return value in ConfigParser

New submission from Juan Javier : I think it is useful, at least for me, to add an argument, default, to [Safe,Raw]ConfigParser.get that, if present, will be returned if the methid fails to return the value. That is, instead of rasing an exception, return default, if present. It could be done

[issue3821] trace module bug when using --missing

New submission from Juan Javier <[EMAIL PROTECTED]>: I get the following exception: $ /opt/python3.0b2/bin/python3.0 -m trace -c -m run.py Traceback (most recent call last): File "/opt/python3.0b2/lib/python3.0/runpy.py", line 121, in _run_module_as_main "__m