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

[Max Noel]

On Oct 20, 2004, at 00:47, Jeff Shannon wrote:

>>     You have a point there. However, I don't really see why str() and 
>> repr() are functions and not methods, given that you have to 
>> implement methods for them to work anyway.
>
>
> Well, if you're defining your own class, you need to implement methods 
> to be able to add and subtract, as well, but you wouldn't think that 
> those should be methods, would you?

	They could be. And actually, in Ruby, they are. (when you type 2+2, 
what's actually executed is 2.+(2) )
	But that's not my point. What I mean is, if I recall correctly, when 
you use repr(foo), what actually happens is a method call 
(foo.__str__() IIRC).
	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().

> It's a philosophical point, as much as anything -- using repr() is 
> telling Python "give me a string that represents this object"; the 
> fact that the function may need to ask the object how it wants to be 
> represented is an implementation detail.  The intent is that repr() 
> functions on pretty much any argument, so tying it directly to any 
> particular (set of) type/class definitions doesn't convey the intended 
> meaning.

	Since a "helper" function has to be implemented for each class on 
which you intend to use it, repr() *is* inherently tied to a particular 
set of type/class definitions.
	It's probably a philosophical choice, as you say. I can live with it, 
but I don't like it. However, it starts to become more problematic with 
functions such as int(), because IIRC you can't define custom "helper" 
methods for this one (__int__(), perhaps?).

>   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.
	I think that's how it's done in Java (the toString() method).

> (And technically, str() is not a function -- it's a type.  Using it is 
> asking Python to generate a new string object, using the argument to 
> determine the contents of that string.  Definitely a nitpick, 
> especially as one *could* argue that a type object is not much more 
> than a factory function... but often understanding the nits can really 
> help to make sense out of the whole structure.)

	Mmh. I hadn't realized this. It also destroys the point I make a few 
paragraphs above in this post, but I'll leave it anyways because it 
might spark some interesting answers.

	This, in any case, is an interesting discussion. I like that place. ^^

-- Wild_Cat
maxnoel_fr at yahoo dot fr -- ICQ #85274019
"Look at you hacker... A pathetic creature of meat and bone, panting 
and sweating as you run through my corridors... How can you challenge a 
perfect, immortal machine?"