Comparison with False - something I don't understand

Tim Harig usernet at ilthio.net
Sun Dec 5 06:53:24 EST 2010


On 2010-12-05, Tim Harig <usernet at ilthio.net> wrote:
> 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.

Okay, it occures to me that you don't really need to see much to know what was
going on, here is the basic idea of how the role function of the object would
have looked like:

def role(self, dice):

	try:
		self.role(dice.previous())
	except diceReset:
		dice.increment()
	except endOfDice:
		raise diceReset



More information about the Python-list mailing list