Guido's new method definition idea

[Bruno Desthuilliers]

william tanksley a écrit :

I think it's an awesome proposal. It's about time! With this change,
defining methods uses the same special syntax hack that calling them
does.

except that self doesn't exist when the method is defined. Or, should I
say, when the function is defined - because that's really a function. It
only becomes a method when looked up on the class (either directly or
thru an instance), thanks to the descriptor protocol (hint : there's
*no* "syntax hack" involved when calling inst.method - just partial
evaluation). IOW : this def self.stuff thing only empeds correct
understanding of Python's object model.

(snip)

I see a lot of people are against it; I admit that it's not the status
quo, but that's not a sufficient argument against a change (it defeats
all possible changes). A more interesting argument against it is that
it's special "implicit" syntax; but I would argue that it merely
reflects the existing special syntax of method calls.

Once again, there's *nothing* like an "existing special syntax of method
calls". Just the use of the descriptor protocol (the very same mechanism
that's powers properties) and partial application. I've already
described this more than once in details in this newsgroup FWIW.

 

[Antoine De Groote]

This brings up another question, what would one use when referencing
method names inside the class definition?:

class C:
def self.method(arg):
self.value = arg
def self.othermethod(arg):
self.value = arg
# do this?
funcs = (self.method, self.othermethod)
# or this?
funcs = (method, othermethod)

On another related note, I would be interested in seeing this syntax
adopted for a different purpose...

Normally, if I'm defining a nested function that needs to be stored as
an object attribute, I have to use a dummy name, like the following:

class C:
def createfunc(self, arg):
def _dummy(arg):
return arg + 1
self.func = _dummy

It would be nice to be able to do the following instead:

class C:
def createfunc(self):
def self.func(arg):
return arg + 1

Or, after the class definition is done, to extend it dynamically:

def C.method(self, arg):
self.value = arg

...which would be the equivalent of the following:

def method(self, arg):
self.value = arg
C.method = method

Since functions are first-class objects, it seems perfectly reasonable
to me.

A decorator might be more advisable here.

class C:
def createfunc(self):
@some_decorator_name
def func(arg):
return arg + 1

Altough I'm not a huge fan of decorators, this would be more in line
what Python already can do an would lean on the @staticmethod and
@classmethod decorators.

 

[ptn]

Is "@" a "speaking identifier? How about "#" and "!="? Last I heard,
they were all part of Python.

Those are operators and the comment starter, not identifiers.

I think that the more used an operator/variable is, the least mnemonic
it' name has to be. Given that you'll be useing it all the time, you
don't need it's name reminding you what it's supposed to be used for.
So the "it's not a speaking-identifier" argument is not a good one, in
my opinion.

However, $ being ugly is a very strong argument. Python is supposed
to be beautiful. And sure you can get used to it, just as you can get
used to Pearl, assembly language or Brainfuck. By beautiful we mean
beautiful at first sight.

 

[Lie Ryan]

class C:
def createfunc(self):
def self.func(arg):
return arg + 1

Or, after the class definition is done, to extend it dynamically:

def C.method(self, arg):
self.value = arg

...which would be the equivalent of the following:

def method(self, arg):
self.value = arg
C.method = method

What about the following then?

functions = {}

def functions['square'](x):
return x*x

def functions['cube'](x):
return x**3

-1. In most cases, it would generally be better as:

def functions(x):
return x.func()

since the rule-of-thumb of OOP is that objects should do things by
itself. This is also more in line with python's built-in functions, which
merely calls the appropriate __special__ names.

and whenever creating an object is too complex, that could easily be
def functions(which, x):
def _function_square():
return x*x
def _function_cube():
return x**3

d = {'square': _function_square,
'cube': _function_cube,
}

return d[which]()