[Tutor] methods versus functions (using lists as an example)
jeff at ccvcorp.com
Wed Oct 20 01:47:43 CEST 2004
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..... ;)
More information about the Tutor