[Tutor] ftp program

[Rich Krauter]

Alan Gauld wrote:
 >>Rich wrote:
>>2. In other code, when I use __getattr__ to handle multiple name
>>lookups, I end up with code like this in __getattr__:
>>[snip]
>>Is this the canonical way to handle this?


> getattr is useful when you get passed an attribute string
> rather than a name and have to do some munging *of the name*
> but it is better to delegate the processing to a method,
> rather than do it inside getattr.

> 
> The reason for this is that when you come to extend the class
> via inheritance the sub class needs to override the getattr
> method which is much more complicated. If there is a method
> that does the attribute specifoic processing the subclass
> only needs to override the attribute specific method which
> is much less likely to break existing code and much simpler
> to implement. After all avoiding a lot of if/elif chains
> is one of the biggest benefits of OOP, why introduce such
> chains inside our classes?
> 


Right; that makes perfect sense; thanks.


> 
>>I generally don't use properties unless the calculation must
>>be updated on each attribute access, which I don't really
>>seem to need too often.
> 
> 
> Whats the difference between doing that in a property as opposed
> to getattr? getattr still gets called each access and your code
> must cope, why is a property any different? I think I might be
> missing something here...
> 

Isn't __getattr__ only called if name lookup fails by the ordinary 
lookup protocol, whereas properties are called everytime the attribute 
is accessed, regardless of whether the attribute's already been set?


> OTOH I rarely use properties either since accessing the internal
> attributes of a class should rarely be necessary, and apart from
> simple validation of input properties have little to offer IMHO.
> Mostly an explicit method that reflects the object behaviour is a
> better solution.
>>->Sometimes I use a method, and just use the return value of the 
> method

> This should be the norm since methods should define the interface
> to the object.

Yeah, I probably tend to overuse the ways to make things look like 
attributes.

>>->call that method in __getattr__ if I want to access the method's
>>return value as an attribute, but don't necessarily need the
>>attribute on every instance,
>>->call the method in __init__, if I know I will definitely need the
>>attribute for most instances.

> Not sure what you mean here,  __init__ is normally about setting
> attributes not getting them?


I wasn't clear about that - I meant doing something like

def __init__(self):
     self.x = self.some_method_to_set_x()

This seems to work, but it does seem odd to access methods attached to 
the instance before the instance is fully 'instantiated'.


>>I'm wondering what conventions or rules of thumb others use?
> My rule of thumb is to avoid all kinds of object trickery as much as
> possible, even if it means writing a little more code. It's usually
> easier to understand and, most importantly, to extend via inheritance.


Sometimes it just makes more sense to me to have things available as 
attributes; I agree with you that the code in my previous email is not a 
good example of when wrapping everything up as attributes makes sense 
though. I'll change it.

Thanks for the input.

Rich