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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com