[Tutor] methods versus functions (using lists as an example)

[Jeff Shannon]

Max Noel wrote:

>
>     It doesn't really make that much sense to me. Though I understand 
> the logic behind sum() (and to a certain extent, behind len(), 
> although that one is less convincing to me), I don't see where the 
> advantage of calling repr(foo) is over something in the lines of 
> foo.toString().


I'll grant that the reasoning is less compelling for repr() than for 
things like sum() and len().  But at the same time, I can't really see 
an advantage in calling foo.toString() over repr(foo) -- they're 
relatively equivalent in my mind, except that each shows a different 
programming paradigm.  Python is designed to be paradigm-flexible, which 
may be why the OO-specific spelling was not chosen. 

>>   And besides, since repr() is a function, that means that if a class 
>> *doesn't* define a method to help it, it can have a fallback 
>> response.  If it were a method, then attempting to call it on a class 
>> that didn't define anything for that purpose would throw an 
>> AttributeError.
>
>
>     Not really. Unless I'm missing something, all classes in Python 
> are subclasses of a root class (like Object in Java). If repr() was a 
> method, chances are it'd be implemented in the root class as a 
> fallback. Object.repr() would display what you see when you call 
> repr() now on an object which doesn't define a method to help it, and 
> all you'd have to do to get your object to display itself would be to 
> override this method.


Well, new-style classes are all derived from object, though I think that 
was as much an implementation detail (to separate them from old-style 
classes) as a philosophical decision.  Before Python 2.2, there was a 
strong distinction between types (built-in, C-coded data such as ints, 
strings, lists, dicts, etc), and classes.  In 2.2, this difference was 
eliminated, but the need to maintain backwards compatibility meant that 
old-style classes were still the default, and thus it was necessary to 
have a way to specify which classes were intended to be new-style.  This 
was done by deriving new-style classes from a newly-created abstract 
base type, object.  I think (though I could be wrong) that the intent 
was only to enable this class/type unification, and not to 
philosophically root all objects into a single class heirarchy (as Java 
does).

I think that the point here is that, while Python was indeed designed to 
be object-oriented from the ground up, it was not designed to be 
*exclusively* object-oriented.  Java and Smalltalk, etc, were designed 
to be exclusively object-oriented, but Python wanted to allow other 
paradigms like functional programming as well.  Thus, while objects are 
a major part of the language and their use is encouraged, there isn't an 
attempt to present *everything* in an OO style.

Jeff Shannon
Technician/Programmer
Credit International