* 2010-12-06 00:14 (-0800), Paul Rubin wrote:
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. Are there
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
OKB (not okblacke) brennospamb...@nobrenspambarn.net 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
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
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 it
On 12/05/10 15:52, Tim Harig wrote:
On 2010-12-05, Tim Harig user...@ilthio.net 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
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 big
On 12/2/2010 10:09 AM, Paul Rubin wrote:
MRABpyt...@mrabarnett.plus.com 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
On Mon, 06 Dec 2010 09:54:46 -0800, Dennis Lee Bieber wrote:
On Mon, 06 Dec 2010 00:14:11 -0800, Paul Rubin no.em...@nospam.invalid
declaimed the following in gmane.comp.python.general:
exceptions that fixed the issue. Are there any languages out there
with resumable exceptions?
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
Paul Rubin no.em...@nospam.invalid 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
On Dec 6, 12:58 pm, m...@distorted.org.uk (Mark Wooding) wrote:
Paul Rubin no.em...@nospam.invalid 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
On Dec 6, 2:42 pm, Carl Banks pavlovevide...@gmail.com 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
Carl Banks pavlovevide...@gmail.com 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
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
Tim Harig user...@ilthio.net 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
On 2010-12-05, Paul Rubin no.em...@nospam.invalid wrote:
Tim Harig user...@ilthio.net 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
On 2010-12-05, Tim Harig user...@ilthio.net wrote:
On 2010-12-05, Paul Rubin no.em...@nospam.invalid wrote:
Tim Harig user...@ilthio.net 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
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 = 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. Instead,
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
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 all
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 by the
On Sat, 4 Dec 2010 17:07:45 + (UTC)
Harishankar v.harishan...@gmail.com 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
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, 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 result.
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 2010-12-05, Harishankar v.harishan...@gmail.com 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
On 2010-12-05, Tim Harig user...@ilthio.net 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
Tim Harig user...@ilthio.net 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)
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
On 2010-12-05, Paul Rubin no.em...@nospam.invalid wrote:
Tim Harig user...@ilthio.net 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
On 2010-12-03, Paul Rubin no.em...@nospam.invalid wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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: ...
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 its
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
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:
*
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
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
In article mailman.187.1291397553.2649.python-l...@python.org,
Harishankar v.harishan...@gmail.com 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
On Dec 3, 2:12 am, Tim Harig user...@ilthio.net 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
On 2010-12-04, alex23 wuwe...@gmail.com wrote:
On Dec 3, 2:12 am, Tim Harig user...@ilthio.net 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
On 2010-12-03, Harishankar v.harishan...@gmail.com 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;
*
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
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 or
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. ;)
if var
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 what I
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 want to specifically
Harishankar v.harishan...@gmail.com 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
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
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 just a
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
--
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 error
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 flag the
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 2010-12-02, Harishankar v.harishan...@gmail.com 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
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 multiple points of
On 2010-12-02, Steve Holden st...@holdenweb.com 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
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 reason to use
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 2010-12-02, Harishankar v.harishan...@gmail.com 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
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: that's
On 2010-12-02, Harishankar v.harishan...@gmail.com 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
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
Harishankar v.harishan...@gmail.com 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
On 2010-12-02, Harishankar v.harishan...@gmail.com 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
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 02/12/2010 16:12, Tim Harig wrote:
On 2010-12-02, Harishankarv.harishan...@gmail.com 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.
MRAB pyt...@mrabarnett.plus.com 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
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
On 2010-12-02, Paul Rubin no.em...@nospam.invalid wrote:
MRAB pyt...@mrabarnett.plus.com 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
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
Tim Harig user...@ilthio.net 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
On 2010-12-02, Paul Rubin no.em...@nospam.invalid wrote:
MRAB pyt...@mrabarnett.plus.com 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
On 02/12/2010 18:09, Paul Rubin wrote:
MRABpyt...@mrabarnett.plus.com 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
On 2010-12-02, Paul Rubin no.em...@nospam.invalid wrote:
Tim Harig user...@ilthio.net 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
Tim Harig user...@ilthio.net 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
On 2010-12-02, Paul Rubin no.em...@nospam.invalid wrote:
Tim Harig user...@ilthio.net 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
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
On 02/12/2010 19:15, Tim Harig wrote:
On 2010-12-02, Paul Rubinno.em...@nospam.invalid wrote:
Tim Hariguser...@ilthio.net 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
Tim Harig user...@ilthio.net 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
On 2010-12-02, MRAB pyt...@mrabarnett.plus.com wrote:
On 02/12/2010 19:15, Tim Harig wrote:
On 2010-12-02, Paul Rubinno.em...@nospam.invalid wrote:
Tim Hariguser...@ilthio.net writes:
longjmp. Alternatively you can have an auxiliary stack of cleanup
records that the longjmp handler walks
On 2010-12-02, Paul Rubin no.em...@nospam.invalid wrote:
Tim Harig user...@ilthio.net 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
Harishankar v.harishan...@gmail.com 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
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
In article mailman.143.1291301807.2649.python-l...@python.org,
Harishankar v.harishan...@gmail.com 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
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
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 2010-12-03, Harishankar v.harishan...@gmail.com 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
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
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
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 or None was returned. Why is comparison with False so bad?
#
91 matches
Mail list logo
