Nick Coghlan wrote:

>     Eliminate the need for explicit class and self
>     slots in class and instance methods by
>     implicitly providing those slots on all functions.

>  How many positional arguments does the function
>  have if I retrieve it from the class, rather than from
>  an instance?

To keep things simple, it should have the same
number of positional arguments no matter how
you retrieve it -- think of self and cls as keyword
arguments that we currently write in an odd manner.

>     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?

>  The answer to the first question *has* to be 3,
>  or we lose too much functionality

No, it should be 2.  If you use it as a staticmethod,
there isn't any problem.  If you really want a method
outside of its context, then pass self (or cls) as a keyword.

    f(4,5,self=Foo(10))

(I also think we could use class as the keyword, since
    class=expression
is different from
    class Name:
but that is a separate question.)

If you like having self at the front -- well, wasn't
the "keywords must be last" restriction likely to
go away even before python 3.0?

>  ... 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 find it sort of strange that the signatures are
different in the first place.  I prefer the one
without boilerplate.

-jJ
_______________________________________________
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