Nick Coghlan wrote:
[...]
>  Under the proposal being discussed, things become far less clear:
>  
>       class Foo:
>           def __init__(x):         # 1: Implicit self
>               .x = x               # 2: Brief form of: self.x = x
>           def bar(a, b):           # 3: Two arguments...
>               print .x + a + b
>  
>       f = Foo(10).bar              # We agree this accepts 2 arguments
>       f = Foo.bar                  # How many arguments does f accept?
>       f = Foo.__dict__["bar"]      # How many arguments does it accept now?

I think this might return things very similar to what are returned now. 
  The only reasonable alternative I can think of is that Foo.bar would 
return something that simply could not be called until it was bound, so 
this:

   inst = Foo()
   f = Foo.bar
   print f(inst, 1, 2)

would have to be translated to this this:

   inst = Foo()
   f = Foo.bar
   meth = bind(f, inst)
   print meth(1, 2)

It seems clear given the rest of the proposal that this second form will 
work, it's just a question of whether the first form will work at all. 
Personally I find the first form is rather uncommon anyway, and 50% of 
the time I write it it's a bug.  So the more explicit second form would 
be fine with me.  Well... it becomes more complex for decorators, I guess:

   def printargs(func):
       def replacement(*args, **kw):
           print args, kw
           return func(*args, **kw)
       return replacement
   class Foo:
       @printargs
       def null(a): pass

What is printargs going to print?  Will it even work?  I'd guess you'd 
have to do:

   def printargs(func):
       def replacement(*args, **kw):
           print args, kw
           return bind(func, self)(*args, **kw)
       return replacement

But what does that do if you apply printargs to a function that isn't a 
method?  I generally have found it awkard to apply decorators to both 
methods and functions, except when the decorators pass through all the 
arguments unchanged (as printargs does).  But I don't know if this is an 
improvement; I guess it depends on what bind(func, self) does outside of 
a method invocation.  I think self should be undefined in that case. 
Well, I guess you could do:

   def printargs(func):
       def replacement(*args, **kw):
           print args, kw
           try:
               bound = bind(func, self, class)
           except NameError:
               try:
                   bound = bind(func, None, class)
               except NameError:
                   bound = func
           return bound(*args, **kw)
       return replacement

Ugh.

>  The answer to the first question *has* to be 3, or we lose too much 
>  functionality - but that's seriously surprising (the method appears to require 
>  two arguments when its defined, but actually requires 3 due to its being 
>  retrieved from a class). And it still requires that a distinction be made 
>  between instance, class and static methods in order to control the signature 
>  of the retrieved method.
>  
>  However, that answer creates its own problems - what if we have a 3-argument 
>  function that does exactly what we want our method to do? We'd need some way 
>  of signalling to the class that the function should be left alone when being 
>  retrieved from the class, but have the first argument bound automatically when 
>  being retrieved from an instance.
>  
>  This is where the "Explicit is better than implicit" and "Practicality beats 
>  purity" *both* kick in in favour of explicit self and class_ parameters - the 
>  signature of the retrieved function is exactly what the source code says it 
>  is, because there aren't any implicit parameters getting slipped into the 
>  parameter list when you aren't looking.
>  
>  As I see it, the real issue is that people are often coming from a Java or C++ 
>  background where you can't manipulate functions and classes as first-class 
>  objects - the idea that the instance method signature could be written to 
>  describe the signature of the unbound method returned by "Foo.bar" rather than 
>  the bound method returned by "Foo().bar" is an entirely foreign concept.

I disagree; I'm 100% comfortable and have internalized Python's use of 
an explicit self parameter, but it still doesn't feel more explicit or 
practical than the traditional way of writing out methods in other 
languages.  I'm inclined to say that this might be too substantial of a 
change to Python, but I don't think the current way method definitions 
work is particular elegant, and it hasn't really grown on me over all 
these years.  I still frequently spell method signatures incorrectly. 
And I can't explain the current situation to a new user, except to say 
"this is just the way it is", because the explanation only makes sense 
when you are much further into the language.  And don't get me started 
on the error messages when you get the parameter count wrong...


(As an aside directed at the original PEP, I think discussion of leaving 
self out of expressions, e.g., ".x" for "self.x", should be separate 
from the rest of this PEP).


-- 
Ian Bicking  /  ianb@[...].com  /  http://blog.ianbicking.org
_______________________________________________
Python-Dev mailing list
Python-Dev@[...].org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-dev-ml%40activestate.c
om