Re: [Tutor] Another try at Python's selfishness
On 04/02/06, Alan Gauld [EMAIL PROTECTED] wrote: I have to say that as a newbie, it took me quite a while to get my head around that extra parameter (self). That's OK, its true of most folks, even non newbies! It is one area where Python is different to most languages who hide the self completely. It took me ages to work out that: class A: def __init__(self, foo): self.foo = foo a = A(hello) is actually a shortcut for: a = A(a, Hello) I think insisting on: a = A(a, Hello) would be very good for readability, understandability and newbie-friendliness. Only for the constructor. Once you have the object itself the method calls wouyld be much less readable: class C: def a(s):pass c = C() c = c.a(c) etc is not descriptive of the concept of passing a message to the object c, it looks rather like you are passing the object c to a function which is a member of itself, which brings to mind recursion not messages... Remember that the purpose of writing a class is to *hide* the details of its implementation from the user, thus the user never has to use self, only the builder. The only reason you are confused is because you are both builder and user of the class. As always Alan, you've managed to make something confusing seem sensible and logical. That is the best explanation of this subject I've ever heard. But consider file objects, do you ever feel the need to write: myfile = file(myfile,filename,mode) or does myfile = file(filename,mode) seem more friendly? Is that because you've nbever actually seen the constructor code for the file class(*) and so don't worry about the presence of self? If you did have to pass the object in, wouldn't you be asking why you had to pass the object into the file creation method? I now agree, and (I think) understand completely. Ed PS Are there any good tutorials on the more philosophical side of the object orientedness of Python? I've read pretty much all the major tutorials that are commonly linked to, and they often cover HOW to use classes and stuff, but I'm quite interested in WHY we use classes (and as I've discovered from you and Kent, WHEN to use classes). I've found some general OOP tutorials, but they always seem to use Java or C which I don't know and don't particularly care to know. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Another try at Python's selfishness
PS Are there any good tutorials on the more philosophical side of the object orientedness of Python? Good question, but I don't know of any answers. One author from the c.l.p list was writing a book about the innards of Python that promised to answer many of those questions but sadly that project has stalled... found some general OOP tutorials, but they always seem to use Java or C which I don't know and don't particularly care to know. The best (theoretical) book on OO I know of is Meyer's OO Software Construction (2nd ed - NOT the first!) Its huge (c 1000 pages) but it does a great job of explaining why OO things are the way they are. BUT its code is in Eiffel... Grady Booch is allegedly doing a 3rd edition of his OOD book using UML and that used to have a good (and shorter!) rationale section in it. You could probably borrow either the 1st or 2nd edition from a library? Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Another try at Python's selfishness
On 3 Feb 2006 03:59:10 -0800, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I still see newbie-friendliness as a MAJOR plus for Python -- it increases the chance that users of your software will become contributors. Yes, I 100% agree to that point! But the point is, the current situation is not newbie-friendly (I can tell, I am a newbie): I declare a method with 3 parameters but when I call it I only pass 2 parameters. That's confusing. If I declare a member variable, I write: self.x = ValueForX, why can't I be equally explicit for declaring member functions? I have to say that as a newbie, it took me quite a while to get my head around that extra parameter (self). It took me ages to work out that: class A: def __init__(self, foo): self.foo = foo a = A(hello) is actually a shortcut for: a = A(a, Hello) or even: a = new A(a, Hello) I think insisting on: a = A(a, Hello) would be very good for readability, understandability and newbie-friendliness. Ed ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Another try at Python's selfishness
I have to say that as a newbie, it took me quite a while to get my head around that extra parameter (self). That's OK, its true of most folks, even non newbies! It is one area where Python is different to most languages who hide the self completely. It took me ages to work out that: class A: def __init__(self, foo): self.foo = foo a = A(hello) is actually a shortcut for: a = A(a, Hello) I think insisting on: a = A(a, Hello) would be very good for readability, understandability and newbie-friendliness. Only for the constructor. Once you have the object itself the method calls wouyld be much less readable: class C: def a(s):pass c = C() c = c.a(c) etc is not descriptive of the concept of passing a message to the object c, it looks rather like you are passing the object c to a function which is a member of itself, which brings to mind recursion not messages... Remember that the purpose of writing a class is to *hide* the details of its implementation from the user, thus the user never has to use self, only the builder. The only reason you are confused is because you are both builder and user of the class. But consider file objects, do you ever feel the need to write: myfile = file(myfile,filename,mode) or does myfile = file(filename,mode) seem more friendly? Is that because you've nbever actually seen the constructor code for the file class(*) and so don't worry about the presence of self? If you did have to pass the object in, wouldn't you be asking why you had to pass the object into the file creation method? (*)OK I haven't checked, but I strongly suspect the built in file objects aren't written in Python so won't look the same but the illustration is valid. I dunno if that helps explain the rational but maybe... Alan G Author of the learn to program web tutor http://www.freenetpages.co.uk/hp/alan.gauld ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
