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

[Jeff Shannon]

Max Noel wrote:

>
> On Oct 19, 2004, at 22:02, Jeff Shannon wrote:
>
>> The reason that some of these things are done as functions and some 
>> as methods of list objects, is that some of the operations make sense 
>> on a much wider range of things than just lists.  If you want to be 
>> able to conveniently sum a sequence, you can pass that sequence to 
>> sum() and everything just works.  If sum() were a method instead of a 
>> function, then *every* type of sequence would have to define a sum() 
>> method that would be essentially identical.  Even worse, if a 
>> programmer defines his own sequence type, then he'd have to write a 
>> sum() method on that custom type before it could be summed.
>
>
>     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?

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.  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.

(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.)

>> I don't know Ruby, [...]
>
>
>     Ruby ( http://www.ruby-lang.org/ ) is another object-oriented 
> "scripting" language. 


Heh.  I should have said, I haven't really looked at Ruby yet. ;)  I 
have heard about it, and it does often get compared to Python.  At this 
point, I find it more useful to concentrate my efforts, so picking up 
more languages is a low priority for me.  (And if I *were* to try to 
pick up a new language, I'd probably go for something with a new-to-me 
paradigm, such as Lisp/Scheme or Haskell...)  Not that I have anything 
against Ruby, just a matter of most efficient use of limited resources 
(time and brainpower).

>     I'm hitting a roadblock, though, when it comes to web programming 
> with mod_python. The documentation I've found about it is quite terse, 
> and mod_python's logic seems completely alien to me (I was expecting 
> something that works exactly like CGI but faster). Are there any good 
> tutorials on the subject, by the way?


Sorry, I can't help you on that -- I've never needed to do any web 
programming, myself, so I haven't investigated that area at all.  Some 
day when I have all the free time that I'd like..... ;)

Jeff Shannon
Technician/Programmer
Credit International