[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