Object-oriented philosophy

[MRAB]

On 2018-09-06 21:24, Michael F. Stemper wrote:
> On 2018-09-06 09:35, Rhodri James wrote:
>> On 06/09/18 15:04, Michael F. Stemper wrote:
>>> Net net is that the only thing that ended up being common was the
>>> __init__ methods. Two of the classes have identical __init__
>>> methods; the third has a superset of that method. The other methods
>>> all have completely different implementations. This isn't due to
>>> poor coding, but due to the fact that what these model have
>>> different physical characteristics.
>>>
>>> Not being that familiar with object-oriented programming (I grew up
>>> on FORTRAN and c), I'm seeking opinions:
>>>
>>> Is there really any benefit to this change? Yes, I've eliminated
>>> some (a few lines per class) duplicate code. On the other hand,
>>> I've added the parent class and the (probably small, but not
>>> non-existent) overhead of invoking super().
>> 
>> What you've done is the work you would have to do in a statically-typed
>> language such as C++.  You've been taking advantage of duck typing
> 
> Upon review, it seems that I haven't. However, as noted in another
> followup, I think that I've found a way to do so.
> 
>> Is it worth creating the superclass in Python?  It sounds like it's a
>> bit marginal in your case.  I'm not that seasoned in object-oriented
>> design either, but my yardstick would be how much common code does it
>> eliminate?
> 
> About half a dozen lines. Here's the common part:
> 
> def __init__( self, xmlmodel, V, id ):
> 
>    try:
>      P_0s = xmlmodel.findall( 'RatedPower' )[0].text
>      self.P_0 = float( P_0s )
>    except:
>      Utility.DataErr( "Power not specified for %s load" % (id) )
>    if self.P_0<=0.0:
>      Utility.DataErr( "Power for %s load must be postive, not %s" \
>        % (id,P_0s) )
> 
> Actually, looking over it, I see that I can slightly simplify this.
> I suppose that's a good reason for putting it in one place -- if I
> want to change it, I only need to do it once, not three times.
> 
> Thanks for your input.
> 
A word of advice: don't use a "bare" except, i.e. one that doesn't 
specify what exception(s) it should catch.

Your try...except above will catch _any_ exception. If you misspelled a 
name in the 'try' part, it would raise NameError, which would also be 
caught.

There are rare occasions when it's OK, but even then you'd just want to 
do something and then re-raise it.

Catch only those exceptions that you're prepared to deal with and allow 
any others to propagate and let you know that there's a problem!