[Tutor] Are you allowed to shoot camels? [kinda OT]

[Liam Clarke]

I had a problem with nested

while 1:
   ... .
   ...
   ... 
   break

blocks. So, I got some sleep, fixed it, and now do everything in my
power to not nest while 1 - break blocks.

Not that it's really relevant.

On Fri, 4 Feb 2005 17:18:49 -0500, Smith, Jeff <jsmith at medplus.com> wrote:
> Please don't take offense.  I should have included the smiley.  To
> reiterate an earlier statement:  I like Python...a lot.  But as with all
> langauges there are some things I don't like and I believe they were
> left out for the wrong reasons.
> 
> On the indentation topic.  I would be curious to know if anyone has had
> an experience where a rogue process or editor has trashed the
> indentation in your Python and how you recovered from it.
> 
> Jeff
> 
> -----Original Message-----
> From: Marilyn Davis [mailto:marilyn at deliberate.com]
> Sent: Friday, February 04, 2005 5:07 PM
> To: tutor at python.org
> Subject: RE: [Tutor] Are you allowed to shoot camels? [kinda OT]
> 
> I think Danny was saying that if you don't like:
> 
> if var == 'a':
>    print 'a'
> elif var == 'b' or var == 'c':
>    print 'b or c'
> elif var == 'd':
>    pass
> else:
>    print 'default case'
> 
> you might like his dispatch scheme.  And it has been mighty nice and
> handy for me since he taught me, in some special cases.
> 
> I'll whisper that I'm a tiny bit disappointed to see the vaguely
> demeaning 'are you joking' theme that has emerged in here.  It's unusual
> for us to be anything but generous and kind with each other. I guess
> this is a hot topic.  :^)
> 
> Marilyn
> 
> On Fri, 4 Feb 2005, Smith, Jeff wrote:
> 
> > Now who's joking?  Are you saying that
> >
> > switch var:
> >       case 'a':
> >               print 'a'
> >       case 'b' or 'c':
> >               print 'b or c'
> >       case 'd':
> >               pass
> >       default:
> >               print 'default case'
> >
> > Is less clear and maintainable than
> >
> > def do_this_function():
> >       print 'a'
> >
> > def do_that_function():
> >       print 'b or c'
> >
> > def do_pass_function():
> >       pass
> >
> > def do_default_function():
> >       print 'default case'
> >
> > ftable = { 'a' : do_this_function,
> >            'b' : do_that_function,
> >            'c' : do_that_function,
> >            'd' : do_pass_function }
> > ftable.get(var, do_default_function)()
> >
> > Ugh!
> >
> >
> > -----Original Message-----
> > From: Alan Gauld [mailto:alan.gauld at freenet.co.uk]
> > Sent: Friday, February 04, 2005 1:14 PM
> > To: Smith, Jeff; Jacob S.; Nicholas.Montpetit at deluxe.com;
> > tutor at python.org
> > Subject: Re: [Tutor] Are you allowed to shoot camels? [kinda OT]
> >
> >
> > > What you are try to do is "execute a block of code based on the
> > value of
> > > a single statement."  if/elif doesn't do that and thereby introduces
> > the
> > > possibility of errors.
> >
> > In that case the best solution is a dictionary jump table. That is
> > more maintainable than either and much faster too. And its also
> > shorter to write. [Especially with lambdas :-)]
> >
> > > Note that the logic intended is that "on-this."  So why force the
> > > programmer to rewrite it N times and thereby introduce the
> > possibility
> > > of N-1 typographical errors...
> >
> > Thats a fair point although the dictionary solution avoids that. OTOH
> > such switches tend to proliferate thropugh code and become a big
> > source of maintenance headaches in their own right - multiple update
> > syndrome across multiple files potentially.
> >
> > > Note that I've left out break.  I'm not convinced that fall-through
> > > is
> >
> > > an important feature in switch and is usually the culpit in the
> > > cases
> > > of abuse.
> >
> > The problem is its so hard to tell when fall though is happening
> > intentionally  or by accident because someone forgot a break
> > sytatement.
> >
> > But when it comes to abuuse the fall through mechanism is one of the
> > worst offenders in C, its just too tempting to be "clever" with it.
> >
> > > This is also true for the ternary operator.  The desired logic is to
> > > assign the value of a variable based on the value of some other
> > > variable.
> >
> > But its not its based on the value of an *expression*. If the test
> > could be limited to a single valiable value it might be justified but
> > its an arbitrary expression. That makes it a conditional statement,
> > which is most clearly represented by an if/else... Well I think so :-)
> >
> > > I also like Perl's unless statement but really prefer
> > > VBs DO/WHILE/UNTIL/LOOP constuct.  Nothing beats it for clarity of
> > > expression.
> >
> > I won't argue on either point, Python's minimalist
> > approach - there's only one way to do it - means a
> > paucity of looping constructs - something I point
> > out in my tutorial. But I can live with it for the
> > other niceties it brings.
> >
> > Alan G.
> >
> > _______________________________________________
> > Tutor maillist  -  Tutor at python.org
> > http://mail.python.org/mailman/listinfo/tutor
> >
> 
> --
> 
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor
> 


-- 
'There is only one basic human right, and that is to do as you damn well please.
And with it comes the only ba  sic human duty, to take the consequences.