LJ wrote:
I have a network in which the nodes are defined as dictionaries using the
NetworkX package. Inside each node (each dictionary) I defined a
dictionary of dictionaries holding attributes corresponding to different
ways in which the node can be reached (this dictionaries I refer to as
On Tue, Sep 23, 2014 at 2:57 AM, LJ luisjoseno...@gmail.com wrote:
Quick question here. In the code I am working on I am apparently doing a lot
of dictionary lookups and those are taking a lot of time.
I looked at the possibility of changing the structure and I found about the
numpy
On Monday, September 22, 2014 1:12:23 PM UTC-4, Chris Angelico wrote:
On Tue, Sep 23, 2014 at 2:57 AM, LJ luisjoseno...@gmail.com wrote:
Quick question here. In the code I am working on I am apparently doing a
lot of dictionary lookups and those are taking a lot of time.
I looked at
On Tue, Sep 23, 2014 at 3:38 AM, LJ luisjoseno...@gmail.com wrote:
At some point in my algorithm I am looping through some subset of nodes and
through the labels in each node and I perform some joining checks with the
labels of each node in another subset of nodes. To clarify I check for a
In article mailman.1077.1366944517.3114.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
If you switch the order of operands in that, the compiler won't help
you. Plus it reads wrong. So the convention is still
variable==constant.
I just found a nice example of putting the
On 4/27/2013 5:03 PM, Roy Smith wrote:
In article mailman.1077.1366944517.3114.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
If you switch the order of operands in that, the compiler won't help
you. Plus it reads wrong. So the convention is still
variable==constant.
I just
On 25/04/2013 21:35, Steve Simmons wrote:
The Ying Tong song - a classic of its time. But eminently suited to the
chorally challenged.
Released on a classic EP with Major Dennis Bloodnok's Rock and Roll Call
Rumba, I'm walking Backwards for Christmas and Bluebottle Blues.
Bravado,
On Thu, Apr 25, 2013 at 3:49 PM, llanitedave llanited...@veawb.coop wrote:
Given that
s = some static value
i = a value incremented during a loop
I'm used to comparing them as
if i == s:
# some code
But for some unknown reason I did a switch
if s == i:
# same code
It didn't
On Wednesday, April 24, 2013 10:57:49 PM UTC-7, Chris Angelico wrote:
On Thu, Apr 25, 2013 at 3:49 PM, llanitedave llanited...@veawb.coop wrote:
Given that
s = some static value
i = a value incremented during a loop
I'm used to comparing them as
if i == s:
On Fri, Apr 26, 2013 at 12:19 AM, llanitedave llanited...@veawb.coop wrote:
On Wednesday, April 24, 2013 10:57:49 PM UTC-7, Chris Angelico wrote:
I thought programming WAS a hobby?
I meant a safer, easier, and more mainstream hobby, like base jumping or
motorcycle aerobatics or something.
Chris Angelico ros...@gmail.com wrote:
With the sort of thinking you're demonstrating here, you
should consider a job working with Spike Milligna (the well known typing error).
Errr , I think you'll find that he's joined the choir invisibule. Mind you,
he did say he was ill!
Sent from a
On Thursday, April 25, 2013 11:31:04 AM UTC-7, Steve Simmons wrote:
Chris Angelico ros...@gmail.com wrote:
With the sort of thinking you're demonstrating here, you
should consider a job working with Spike Milligna (the well known typing
error).
Errr , I think you'll find that
On 2013-04-25, llanitedave llanited...@veawb.coop wrote:
Errr , I think you'll find that he's joined the choir
invisibule. Mind you, he did say he was ill!
Sent from a Galaxy far far away
Did you ever hear him sing? He's better off in the choir
inaudible.
Well I've never heard either
llanitedave llanited...@veawb.coop wrote:
On Thursday, April 25, 2013 11:31:04 AM UTC-7, Steve Simmons wrote:
Chris Angelico ros...@gmail.com wrote:
With the sort of thinking you're demonstrating here, you
should consider a job working with Spike Milligna (the well known
typing error).
On Fri, Apr 26, 2013 at 12:37 PM, Dennis Lee Bieber
wlfr...@ix.netcom.com wrote:
On Thu, 25 Apr 2013 15:57:49 +1000, Chris Angelico ros...@gmail.com
declaimed the following in gmane.comp.python.general:
It's conventional to compare variables to constants, not constants to
variables (even in C
On 04/25/2013 10:48 PM, Chris Angelico wrote:
SNIP
Also, this protection helps only when the constant
is actually something the compiler knows is a constant - it doesn't
work in a search function, for instance:
char *strchr(char *string, char findme) {
while (*string) {
if
On 01/08/2013 12:28 AM, Kelvin Li wrote:
The language reference says:
...the choice whether one object [of built-in type] is considered
smaller or larger than another one is made arbitrarily...
When quoting some online source, please give a reference link. It took
me a while to find the
When quoting some online source, please give a reference link. It took
me a while to find the following page with your quote in it:
http://docs.python.org/3.3/reference/expressions.html
http://docs.python.org/3.3/reference/expressions.htm
in section 6.9 Comparisons
Sorry about that.
On 6/1/2011 8:44 PM, harrismh777 wrote:
Ian Kelly wrote:
?? wrote
integer. However comparison between a string and an integer seems to
be permitted. Is there any rationale behind this ?
It allows things like sorting of heterogeneous lists. It's generally
viewed as a wart, though, and it
On Jun 2, 1:44 am, harrismh777 harrismh...@charter.net wrote:
..
Just another example (excluding print 1/2 and unicode) where 3.x
seems to be completely compatible with 2.x/ (tongue-in-cheek)
One of the key purposes of the 3.x line of code is to get rid of warts
in the language. As a
Anirudh Sivaraman writes:
I am a relative new comer to Python. I see that typing is strongly
enforced in the sense you can't concatenate or add a string and an
integer. However comparison between a string and an integer seems to
be permitted. Is there any rationale behind this ?
In Python 3
On Wed, Jun 1, 2011 at 12:50 PM, Anirudh Sivaraman sk.anir...@gmail.com wrote:
Hi
I am a relative new comer to Python. I see that typing is strongly
enforced in the sense you can't concatenate or add a string and an
integer. However comparison between a string and an integer seems to
be
Ian Kelly wrote:
integer. However comparison between a string and an integer seems to
be permitted. Is there any rationale behind this ?
It allows things like sorting of heterogeneous lists. It's generally
viewed as a wart, though, and it was fixed in Python 3:
Just another example
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
1 - 100 of 216 matches
Mail list logo
