"OKB (not okblacke)" writes:
> This is an interesting setup, but I'm not sure I see why you need
> it. If you know that, in a particular context, you want toy(x, 0) to
> result in 42 instead of ZeroDivisionError,
... and that's the point. You don't know whether you'll need it at the
c
Mark Wooding wrote:
> Any code called from within the `with handler' context will (unless
> overridden) cause a call `toy(x, 0)' to return 42. Even if the `with
> handler' block calls other functions and so on. Note also that the
> expression of this is dynamically further from where the error is
On Mon, 06 Dec 2010 08:32:18 -0500, Mel wrote:
> Apparently, at the end of his research, Alan Turing was trying out the idea
> of 'oracles', where a computable process would have access to an
> uncomputable process to get particular results. I would imagine that the
> idea here was to clarify
Carl Banks writes:
> On Dec 6, 12:58 pm, m...@distorted.org.uk (Mark Wooding) wrote:
> > def toy(x, y):
> > r = restart('use-value')
> > with r:
> > if y == 0:
> > error(ZeroDivisionError())
> > r.result = x/y
> > return
On Dec 6, 2:42 pm, Carl Banks wrote:
> Or, you could just put your try...finally inside a loop.
er, try...except
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Dec 6, 12:58 pm, m...@distorted.org.uk (Mark Wooding) wrote:
> Paul Rubin writes:
> > You know, I've heard the story from language designers several times
> > over, that they tried putting resumable exceptions into their languages
> > and it turned out to be a big mess, so they went to terminat
Paul Rubin writes:
> You know, I've heard the story from language designers several times
> over, that they tried putting resumable exceptions into their languages
> and it turned out to be a big mess, so they went to termination
> exceptions that fixed the issue.
That seems very surprising to m
On 12/6/2010 12:40 AM, Steve Holden wrote:
On 12/6/2010 9:14 AM, Paul Rubin wrote:
m...@distorted.org.uk (Mark Wooding) writes:
The most obvious improvement is resumable exceptions.
You know, I've heard the story from language designers several times
over, that they tried putting resumable ex
On Mon, 06 Dec 2010 09:54:46 -0800, Dennis Lee Bieber wrote:
> On Mon, 06 Dec 2010 00:14:11 -0800, Paul Rubin
> declaimed the following in gmane.comp.python.general:
>
>
>> exceptions that fixed the issue. Are there any languages out there
>> with resumable exceptions? Escaping to a debugger
On 12/2/2010 10:09 AM, Paul Rubin wrote:
MRAB writes:
When writing the C code for the new regex module I thought that it
would've been easier if I could've used exceptions to propagate errors
and unwind the stack, instead of having to return an error code which
had to be checked by the caller,
Paul Rubin wrote:
> m...@distorted.org.uk (Mark Wooding) writes:
>> The most obvious improvement is resumable exceptions.
>
> You know, I've heard the story from language designers several times
> over, that they tried putting resumable exceptions into their languages
> and it turned out to be a
On 12/05/10 15:52, Tim Harig wrote:
> On 2010-12-05, Tim Harig wrote:
>> Another, questionable but useful use, is to ignore the complex accounting
>> of your position inside of a complex data structure. You can continue
>> moving through the structure until an exception is raised indicating
>> th
On 12/6/2010 9:14 AM, Paul Rubin wrote:
> m...@distorted.org.uk (Mark Wooding) writes:
>> The most obvious improvement is resumable exceptions.
>
> You know, I've heard the story from language designers several times
> over, that they tried putting resumable exceptions into their languages
> and i
m...@distorted.org.uk (Mark Wooding) writes:
> The most obvious improvement is resumable exceptions.
You know, I've heard the story from language designers several times
over, that they tried putting resumable exceptions into their languages
and it turned out to be a big mess, so they went to term
On 05/12/2010 21:01, Martin v. Loewis wrote:
result = myfunction (vars)
if not result:
# error condition
Now above I first realized that the function can also return an empty
list under some conditions and so changed it to
If your function returns a list when successful, it should not re
> result = myfunction (vars)
>
> if not result:
> # error condition
>
> Now above I first realized that the function can also return an empty
> list under some conditions and so changed it to
If your function returns a list when successful, it should not return
False in the error case. Ins
On 12/04/2010 11:42 PM, Steven D'Aprano wrote:
On Sun, 05 Dec 2010 04:13:02 +, Tim Harig wrote:
str.find is more troublesome, because the sentinel -1 doesn't propagate
and is a common source of errors:
result = string[string.find(delim):]
will return a plausible-looking but incorrect result
On 2010-12-05, Tim Harig wrote:
> On 2010-12-05, Paul Rubin wrote:
>> Tim Harig writes:
>>> The fact that I bothered to create classes for the dice and roles, rather
>>> then simply iterating over a list of numbers, should tell you that I
>>> produced was of a far more flexible nature; includin
On 2010-12-05, Paul Rubin wrote:
> Tim Harig writes:
>> The fact that I bothered to create classes for the dice and roles, rather
>> then simply iterating over a list of numbers, should tell you that I
>> produced was of a far more flexible nature; including the support for
>> roles with dice ha
Tim Harig writes:
> The fact that I bothered to create classes for the dice and roles, rather
> then simply iterating over a list of numbers, should tell you that I
> produced was of a far more flexible nature; including the support for
> roles with dice having different numbers of sides.
fr
On 2010-12-05, Paul Rubin wrote:
> Tim Harig writes:
>> A friend was trying to derive a mathematical formula for determining
>> the possibly distribution of results from rolling arbitrariy numbers
>> of m n-sided dice
>
> http://en.wikipedia.org/wiki/Multinomial_distribution
I sure he redisc
On Sun, 05 Dec 2010 04:13:02 +, Tim Harig wrote:
> Anything it is an obvious
> error *should* throw an exception.
Well, maybe... there are good use-cases for returning a sentinel. E.g.
str.find, or the use of quiet NANs in IEEE floating point and decimal
maths.
NANs and INFs in floating po
Tim Harig writes:
> A friend was trying to derive a mathematical formula for determining
> the possibly distribution of results from rolling arbitrariy numbers
> of m n-sided dice
http://en.wikipedia.org/wiki/Multinomial_distribution
> To generate a listing of all (non-uniq) possible roles,
On 2010-12-05, Tim Harig wrote:
> Another, questionable but useful use, is to ignore the complex accounting
> of your position inside of a complex data structure. You can continue
> moving through the structure until an exception is raised indicating
> that you have reached a boundary of the stru
On 2010-12-05, Harishankar wrote:
>> Or consider this code:
>>
>> if y != 0:
>> result = x/y
>> else:
>> handle_division_by_zero()
>>
>>
>> This is also unsafe unless you know the type of y. Suppose y is an
>> interval quantity that straddles zero, then division by y may fail even
>> th
On Sun, 05 Dec 2010 01:59:27 +, Steven D'Aprano wrote:
> Of course, this is mainly of theoretical concern. In practice, "Look
> Before You Leap" (test first, then process) is often fine. But there are
> traps to look out for. For example, unless you are running a single-
> process machine, the
On Sat, 04 Dec 2010 17:07:45 +, Harishankar wrote:
> I find a bit cumbersome
> that exceptions are advocated for certain conditions which can be sanely
> worked around in the application's logic and even avoided, rather than
> waiting for them to get caught and providing an unsatisfactory resu
On 12/4/2010 12:07 PM, Harishankar wrote:
Of course not. But going by the replies here, it appears that Python has
made exceptions as the "norm" for error handling which is ironical
considering the meaning of the word "exception".
In communications parlance, 'exception' = out-of-band signal or
On Sat, 4 Dec 2010 17:07:45 + (UTC)
Harishankar wrote:
> Of course not. But going by the replies here, it appears that Python has
> made exceptions as the "norm" for error handling which is ironical
> considering the meaning of the word "exception". I find a bit cumbersome
> that exceptions
> You appear to be suffering from the delusion that all exceptions must be
> caught and handled. This is far from being the case. But still, better
> to have your top-level code "littered with exception handlers" than to
> have your functions "littered with if statements".
Of course not. But going
On 12/2/2010 11:42 PM, Harishankar wrote:
> One of the reasons why I feared to do this is because I need to know each
> and every exception that might be thrown by the function and litter my
> top-level code with too many exception handlers.
>
You appear to be suffering from the delusion that al
On 2010-12-03, Harishankar wrote:
> On Fri, 03 Dec 2010 14:31:43 +, Mark Wooding wrote:
>> In general, recovering from an exceptional condition requires three
>> activities:
>>
>> * doing something about the condition so that the program can continue
>> running;
>>
>> * identifying s
On 2010-12-04, alex23 wrote:
> On Dec 3, 2:12 am, Tim Harig wrote:
>> Actually, I thought that debate was resolved years ago. I cannot think of
>> a single recently developed programming language that does not provide
>> exception handling mechanisms because they have been proven more reliable.
On Dec 3, 2:12 am, Tim Harig wrote:
> Actually, I thought that debate was resolved years ago. I cannot think of
> a single recently developed programming language that does not provide
> exception handling mechanisms because they have been proven more reliable.
Google's Go lacks exceptions and I
In article ,
Harishankar wrote:
>On Thu, 02 Dec 2010 17:33:47 -0800, Aahz wrote:
>>
>> Please demonstrate that using ``if`` blocks for True/False is impler and
>> cleaner than using ``try`` blocks to handle exceptions.
>
>It is my personal preference and coding style for certain situations I
>en
On 12/3/2010 6:31 AM Mark Wooding said...
It's easy to show that a resumable exception system can do everything
that a nonresumable system (like Python's) can do (simply put all of the
recovery logic at the resume point); but the converse is not true.
There are some other fringe benefits to res
On Thu, 02 Dec 2010 17:33:47 -0800, Aahz wrote:
> Please demonstrate that using ``if`` blocks for True/False is impler and
> cleaner than using ``try`` blocks to handle exceptions.
It is my personal preference and coding style for certain situations I
encounter in my own programs and not somethi
On Fri, 03 Dec 2010 14:31:43 +, Mark Wooding wrote:
> The most obvious improvement is resumable exceptions.
This is probably what I had in mind but I just couldn't explain it the
way you did below.
>
> In general, recovering from an exceptional condition requires three
> activities:
>
>
Steven D'Aprano writes:
> On Thu, 02 Dec 2010 16:35:08 +, Mark Wooding wrote:
> > There are better ways to handle errors than Python's exception system.
>
> I'm curious -- what ways would they be?
The most obvious improvement is resumable exceptions.
In general, recovering from an exception
Harishankar wrote:
> I think I understand the general trend of what you're saying. It
> definitely requires a mindset change. I still feel that user-defined
> exception classes might not be the way, but maybe I should allow the
> built-in exceptions which are thrown by library functions to follow
On 2010-12-03, Paul Rubin wrote:
> Steven D'Aprano writes:
>>> There are better ways to handle errors than Python's exception system.
>> I'm curious -- what ways would they be?
>> I'm aware of three general exception handling techniques: ...
>> What else is there?
>
> The Erlang approach is to ch
Steven D'Aprano writes:
>> There are better ways to handle errors than Python's exception system.
> I'm curious -- what ways would they be?
> I'm aware of three general exception handling techniques: ...
> What else is there?
The Erlang approach is to chop the application into a lot of very
light
On Thu, 02 Dec 2010 16:35:08 +, Mark Wooding wrote:
>> 3. Philosophically I think exception handling is the wrong approach to
>> error management.
>
> There are better ways to handle errors than Python's exception system.
I'm curious -- what ways would they be?
I'm aware of three general ex
On 2010-12-03, Harishankar wrote:
> On Thu, 02 Dec 2010 16:52:57 +, Tim Harig wrote:
>
>> If you are having that issue, then you are likely placing the try blocks
>> at too low of a level in your code. In general you will find that most
>> systems have a gateway function as an entry point to
On Thu, 02 Dec 2010 16:52:57 +, Tim Harig wrote:
> If you are having that issue, then you are likely placing the try blocks
> at too low of a level in your code. In general you will find that most
> systems have a gateway function as an entry point to the system. If
> there is not one already
On Fri, 03 Dec 2010 08:06:35 +1100, Ben Finney wrote:
> Raise exceptions for exceptional cases, and define the function
> interface so that it's doing one clear job only. Often that involves
> breaking a complicated function into several collaborating functions
> with simpler interfaces.
This is
In article ,
Harishankar wrote:
>
>There are some reasons why I hate exceptions but that is a different
>topic. However, in short I can say that personally:
>
>1. I hate try blocks which add complexity to the code when none is
>needed. Try blocks make code much more unreadable in my view and I
On 12/2/2010 10:13 AM, Terry Reedy wrote:
Aside from the other issues raised, I will just note that is more common
to return None when there is no answer (for whatever reason) rather than
False and explicitly compare 'is None' than 'is False'.
The basic problem is that the original design of
Harishankar writes:
> On Thu, 02 Dec 2010 22:19:25 +1100, Ben Finney wrote:
>
> > More details of the problem you're trying to solve would help with
> > giving specific advice.
>
> I'm writing functions with multiple points of failure exits. I use
> return False as a way to flag the error conditi
On 2010-12-02, Paul Rubin wrote:
> Tim Harig writes:
>> I am not talking about what setjmp() has to do, I am talking about what
>> *you* have to do after setjmp() returns. If you have allocated memory in
>> intermediate functions and you don't have a reference to them outside of
>> the functions
On 2010-12-02, MRAB wrote:
> On 02/12/2010 19:15, Tim Harig wrote:
>> On 2010-12-02, Paul Rubin wrote:
>>> Tim Harig writes:
> longjmp. Alternatively you can have an auxiliary stack of cleanup
> records that the longjmp handler walks through. Of course if you do
Only if you a
Tim Harig writes:
> I am not talking about what setjmp() has to do, I am talking about what
> *you* have to do after setjmp() returns. If you have allocated memory in
> intermediate functions and you don't have a reference to them outside of
> the functions that longjmp() bypasses from returning
On 02/12/2010 19:15, Tim Harig wrote:
On 2010-12-02, Paul Rubin wrote:
Tim Harig writes:
longjmp. Alternatively you can have an auxiliary stack of cleanup
records that the longjmp handler walks through. Of course if you do
Only if you already have pointers to *all* of the data structures
On 12/2/2010 1:31 PM, Terry Reedy wrote:
> It turns out that try block are computationally lighter weight (faster)
> for normal execution ;-)
Though that alone would hardly be sufficient reason to use them.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
PyCon 2011 Atl
On 2010-12-02, Paul Rubin wrote:
> Tim Harig writes:
>>> longjmp. Alternatively you can have an auxiliary stack of cleanup
>>> records that the longjmp handler walks through. Of course if you do
>>
>> Only if you already have pointers to *all* of the data structures at
>> the point where you pu
Tim Harig writes:
>> longjmp. Alternatively you can have an auxiliary stack of cleanup
>> records that the longjmp handler walks through. Of course if you do
>
> Only if you already have pointers to *all* of the data structures at
> the point where you put your setjmp().
The setjmp point only h
On 2010-12-02, Paul Rubin wrote:
> Tim Harig writes:
>>> That's called longjmp.
>>
>> The problem is that you might have partially allocated data structures
>> that you need to free before you can go anywhere.
>
> Alloca can help with that since the stack stuff gets released by the
> longjmp. Al
On 02/12/2010 18:09, Paul Rubin wrote:
MRAB writes:
When writing the C code for the new regex module I thought that it
would've been easier if I could've used exceptions to propagate errors
and unwind the stack, instead of having to return an error code which
had to be checked by the caller, an
On 2010-12-02, Paul Rubin wrote:
> MRAB writes:
>> When writing the C code for the new regex module I thought that it
>> would've been easier if I could've used exceptions to propagate errors
>> and unwind the stack, instead of having to return an error code which
>> had to be checked by the call
Tim Harig writes:
>> That's called longjmp.
>
> The problem is that you might have partially allocated data structures
> that you need to free before you can go anywhere.
Alloca can help with that since the stack stuff gets released by the
longjmp. Alternatively you can have an auxiliary stack o
On 12/2/2010 9:56 AM, Harishankar wrote:
There are some reasons why I hate exceptions but that is a different
topic. However, in short I can say that personally:
1. I hate try blocks which add complexity to the code when none is
needed. Try blocks make code much more unreadable in my view and I
On 2010-12-02, Paul Rubin wrote:
> MRAB writes:
>> When writing the C code for the new regex module I thought that it
>> would've been easier if I could've used exceptions to propagate errors
>> and unwind the stack, instead of having to return an error code which
>> had to be checked by the call
Aside from the other issues raised, I will just note that is more common
to return None when there is no answer (for whatever reason) rather than
False and explicitly compare 'is None' than 'is False'.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
MRAB writes:
> When writing the C code for the new regex module I thought that it
> would've been easier if I could've used exceptions to propagate errors
> and unwind the stack, instead of having to return an error code which
> had to be checked by the caller, and then have the caller explicitly
On 02/12/2010 16:12, Tim Harig wrote:
On 2010-12-02, Harishankar wrote:
I understand that the error vs exception debate is quite a big one in the
programming community as a whole and I don't consider myself very
Actually, I thought that debate was resolved years ago. I cannot think of
a sing
Harishankar wrote:
As I said before, the way exceptions are caught seem to me to be the most
confusing bit. Non-atomic operations always worry me. What if my function
which is wrapped inside a try block has two different statements that
raised the same exception but for different reasons? With
On 2010-12-02, Harishankar wrote:
>> Actually, finer grained error handling commonly covers up bugs. If you
>> want to find bugs, you want to make the program prone to crashing if a
>> bug is present. It is all too easy to accidently mistake the return
>> value of a function as error condition a
Harishankar writes:
> There are some reasons why I hate exceptions but that is a different
> topic. However, in short I can say that personally:
>
> 1. I hate try blocks which add complexity to the code when none is
> needed. Try blocks make code much more unreadable in my view and I use it
>
On Thu, 02 Dec 2010 15:53:49 +, Tim Harig wrote:
> If you are using exceptions to try to catch bug then you are using them
> improperly. Exceptions (with the exception (no pun intended) of
> AssertionError) are designed to catch error conditions, not bugs.
I agree. But more specifically some
On 2010-12-02, Harishankar wrote:
> I understand that the error vs exception debate is quite a big one in the
> programming community as a whole and I don't consider myself very
Actually, I thought that debate was resolved years ago. I cannot think of
a single recently developed programming la
On Thu, 02 Dec 2010 07:35:18 -0800, Stephen Hansen wrote:
> Exceptions aren't about "error management"; they are about exceptional
> conditions: some are errors, others are entirely normal situations you
> know are going to happen (such as reaching the end of a sequence as you
> iterate over it: t
On 2010-12-02, Harishankar wrote:
> I am also wary of using larger catch-all try blocks or try blocks with
> multiple exception exits (which seem to make tracking subtle bugs
> harder). I prefer the philosophy of dealing with errors immediately as
If you are using exceptions to try to catch bu
On Thu, 02 Dec 2010 15:25:55 +, Tim Harig wrote:
>...
>...
>
> Perhaps you should take a look at how Erlang appoaches exception
> handling. Being message passing and concurrency oriented, Erlang
> encourages ignoring error conditions within worker processes. Errors
> instead cause the worker
On 12/2/10 6:56 AM, Harishankar wrote:
> On Thu, 02 Dec 2010 08:44:11 -0600, Tim Chase wrote:
>
>> On 12/02/2010 08:18 AM, Harishankar wrote:
>>> Here I'm using it to compare the result of a function where I
>>> specifically return False on error condition,
>>
>> This sounds exactly like the reaso
On 2010-12-02, Steve Holden wrote:
> On 12/2/2010 9:13 AM, Harishankar wrote:
>>
>> if not result:
>> # error condition
>>
>> Now above I first realized that the function can also return an empty
>> list under some conditions and so changed it to
>>
>> if result == False:
>> # error co
On Thu, 02 Dec 2010 10:19:35 -0500, Steve Holden wrote:
> On 12/2/2010 9:13 AM, Harishankar wrote:
>> On Thu, 02 Dec 2010 22:19:25 +1100, Ben Finney wrote:
>>
>>> More details of the problem you're trying to solve would help with
>>> giving specific advice.
>>
>> I'm writing functions with multi
On 2010-12-02, Harishankar wrote:
> There are some reasons why I hate exceptions but that is a different
> topic. However, in short I can say that personally:
>
> 1. I hate try blocks which add complexity to the code when none is
> needed. Try blocks make code much more unreadable in my view and
On 12/2/2010 9:56 AM, Harishankar wrote:
> 3. Philosophically I think exception handling is the wrong approach to
> error management. I have never grown up programming with exceptions in C
> and I couldn't pick up the habit with python either. Did I mention that I
> detest try blocks? try blocks
On 12/2/2010 9:13 AM, Harishankar wrote:
> On Thu, 02 Dec 2010 22:19:25 +1100, Ben Finney wrote:
>
>> More details of the problem you're trying to solve would help with
>> giving specific advice.
>
> I'm writing functions with multiple points of failure exits. I use return
> False as a way to fl
On Thu, 02 Dec 2010 08:44:11 -0600, Tim Chase wrote:
> On 12/02/2010 08:18 AM, Harishankar wrote:
>> Here I'm using it to compare the result of a function where I
>> specifically return False on error condition,
>
> This sounds exactly like the reason to use exceptions...you have an
> exceptional
On 12/02/2010 08:18 AM, Harishankar wrote:
Here I'm using it to compare the result of a function where I
specifically return False on error condition,
This sounds exactly like the reason to use exceptions...you have
an exceptional error condition.
-tkc
--
http://mail.python.org/mailman/lis
On Thu, 02 Dec 2010 02:49:50 -0800, Stephen Hansen wrote:
>...
>...
>...
> * P.S. I'm not saying its never right to use "is" outside of The
> Singletons. Just that its probably not, for most people, what they
> actually should do in most code. There are numerous counter-examples, of
> course. Its j
On Thu, 02 Dec 2010 22:19:25 +1100, Ben Finney wrote:
> More details of the problem you're trying to solve would help with
> giving specific advice.
I'm writing functions with multiple points of failure exits. I use return
False as a way to flag the error condition rather than raising
exception
Harishankar writes:
> When I run pychecker through my modules I get the message that
> comparisons with "False" is not necessary and that it might yield
> unexpected results.
Good advice.
> Yet in some situations I need to specifically check whether False was
> returned or None was returned. Wh
On 12/2/10 2:02 AM, Harishankar wrote:
> On Thu, 02 Dec 2010 00:15:42 -0800, Alice Bevan–McGregor wrote:
>> The bool type is a subclass of int! (Run those lines in a Python
>> interpreter to see. ;)
>>
>>> if var == False:
>>
>> if var is False: …
>
> So "var is False" is safer to use when I wan
On Thu, 02 Dec 2010 09:58:18 +, Nobody wrote:
> If you want to test specifically for True, False or None, use "is"
> rather than an equality check. This eliminates the warning and doesn't
> risk misleading someone reading the code.
Thanks so much for this very specific answer. I guess "is" is
On Thu, 02 Dec 2010 00:15:42 -0800, Alice Bevan–McGregor wrote:
> Howdy!
Good day to you!
> (False == 0) is True
> (True == 1) is True
I see. Thanks for this. I suspected this, but wasn't sure.
> The bool type is a subclass of int! (Run those lines in a Python
> interpreter to see. ;)
>
>>
On Thu, 02 Dec 2010 07:28:30 +, Harishankar wrote:
> When I run pychecker through my modules I get the message that
> comparisons with "False" is not necessary and that it might yield
> unexpected results.
>
> Yet in some situations I need to specifically check whether False was
> returned
Howdy!
When I run pychecker through my modules I get the message that
comparisons with "False" is not necessary and that it might yield
unexpected results.
Comparisons against False -are- dangerous, demonstrated below.
Yet in some situations I need to specifically check whether False was
ret
89 matches
Mail list logo
