Comparison with False - something I don't understand

[Tim Harig]

On 2010-12-05, Paul Rubin <no.email at nospam.invalid> wrote:
> Tim Harig <usernet at 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 sides.
>
>     from itertools import product
>     def n_sided_die(n): return xrange(1, n+1)
>
>     # make one 3-sided die, one 4-sided die, and one 5-sided die
>     dice = (n_sided_die(3), n_sided_die(4), n_sided_die(5))
>     for roll in product(*dice):
>         print roll

Notice that you had to change the structure of your program to accomodate
the new possiblity; and, if I throw further requirements at you, you
will have to change them again.  I didn't want that.  What the dice
returned may or may not have returned an easy to compute sequence.
In fact, for all of the rest of the logic cared, the dice could have
computed their value from a previous role of another dice.  All of the
logic of about what the dice may have returned when asked for their
value and how they derived, was encapsilated in the dice themselves.
It did not need to be known anywhere else in the program logic.

The DSL effectively provided a way do define how the dice decided how
to increment themselves, how to choose the value that they returned for
their face, and how to know when they could no longer be incremented.
The DSL parser generated the dice set from the description given.
Creating new dice objects was much easier then attempting to change the
logic of how they were rolled.

>> I merely posted a simplied description of the dice-role objects
>> because I thought that it demonstrated how exceptions can provide
>> eligance of control for situations that don't involve what would
>> traditionally be defined as an error.
>
> Exceptions (though sometimes necessary) are messy and I'm having a hard
> time trying to envision that code being cleaner with them than without
> them.  If you post the actual code maybe that will help me understand.

Let me get this straight, the same person that was trying to tell me
setjmp/longjmp weren't messy thinks exceptions are messy?  I have used
both.  I much prefer the exceptions.  I not have to code here to post.

The cleanliness of using the exception and calling the dice increments
recursively, was that there was no need to figure out which dice needed
to be incremented whenever the first die needed to be reset.  When a dice
needed to be reset, it would raise an exception.  This exception would
rise through the recursion stack, and thus through the dice, resetting
each along the way until it found the one which needed to be incremented
or raised past the top call indicating that all of the combinations has
been exhausted.  There, once the reset condition for the previous dice
had been effectively handled, it would be supprested. 

Had this been done using in band data:

	1. The roll object would have needed logic to determine when
		a reset condition needed to take place, effectively
		leaking some of the logic from the dice object to the
		role object.

	2. The roll object would have needed logic to determine how to
		follow the dice which needed to be reset until it found
		which one needed incrementing.	Once again, this logic
		was better left to the dice walking the resets was
		automatically handled by the progression of the exception.

Even if it wasn't an error, the resets were effectively a exceptional
condition from the normal flow of the role object (the primary flow simply
being to increment the first die).  By using exceptions, I effectively
isolated each into its own separate independent flow; and, because they
where called separatly, neither needed to have control conditions to detect
which was needed.  They simply allowed the dice object to decide.