[issue15634] Add serialized decorator to the threading module

2013-10-27 Thread Juan Javier

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 you think?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15634
___
___
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

2013-10-26 Thread Juan Javier

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



[issue15634] Add serialized decorator to the threading module

2013-10-26 Thread Juan Javier

Juan Javier added the comment:

It looks like this is not very interesting after all.

--
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15634
___
___
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

2013-10-26 Thread Juan Javier

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



[issue15634] synchronized decorator for the threading module

2012-08-14 Thread Juan Javier

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 rep...@bugs.python.org
http://bugs.python.org/issue15634
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue15634] synchronized decorator for the threading module

2012-08-14 Thread Juan Javier

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 _serialized

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15634
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue15634] synchronized decorator for the threading module

2012-08-13 Thread Juan Javier

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 Foo:
def __init__(self):
self.__syncdata = None

@property
def syncdata(self):
return self.__syncdata

@syncdata.setter
@synchronized
def syncdata(self, value):
self.__syncdata = value

if not hasattr(func, __lock):
func.__lock = threading.Lock()
def _synchronized(*args, **kwds):
with func.__lock:
func(*args, **kwds)
_synchronized.__doc__ = func.__doc__
return _synchronized

What do you think?

--
components: Library (Lib)
messages: 168071
nosy: jjdominguezm
priority: normal
severity: normal
status: open
title: synchronized decorator for the threading module
type: enhancement
versions: Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15634
___
___
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

2012-07-18 Thread Juan Javier

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

2012-07-18 Thread Juan Javier

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

2012-03-09 Thread Juan Javier

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

2012-02-29 Thread Juan Javier

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

2012-01-15 Thread Juan Javier

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

2012-01-14 Thread Juan Javier

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



[issue6751] Default return value in ConfigParser

2010-08-07 Thread Juan Javier

Juan Javier jjdomingu...@gmail.com 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 always be present and you 
wouldn't know if the user wants the exception thrown or the default value 
returned.

Do you know how to program this using a default keyword argument?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6751
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6751] Default return value in ConfigParser

2010-07-22 Thread Juan Javier

Juan Javier jjdomingu...@gmail.com 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.python.org/file18122/configparser.py.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6751
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6751] Default return value in ConfigParser

2010-07-22 Thread Juan Javier

Changes by Juan Javier jjdomingu...@gmail.com:


Added file: http://bugs.python.org/file18123/test_cfgparser.py.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6751
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6751] Default return value in ConfigParser

2009-08-21 Thread Juan Javier

New submission from Juan Javier jjdomingu...@yahoo.com:

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 overriding the get method in SafeConfigParser,
something like this:

class SafeConfigParser(ConfigParser):
def get(self, section, option, raw=False, vars=None, **kwds):
try:
return super().get(section, option, raw, vars)
except Exception as exc:
if default in kwds:
return kwds[default]
raise exc

--
components: Library (Lib)
messages: 91808
nosy: jjdominguezm
severity: normal
status: open
title: Default return value in ConfigParser
type: feature request
versions: Python 3.2

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6751
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue3821] trace module bug when using --missing

2008-09-09 Thread Juan Javier

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
__main__, fname, loader, pkg_name)
  File /opt/python3.0b2/lib/python3.0/runpy.py, line 34, in _run_code
exec(code, run_globals)
  File /opt/python3.0b2/lib/python3.0/trace.py, line 809, in module
main()
  File /opt/python3.0b2/lib/python3.0/trace.py, line 806, in main
results.write_results(missing, summary=summary, coverdir=coverdir)
  File /opt/python3.0b2/lib/python3.0/trace.py, line 303, in write_results
lnotab = find_executable_linenos(filename)
  File /opt/python3.0b2/lib/python3.0/trace.py, line 428, in
find_executable_linenos
return find_lines(code, strs)
  File /opt/python3.0b2/lib/python3.0/trace.py, line 392, in find_lines
linenos.update(find_lines(c, strs))
  File /opt/python3.0b2/lib/python3.0/trace.py, line 386, in find_lines
linenos = find_lines_from_code(code, strs)
  File /opt/python3.0b2/lib/python3.0/trace.py, line 370, in
find_lines_from_code
line_increments = [ord(c) for c in code.co_lnotab[1::2]]
  File /opt/python3.0b2/lib/python3.0/trace.py, line 370, in listcomp
line_increments = [ord(c) for c in code.co_lnotab[1::2]]
TypeError: ord() expected string of length 1, but int found

I think that line 370 of trace.py should say:

line_increments = [int(c) for c in code.co_lnotab[1::2]]

instead of:

line_increments = [ord(c) for c in code.co_lnotab[1::2]]

--
components: Library (Lib)
messages: 72879
nosy: jjdominguezm
severity: normal
status: open
title: trace module bug when using --missing
versions: Python 3.0

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3821
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com