[Python-ideas] Function/method call issues

[Josiah Carlson]

Please don't top post, it unnecessarily removes context for replies that
help in understanding (most people read top to bottom, not bottom to top).

Raj B <rajb at rice.edu> wrote:
> Well, this definitely makes no difference to me to implement in OCaml  
> or any other language. I'm implementing exactly how Python behaves,  
> so whether it's easy or difficult is not really the question.
> 
> Consider the list object (listobject.c). In CPython, the 'repr'  
> method for integers is implemented by the 'list_repr' function  and  

(repr(5) is implemented as int_repr() in intobject.c)

> the 'insert operation is implemented by 'listinsert', which in turn  
> is part of the 'list_as_sequence' set of methods. So it both 'repr'  
> and 'insert' are implemented as 'methods'. However, the Python  
> convention is that 'repr' is called as repr(l) whereas insert would  
> be l.insert(i,v), with l passed implicitly.

You are not going to change the oft-discussed, long-time established
__magic__ method and magic() builtins.  That is to say, certain builtin
functions (and some operations) result in a method invocation of
obj.__magic__() (sometimes with additional arguments).  This is not
going to change.  Please see the various Python 3.0 PEPs.  Among those
are len(), repr(), etc., as well as functions listed in operator module.

Why?  Generally, finding the length of an object has been defined to be
discovered by len(obj).  While it is internally translated into
obj.__len__(), this is to allow for user methods to take on names that
could otherwise clash with standard methods.


> In both cases, they are performing almost the same amount of work in  
> looking up a function in a PyObject structure (with two lookups for  
> 'repr' and three for 'insert'). Obviously there is a design/ 
> implementation/philosophical decision that one is a generic function  
> and the other is a method call. However, the implementation has to do  
> 2 different things based on the name of the function to be called,  
> even though they are both part of the same object structure. I was  
> wondering why it was necessary to do it that way.

Convenience, flexibility, established semantics, etc.  To change it
would be a major language overhaul for little (if any, if not negative)
Python user gains.


 - Josiah

> On May 14, 2007, at 1:53 PM, Josiah Carlson wrote:
> 
> >
> > Raj B <rajb at rice.edu> wrote:
> >> 1) It would make it easier for users and make for more readable code.
> >> I still find myself having to refer to the docs to find out how a
> >> method needs to be called.
> >> 2) It would improve performance by reducing these checks shown above
> >> to one case.
> >
> > foo(x) means one thing.  x.foo() means another.  Trying to merge them
> > for the sake of "consistency" will only confuse everyone who has been
> > using method calling (x.foo()) to call methods on an object (making
> > every function call into a generic function that users don't know  
> > if it
> > is really just a generic function, or a method caller), or will  
> > give all
> > objects in which you want to call the function foo() on have a method
> > x.foo() (making every method call indistinguishable as to whether you
> > are calling the function foo with argument x, or method foo on  
> > object x).
> >
> > While it may make it easier for you to implement in OCaml, it makes no
> > sense in terms of Python sementics that are understood by basically
> > everyone for at least 10 years.
> >
> >
> >  - Josiah
> 
> --
> When you are not cute, you've got to be clever
> 						-- David Sedaris
>