Hi,
I've came to a problem where I want to keep backwards and forwards
compatibility with an exception syntax. And I mean by backwards going
further down to Python 2.5.
I was pointed to this option from a stack overflow answer[1] that works
forward and backwards, I rewrite the solution here:
imp
I have a socket logging handler and I want to be able to catch
exceptions from it. Specifically, I want to know if the remote side
has gone away so I can close the socket and reopen it when the remote
side come back.
What happens now is that I get Broken pipe and BAD_WRITE_RETRY
exceptions, but it
Fabien writes:
> I am developing a tool which works on individual entities (glaciers)
> and do a lot of operations on them. There are many tasks to do, one
> after each other, and each task follows the same interface: ...
If most of the resources will be spent on computation and the
communication
On 06/20/2015 05:14 AM, Cameron Simpson wrote:
I would keep your core logic Pythonic, raise exceptions. But I would
wrap each task in something to catch any Exception subclass and report
back to the queue. Untested example:
def subwrapper(q, callable, *args, **kwargs):
try:
q.put( ('
On 06/19/2015 10:58 PM, Chris Angelico wrote:
AIUI what he's doing is all the subparts of task1 in parallel, then
all the subparts of task2:
pool.map(task1, dirs, chunksize=1)
pool.map(task2, dirs, chunksize=1)
pool.map(task3, dirs, chunksize=1)
task1 can be done on all of dirs in parallel, as
On 19Jun2015 18:16, Fabien wrote:
On 06/19/2015 04:25 PM, Andres Riancho wrote:
My recommendation is that you should pass some extra arguments to the task:
* A unique task id
* A result multiprocessing.Queue
When an exception is raised you put (unique_id, exception) to the
queue
On Sat, Jun 20, 2015 at 1:41 AM, Steven D'Aprano wrote:
> On Sat, 20 Jun 2015 12:01 am, Fabien wrote:
>
>> Folks,
>>
>> I am developing a tool which works on individual entities (glaciers) and
>> do a lot of operations on them. There are many tasks to do, one after
>> each other, and each task fol
On 06/19/2015 04:25 PM, Andres Riancho wrote:
Fabien,
My recommendation is that you should pass some extra arguments to the task:
* A unique task id
* A result multiprocessing.Queue
When an exception is raised you put (unique_id, exception) to the
queue. When it succeeds you
On 06/19/2015 05:41 PM, Steven D'Aprano wrote:
On Sat, 20 Jun 2015 12:01 am, Fabien wrote:
>Folks,
>
>I am developing a tool which works on individual entities (glaciers) and
>do a lot of operations on them. There are many tasks to do, one after
>each other, and each task follows the same inter
On Sat, 20 Jun 2015 12:01 am, Fabien wrote:
> Folks,
>
> I am developing a tool which works on individual entities (glaciers) and
> do a lot of operations on them. There are many tasks to do, one after
> each other, and each task follows the same interface:
I'm afraid your description is contrad
- Original Message -
> From: "Oscar Benjamin"
> A simple way to approach this could be something like:
>
> #!/usr/bin/env python3
>
> import math
> import multiprocessing
>
> def sqrt(x):
> if x < 0:
> return 'error', x
> else:
> return 'success', math.sqrt(x)
>
On 19 June 2015 at 15:01, Fabien wrote:
> Folks,
>
> I am developing a tool which works on individual entities (glaciers) and do
> a lot of operations on them. There are many tasks to do, one after each
> other, and each task follows the same interface:
>
> def task_1(path_to_glacier_dir):
> o
- Original Message -
> From: "Fabien"
> To: python-list@python.org
> Sent: Friday, 19 June, 2015 4:01:02 PM
> Subject: Catching exceptions with multi-processing
>
> Folks,
>
> I am developing a tool which works on individual entities (glaciers)
>
Fabien,
My recommendation is that you should pass some extra arguments to the task:
* A unique task id
* A result multiprocessing.Queue
When an exception is raised you put (unique_id, exception) to the
queue. When it succeeds you put (unique_id, None). In the main process
you consu
Folks,
I am developing a tool which works on individual entities (glaciers) and
do a lot of operations on them. There are many tasks to do, one after
each other, and each task follows the same interface:
def task_1(path_to_glacier_dir):
open file1 in path_to_glacier_dir
do stuff
i
On Sat, 17 Nov 2012 14:26:43 +1100, Cameron Simpson wrote:
> On 17Nov2012 03:12, Steven D'Aprano
> wrote:
> | Is there some other trick to grab the current exception from inside an
> | except block?
>
> sys.exc_info ?
Thanks, that is just what I was looking for.
--
Steven
--
http://mail.
On 17Nov2012 03:12, Steven D'Aprano
wrote:
| Oh for the day I can drop support for Python 2.4 and 2.5...
|
|
| I have some code that needs to run in any version of Python from 2.4
| onwards. Yes, it must be a single code base.
|
| I wish to catch an exception and bind the exception to a name
Oh for the day I can drop support for Python 2.4 and 2.5...
I have some code that needs to run in any version of Python from 2.4
onwards. Yes, it must be a single code base.
I wish to catch an exception and bind the exception to a name.
In Python 2.6 onwards, I can do:
try:
something()
e
On Fri, 06 Aug 2010 01:37:17 +0100, MRAB wrote:
> The correct way to create your own exceptions is to call the
> superclass's __init__ method:
>
>
> >>> class NetActiveError(RuntimeError):
> ... def __init__(self, error):
> ... RuntimeError.__init__(self, error)
As given, that's po
On Aug 5, 2010, at 7:37 PM, MRAB wrote:
> Chris Hare wrote:
>> okay - but why does the response come back like
>> No such file or directory
>> def b
>> ('n', 'e', 't', ' ', 'a', 'l', 'r', 'e', 'a', 'd', 'y', ' ', 'r', 'u', 'n',
>> 'n', 'i', 'n', 'g')
> The class Exception saves its arguments in
Chris Hare wrote:
okay - but why does the response come back like
No such file or directory
def b
('n', 'e', 't', ' ', 'a', 'l', 'r', 'e', 'a', 'd', 'y', ' ', 'r', 'u', 'n',
'n', 'i', 'n', 'g')
The class Exception saves its arguments in the 'args' instance
attribute, and when it prints the ex
okay - but why does the response come back like
No such file or directory
def b
('n', 'e', 't', ' ', 'a', 'l', 'r', 'e', 'a', 'd', 'y', ' ', 'r', 'u', 'n',
'n', 'i', 'n', 'g')
On Aug 5, 2010, at 5:49 PM, Benjamin Kaplan wrote:
> What makes you think it has to do with user-defined exceptions?
>
What makes you think it has to do with user-defined exceptions?
>>> try :
...raise Exception("hello")
... except Exception as (errno, errText) :
... print "whatever"
...
Traceback (most recent call last):
ValueError: need more than 1 values to unpack
An Exception is an object, not a tuple o
I have a block of test code, where I am trying to raise and catch my own user
defined exception
class NetActiveError(RuntimeError):
def __init__(self,error):
self.args = error
def a():
try:
fh = open("me.txt", "r")
except Exception as (errno, errText):
print
ould be more specific (both in scope and what it catches). The Exception
class is the more generic exception that you should catch.
basically, what i want to happen is to try to run 'something' with the
wrapped fortran code and if that doesn't work (error encountered,
etc.) try something
'something' with the
wrapped fortran code and if that doesn't work (error encountered,
etc.) try something else. is there an easier way to go about doing
this? is there something i'm missing about catching exceptions here?
Thanks in advance!
--
http://mail.python.org/mailman/listinfo/python-list
En Fri, 09 Mar 2007 08:14:18 -0300, Gerard Flanagan
<[EMAIL PROTECTED]> escribió:
> Mea culpa.
Ego te absolvo in nomine Patris Guidii et Filii Python et Spiritus Sancti
Computatorium.
--
Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list
On Mar 9, 11:57 am, "Gabriel Genellina" <[EMAIL PROTECTED]>
wrote:
> En Fri, 09 Mar 2007 07:30:20 -0300, Gerard Flanagan
> <[EMAIL PROTECTED]> escribió:
>
> >> There is a serious flaw on this approach, the function can't return any
> >> false value (it would be treated as a failure).
>
> > I was te
En Fri, 09 Mar 2007 07:30:20 -0300, Gerard Flanagan
<[EMAIL PROTECTED]> escribió:
>> There is a serious flaw on this approach, the function can't return any
>> false value (it would be treated as a failure).
>
> I was teaching myself decorators more than anything, so it's not
> thought out to an
On Mar 9, 9:56 am, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote:
> En Fri, 09 Mar 2007 04:49:59 -0300, Gerard Flanagan
> <[EMAIL PROTECTED]> escribió:
>
> > Another version:
>
> > import exceptions
>
> As back in time as I could go (Python 1.5), exceptions were available as
> builtins...
>
I did
En Fri, 09 Mar 2007 05:52:35 -0300, Duncan Booth
<[EMAIL PROTECTED]> escribió:
> "Gabriel Genellina" <[EMAIL PROTECTED]> wrote:
>
>> Not the *previous* exception, but the *current* one. You must be
>> inside an "except" clause to use a bare raise.
>>
> No, you don't have to be inside an except
En Fri, 09 Mar 2007 04:49:59 -0300, Gerard Flanagan
<[EMAIL PROTECTED]> escribió:
> Another version:
>
> import exceptions
As back in time as I could go (Python 1.5), exceptions were available as
builtins...
> def onfailFalse(fn):
> def inner(*args, **kwargs):
> try:
>
"Gabriel Genellina" <[EMAIL PROTECTED]> wrote:
> Not the *previous* exception, but the *current* one. You must be
> inside an "except" clause to use a bare raise.
>
No, you don't have to be inside an except clause to use a bare raise.
A bare 'raise' will re-raise the last exception that was act
On Mar 8, 10:31 am, "Gabriel Genellina" <[EMAIL PROTECTED]>
wrote:
> En Thu, 08 Mar 2007 06:17:37 -0300, Gerard Flanagan
> <[EMAIL PROTECTED]> escribió:
>
> > @onfail(False)
> > def a(x):
> > if x == 1:
> > return 'function a succeeded'
> > else:
> > raise
>
> I know it's ir
En Thu, 08 Mar 2007 21:11:54 -0300, Steven D'Aprano
<[EMAIL PROTECTED]> escribió:
>>> @onfail(False)
>>> def a(x):
>>> if x == 1:
>>> return 'function a succeeded'
>>> else:
>>> raise
>
> I thought "raise" on its own was supposed to re-raise the previous
> exception, but
Steven D'Aprano <[EMAIL PROTECTED]> writes:
> Are you saying it only works as advertised within the except clause of a
> try...except block?
I think that's the idea. It hadn't occurred to me that it could be
used any other way, but I don't have the docs in front of me right
now, so maybe I missed
On Thu, 08 Mar 2007 16:19:27 -0800, Paul Rubin wrote:
> Steven D'Aprano <[EMAIL PROTECTED]> writes:
>> I thought "raise" on its own was supposed to re-raise the previous
>> exception, but I've just tried it in the interactive interpreter and it
>> doesn't work for me.
>
> It means you can catch a
Steven D'Aprano <[EMAIL PROTECTED]> writes:
> I thought "raise" on its own was supposed to re-raise the previous
> exception, but I've just tried it in the interactive interpreter and it
> doesn't work for me.
It means you can catch an exception, do stuff with it, and then pass
it upward to earlie
On Thu, 08 Mar 2007 06:31:20 -0300, Gabriel Genellina wrote:
> En Thu, 08 Mar 2007 06:17:37 -0300, Gerard Flanagan
> <[EMAIL PROTECTED]> escribió:
>
>> @onfail(False)
>> def a(x):
>> if x == 1:
>> return 'function a succeeded'
>> else:
>> raise
>
> I know it's irrelevan
En Thu, 08 Mar 2007 13:31:14 -0300, Aahz <[EMAIL PROTECTED]> escribió:
> In article <[EMAIL PROTECTED]>,
> Paul Sijben <[EMAIL PROTECTED]> wrote:
>>
>> in a worker thread setup that communicates via queues is it possible to
>> catch exceptions raised by the worker executed, put them in an object
In article <[EMAIL PROTECTED]>,
Paul Sijben <[EMAIL PROTECTED]> wrote:
>
>in a worker thread setup that communicates via queues is it possible to
>catch exceptions raised by the worker executed, put them in an object
>and send them over the queue to another thread where the exception is
>raised in
En Thu, 08 Mar 2007 06:17:37 -0300, Gerard Flanagan
<[EMAIL PROTECTED]> escribió:
> @onfail(False)
> def a(x):
> if x == 1:
> return 'function a succeeded'
> else:
> raise
I know it's irrelevant, as you use a bare except, but such raise looks a
bit ugly...
--
Gabriel
On Mar 7, 7:32 pm, "Arnaud Delobelle" <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Imagine I have three functions a(x), b(x), c(x) that each return
> something or raise an exception. Imagine I want to define a function
> that returns a(x) if possible, otherwise b(x), otherwise c(x),
> otherwise raise
MonkeeSage a écrit :
> On Mar 7, 4:58 pm, Bruno Desthuilliers
> <[EMAIL PROTECTED]> wrote:
>>except_retry: # the missing(???) keyword you're after
>
> What is 'except_retry'?
A totally imaginary statement that would do what the OP is looking for.
> To the OP, with the loop and the callables
On Wed, 07 Mar 2007 10:32:53 -0800, Arnaud Delobelle wrote:
> Hi all,
>
> Imagine I have three functions a(x), b(x), c(x) that each return
> something or raise an exception. Imagine I want to define a function
> that returns a(x) if possible, otherwise b(x), otherwise c(x),
> otherwise raise Can
On Mar 7, 4:58 pm, Bruno Desthuilliers
<[EMAIL PROTECTED]> wrote:
>except_retry: # the missing(???) keyword you're after
What is 'except_retry'?
To the OP, with the loop and the callables you could also break out of
the loop when the condition is met and use the else condition to raise
the ex
Arnaud Delobelle schrieb:
> On Mar 7, 8:52 pm, Larry Bates <[EMAIL PROTECTED]> wrote:
> [snip]
>> Without knowing more about the functions and the variable it is somewhat
>> hard to tell what you are trying to accomplish. If a, b, c are functions
>> that act on x when it is a different type, chang
Gabriel Genellina a écrit :
> En Wed, 07 Mar 2007 18:48:18 -0300, Arnaud Delobelle
> <[EMAIL PROTECTED]> escribió:
>
>> for f in int, float, complex:
>> try:
>> return f(x)
>> except ValueError:
>> continue
>> raise CantDoIt
>>
>> But if the three things I want to do are
Arnaud Delobelle a écrit :
> On Mar 7, 8:52 pm, Larry Bates <[EMAIL PROTECTED]> wrote:
> [snip]
>
>>Without knowing more about the functions and the variable it is somewhat
>>hard to tell what you are trying to accomplish. If a, b, c are functions
>>that act on x when it is a different type, chan
En Wed, 07 Mar 2007 18:48:18 -0300, Arnaud Delobelle
<[EMAIL PROTECTED]> escribió:
> for f in int, float, complex:
> try:
> return f(x)
> except ValueError:
> continue
> raise CantDoIt
>
> But if the three things I want to do are not callable objects but
> chunks of code
On Mar 7, 3:04 pm, [EMAIL PROTECTED] wrote:
> On Mar 7, 2:48 pm, "Arnaud Delobelle" <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > I'm not really thinking about this situation so let me clarify. Here
> > is a simple concrete example, taking the following for the functions
> > a,b,c I mention in my origin
Gabriel Genellina a écrit :
> En Wed, 07 Mar 2007 19:00:59 -0300, Bruno Desthuilliers
> <[EMAIL PROTECTED]> escribió:
>
>> this kind of cose is exactly what OO polymorphic dispatch is supposed to
>
>
> this kind of cose?
sorry
s/cose/code/
> Ce genre de chose?
>
En quelques sortes, oui, quo
On Mar 7, 2:48 pm, "Arnaud Delobelle" <[EMAIL PROTECTED]> wrote:
>
> I'm not really thinking about this situation so let me clarify. Here
> is a simple concrete example, taking the following for the functions
> a,b,c I mention in my original post.
> - a=int
> - b=float
> - c=complex
> - x i
Arnaud Delobelle a écrit :
> Hi all,
>
> Imagine I have three functions a(x), b(x), c(x) that each return
> something or raise an exception. Imagine I want to define a function
> that returns a(x) if possible, otherwise b(x), otherwise c(x),
> otherwise raise CantDoIt.
>
> Here are three ways I
On Mar 7, 8:52 pm, Larry Bates <[EMAIL PROTECTED]> wrote:
[snip]
> Without knowing more about the functions and the variable it is somewhat
> hard to tell what you are trying to accomplish. If a, b, c are functions
> that act on x when it is a different type, change to one function that
> can hand
En Wed, 07 Mar 2007 19:00:59 -0300, Bruno Desthuilliers
<[EMAIL PROTECTED]> escribió:
> this kind of cose is exactly what OO polymorphic dispatch is supposed to
this kind of cose? Ce genre de chose?
--
Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list
Larry Bates a écrit :
(snip)
> def d(x):
> if isinstance(x, basestring):
> #
> # Code here for string
> #
> elif isinstance(x, int):
> #
> # Code here for int
> #
> elif isinstance(x, float):
> #
> # Code here for string
>
Miki a écrit :
> Hello Arnaud,
>
>
>>Imagine I have three functions a(x), b(x), c(x) that each return
>>something or raise an exception. Imagine I want to define a function
>>that returns a(x) if possible, otherwise b(x), otherwise c(x),
>>otherwise raise CantDoIt.
>
> Exceptions are for error
Arnaud Delobelle wrote:
> Hi all,
>
> Imagine I have three functions a(x), b(x), c(x) that each return
> something or raise an exception. Imagine I want to define a function
> that returns a(x) if possible, otherwise b(x), otherwise c(x),
> otherwise raise CantDoIt.
>
> Here are three ways I can
In <[EMAIL PROTECTED]>, Miki wrote:
> Exceptions are for error handling, not flow control.
That's not true, they are *exceptions* not *errors*. They are meant to
signal exceptional situations. And at least under the cover it's used in
every ``for``-loop because the end condition is signaled by
In <[EMAIL PROTECTED]>, Arnaud Delobelle
wrote:
> # This one only works because a,b,c are functions
> # Moreover it seems like an abuse of a loop construct to me
> def rolled_first(x):
> for f in a, b, c:
> try:
> return f(x)
> except:
> continue
> r
On 7 Mar, 19:26, "Miki" <[EMAIL PROTECTED]> wrote:
> Hello Arnaud,
Hi Miki
[snip]
> Exceptions are for error handling, not flow control.
Maybe but it's not always that clear cut! As error handling is a form
of flow control the two have to meet somewhere.
[snip]
> As a side note, try to avoid "c
Hello Arnaud,
> Imagine I have three functions a(x), b(x), c(x) that each return
> something or raise an exception. Imagine I want to define a function
> that returns a(x) if possible, otherwise b(x), otherwise c(x),
> otherwise raise CantDoIt.
Exceptions are for error handling, not flow control.
Hi all,
Imagine I have three functions a(x), b(x), c(x) that each return
something or raise an exception. Imagine I want to define a function
that returns a(x) if possible, otherwise b(x), otherwise c(x),
otherwise raise CantDoIt.
Here are three ways I can think of doing it:
--
# This o
Stargaming & Diez,
thanks very much!
Stargaming wrote:
> Paul Sijben schrieb:
>> All,
>>
>> in a worker thread setup that communicates via queues is it possible to
>> catch exceptions raised by the worker executed, put them in an object
>> and send them over the queue to another thread where the
Paul Sijben schrieb:
> All,
>
> in a worker thread setup that communicates via queues is it possible to
> catch exceptions raised by the worker executed, put them in an object
> and send them over the queue to another thread where the exception is
> raised in that scope?
>
> considering that an e
Paul Sijben wrote:
> All,
>
> in a worker thread setup that communicates via queues is it possible to
> catch exceptions raised by the worker executed, put them in an object
> and send them over the queue to another thread where the exception is
> raised in that scope?
>
> considering that an ex
All,
in a worker thread setup that communicates via queues is it possible to
catch exceptions raised by the worker executed, put them in an object
and send them over the queue to another thread where the exception is
raised in that scope?
considering that an exception is an object I feel it ought
[EMAIL PROTECTED] wrote:
>
> class Test(object):
> ...
> def _setx(self,strvalue):
> try:
> self._x = float(strvalue)
> except ValueError:
> print 'Warning : could not set x attribute to %s' % strvalue
> ...
I think what you are looking for is:
On 16 dic, 10:24, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> > Python isn't Java. Are you sure you need properties?
> I do not know Java. But, object.x = value looks much better than
> object.set_x(value) . Is there any harm in doing it, provided I have to
> do more than just storing the val
On Sat, 16 Dec 2006 05:24:28 -0800, [EMAIL PROTECTED] wrote:
>> > Hi, In the following program, I have a class Test which has a property
>> > x. Its setx function gets a string value and converts it into a float
>> > and stores into it.
>>
>> [snip code]
>>
>> Python isn't Java. Are you sure you n
Steven D'Aprano wrote:
> On Sat, 16 Dec 2006 03:54:52 -0800, [EMAIL PROTECTED] wrote:
>
> > Hi, In the following program, I have a class Test which has a property
> > x. Its setx function gets a string value and converts it into a float
> > and stores into it.
>
> [snip code]
>
> Python isn't Java
On Sat, 16 Dec 2006 17:36:00 +0530, Amit Khemka wrote:
> If I gather correctly, i guess in case of errors/exceptions in a class
> function, you want to get the error string. One thing that comes
> straight to my mind is, in such a case use a return statement in
> functions with two arguments.
>
>
On Sat, 16 Dec 2006 03:54:52 -0800, [EMAIL PROTECTED] wrote:
> Hi, In the following program, I have a class Test which has a property
> x. Its setx function gets a string value and converts it into a float
> and stores into it.
[snip code]
Python isn't Java. Are you sure you need properties?
>
On 16 Dec 2006 03:54:52 -0800, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Hi, In the following program, I have a class Test which has a property
> x. Its setx function gets a string value and converts it into a float
> and stores into it.
>
> class Test(object):
> def _getx(self):
>
Hi, In the following program, I have a class Test which has a property
x. Its setx function gets a string value and converts it into a float
and stores into it.
class Test(object):
def _getx(self):
return self._x
def _setx(self,strvalue):
try:
self._x = float(st
76 matches
Mail list logo
