On Sun, Jul 27, 2008 at 09:39:26PM +0200, Bruno Desthuilliers wrote: > >As for the latter part of #3, self (or some other variable) is > >required in the parameter list of object methods, > > It's actually the parameter list of the *function* that is used as the > implementation of a method. Not quite the same thing.
The idea that Python behaves this way is new to me. For example, the tutorials make no mention of it: http://docs.python.org/tut/node11.html#SECTION0011300000000000000000 The Python reference manual has very little to say about classes, indeed. If it's discussed there, it's buried somewhere I could not easily find it. > consistency mandates that the target object of the method is part of > the parameter list of the *function*, since that's how you make > objects availables to a function. Fair enough, but I submit that this distinction is abstruse, and poorly documented, and also generally not something the average application developer should want to or have to care about... it's of interest primarily to computer scientists and language enthusiasts. The language should prefer to hide such details from the people using it. > >however when the method is *called*, it is omitted. > > Certainly not. Seems not so certain to me... We disagree, even after your careful explanation. See below. > You need to lookup the corresponding attribute *on a given object* > to get the method. Whether you write > > some_object.some_method() > > or > > some_function(some_object) > > you still need to explicitely mention some_object. But these two constructs are conceptually DIFFERENT, whether or not their implementation is the same or similar. The first says that some_method is defined within the name space of some_object. The second says that some_object is a parameter of some_function... Namespace != parameter!!!!!!!!! To many people previously familiar with OO programming in other languages (not just Java or C++), but not intimately familiar with Python's implementation details, the first also implies that some_method is inherently part of some_object, in which case explicitly providing a parameter to pass in the object naturally seems kind of crazy. The method can and should have implicit knowledge of what object it has been made a part. Part of the point of using objects is that they do have special knowledge of themselves... they (generally) manipulate data that's part of the object. Conceptually, the idea that an object's methods can be defined outside of the scope of the object, and need to be told what object they are part of/operating on is somewhat nonsensical... > >Thus when an object method is called, it must be called with one fewer > >arguments than those which are defined. This can be confusing, > >especially to new programmers. > > This is confusing as long as you insist on saying that what you > "def"ined is a method - which is not the case. I can see now the distinction, but please pardon my prior ignorance, since the documentation says it IS the case, as I pointed out earlier. Furthermore, as you described, defining the function within the scope of a class binds a name to the function and then makes it a method of the class. Once that happens, *the function has become a method*. To be perfectly honest, the idea that an object method can be defined outside the scope of an object (i.e. where the code has no reason to have any knowledge of the object) seems kind of gross to me... another Python wart. One which could occasionally be useful I suppose, but a wart nonetheless. This seems inherently not object-oriented at all, for reasons I've already stated. It also strikes me as a feature designed to encourage bad programming practices. Even discounting that, if Python had a keyword which referenced the object of which a given peice of code was a part, e.g. self, then a function written to be an object method could use this keyword *even if it is defined outside of the scope of a class*. The self keyword, once the function was bound to an object, would automatically refer to the correct object. If the function were called outside of the context of an object, then referencing self would result in an exception. You'll probably argue that this takes away your ability to define a function and subsequently use it both as a stand-alone function and also as a method. I'm OK with that -- while it might occasionally be useful, I think if you feel the need to do this, it probably means your program design is wrong/bad. More than likely what you really needed was to define a class that had the function as a method, and another class (or several) that inherits from the first. > The point is that you don't get access to the object "within itself". > You get access to an object *within a function*. Thus methods are not really methods at all, which would seem to suggest that Python's OO model is inherently broken (albeit by design, and perhaps occasionally to good effect). > The fact that a function is defined within a class statement doesn't > imply any "magic", It does indeed -- it does more than imply. It states outright that the function is defined within the namespace of that object, and as such that it is inherently part of that object. So why should it need to be explicitly told about the object of which it is already a part? It further does indeed imply, to hordes of programmers experienced with OO programming in other languages, that as a member, property, attribute, or what ever you care to call it, of the object, it should have special knowledge about the object of which it is a part. It just so happens that in Python, this implication is false. > IOW : there's one arguably good reason to drop the target object from > functions used as methods implementation, which is to make Python looks > more like Java No, that's not the reason. I don't especially like Java, nor do I use it. The reason is to make the object model behave more intuitively. >, and there's at least two good reason to keep it the way it is, >which are simplicity (no special case) and consistency (no special >case). Clearly a lot of people find that it is less simple TO USE. The point of computers is to make hard things easier... if there is a task that is annoying, or tedious, or repetitive, it should be done by code, not humans. This is something that Python should do automatically for its users. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D
pgpKshGDhBdNh.pgp
Description: PGP signature
-- http://mail.python.org/mailman/listinfo/python-list
