Re: Comparison

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

Re: Comparison

On Tue, Sep 23, 2014 at 3:38 AM, LJ 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 > feasibility condit

Re: Comparison

On Monday, September 22, 2014 1:12:23 PM UTC-4, Chris Angelico wrote: > On Tue, Sep 23, 2014 at 2:57 AM, LJ 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 o

Re: Comparison

On Tue, Sep 23, 2014 at 2:57 AM, LJ 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 structured arrays. > The con

Re: Comparison Style

On 4/27/2013 5:03 PM, Roy Smith wrote: In article , Chris Angelico 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 constant first. I've just do

Re: Comparison Style

In article , Chris Angelico 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 constant first. I've just done a whole bunch of ugly math to find

Re: Comparison Style

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, bravado

Re: Comparison Style

On 04/25/2013 10:48 PM, Chris Angelico wrote: 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 (*st

Re: Comparison Style

On Fri, Apr 26, 2013 at 12:37 PM, Dennis Lee Bieber wrote: > On Thu, 25 Apr 2013 15:57:49 +1000, Chris Angelico > declaimed the following in gmane.comp.python.general: >> It's conventional to compare variables to constants, not constants to >> variables (even in C where there's the possibility of

Re: Comparison Style

llanitedave wrote: >On Thursday, April 25, 2013 11:31:04 AM UTC-7, Steve Simmons wrote: >> Chris Angelico 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 ,

Re: Comparison Style

On 2013-04-25, llanitedave 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 one. -- Ne

Re: Comparison Style

On Thursday, April 25, 2013 11:31:04 AM UTC-7, Steve Simmons wrote: > Chris Angelico 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

Re: Comparison Style

Chris Angelico 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 Galaxy far far away

Re: Comparison Style

On Fri, Apr 26, 2013 at 12:19 AM, llanitedave 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. Good point. Wit

Re: Comparison Style

On Wednesday, April 24, 2013 10:57:49 PM UTC-7, Chris Angelico wrote: > On Thu, Apr 25, 2013 at 3:49 PM, llanitedave wrote: > > > Given that > > > > > > s = some static value > > > i = a value incremented during a loop > > > > > > I'm used to comparing them as > > > > > > if i == s: > > >

Re: Comparison Style

On Thu, Apr 25, 2013 at 3:49 PM, llanitedave 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 seem t

Re: comparison between non-comparable objects

> 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 > >in section "6.9 Comparisons" Sorry ab

Re: comparison between non-comparable objects

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

Re: Comparison operators in Python

On Jun 2, 1:44 am, harrismh777 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 result, if someone is

Re: Comparison operators in Python

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

Re: Comparison operators in Python

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 (ex

Re: Comparison operators in Python

On Wed, Jun 1, 2011 at 12:50 PM, Anirudh Sivaraman 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 permitted. Is there

Re: Comparison operators in Python

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

Re: Comparison with False - something I don't understand

"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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Resumable exceptions bad: (was Re: Comparison with False - something I don't understand)

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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,

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

> 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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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,

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

> 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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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.

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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: > >

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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 >

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

Re: Comparison with False - something I don't understand

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

  1   2   3   >