Encapsulation, inheritance and polymorphism

rusi rustompmody at gmail.com
Wed Jul 18 05:54:06 CEST 2012


On Jul 18, 5:46 am, Andrew Cooper <am... at cam.ac.uk> wrote:
> On 17/07/2012 19:36, Lipska the Kat wrote:
>
>
>
>
>
>
>
>
>
> > On 17/07/12 19:18, Mark Lawrence wrote:
> >> On 17/07/2012 18:29, Ethan Furman wrote:
> >>> Terry Reedy wrote:
> >>>> On 7/17/2012 10:23 AM, Lipska the Kat wrote:
>
> >>>>> Well 'type-bondage' is a strange way of thinking about compile time
> >>>>> type
> >>>>> checking and making code easier to read (and therefor debug
>
> >>>> 'type-bondage' is the requirement to restrict function inputs and
> >>>> output to one declared type, where the type declaration mechanisms are
> >>>> usually quite limited.
>
> >>>> >>> def max(a, b):
> >>>> if a <= b: return a
> >>>> return b
>
> >>> Surely you meant 'if a >= b: . . .'
>
> >>> No worries, I'm sure your unittests would have caught it. ;)
>
> >>> ~Ethan~
>
> >> Wouldn't the compiler have caught it before the unittests? :-)
>
> > Not unless the compiler could read your mind!
> > The syntax looks fine it's the semantics that are suspect. Wrong is a
> > word that I try not to use as it tends to upset people, let's call them
> > "differently right" ;-)
>
> > BTW having more than one return statement in a block is a little thing I
> > know but it drives me nuts ... another "Pythonic" thing I'll have to get
> > used to I suppose.
>
> Its not a pythonic thing.  Its a common and very acceptable paradigm.
>
> Mainly, it avoids complicated breaks from nested control structures, and
> especially the 'style' of maintaining one boolean value called
> "should_continue" or something equally silly.
>
> My daily work involves C, x86 assembly, reading x86/PCI/ACPI/etc
> specifications and cursing violently at some of the stupidity, Python,
> Bash and C++, and this is one of the few styles which remains fairly
> constant throughout.
>
> Take for example a Linux system call handler.  The general form looks a
> little like (substituting C for python style pseudocode)
>
> if not (you are permitted to do this):
>     return -EPERM
> if not (you've given me some valid data):
>     return -EFAULT
> if not (you've given me some sensible data):
>     return -EINVAL
> return actually_try_to_do_something_with(data)
>
> How would you program this sort of logic with a single return statement?
>  This is very common logic for all routines for which there is even the
> remotest possibility that some data has come from an untrusted source.

return (-EPERM if not_permitted else -EFAULT if non_valid else -EINVAL
if non_sensible else do_something)

Not that I recommend *doing* this :-)
[I recommend knowing about it]



More information about the Python-list mailing list