[Python-Dev] Draft proposal: Implicit self in Python 3.0

Jim Jewett jimjjewett at gmail.com
Fri Jan 6 20:14:21 CET 2006


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


More information about the Python-Dev mailing list