Guido's new method definition idea

[I V]

`$` as a shortcut for self, on the other hand, gives absolutely no
mnemonic indication what it stands for, and users would be simply left
guessing.

However, $ is sometimes used as an alternative way of writing S̸ (I've
attempted to write here S followed by U+0338 COMBINING LONG SOLIDUS
OVERLAY, in order to produce an S with a stroke through it). This is the
symbol of the "barred subject" in Lacanian psychoanalysis, which is the
Lacanian symbol for the concept of the "self" (see
http://nosubject.com/Bar ).

So, if we want Python to the programming language of choice for Lacanian
psychoanalysts, perhaps we should adopt the symbol "$" (or even, with
Python 3's support for unicode identifiers, S followed by U+0388) instead
of "self."

 

[Andreas Waldenburger]

So, if we want Python to the programming language of choice for
Lacanian psychoanalysts, perhaps we should adopt the symbol "$" (or
even, with Python 3's support for unicode identifiers, S followed by
U+0388) instead of "self."

OK, I'm sold.


/W

 

[Philip Slate]

I'd rather say "more acceptable to java-brainwashed developpers".

And I'd rather say you're trolling, but that's ok since you're
preaching to the converted. You conveniently forgot to mention the C++/
Eiffel/Smalltalk/pretty-much-every-OO-lang "brainwashed" developers
too. In reality Python, with its kludgy OO and objects being
essentially glorified dicts, is the odd one out, not the other way
around.

 

[Lie Ryan]

So, if we want Python to the programming language of choice for Lacanian
psychoanalysts, perhaps we should adopt the symbol "$" (or even, with
Python 3's support for unicode identifiers, S followed by U+0388)
instead of "self."

Is that supposed to be a serious argument or a joke?

 

[Lie Ryan]

What would be interesting would be some syntactical sugar to get rid
of the 'self' (at least in the code body).

example:
class C:
class_elements a,b,c,d

def method(self,arg):
global d
a,b,c = arg[0..3]
d = a + b
self.e = a + d

Nah, that would make it not explicit. Explicit here also means that to
refer to self's a, we need to explicitly refer to self.

Well being explicit when trying to suggest an implicit syntax (in order
to reduce typing) is a little difficult ;-)

Though you're right my main goal is not being implicit but would be
reducing typing and have shorter source code lines.

If 'global '<varname>' is accepted inside a def, then moving
'class_elements <varnames>' inside the def could be acceptable as well
though it would requiere, that this statement is repeated per def

The advantage of explicit self is to easily differentiate instance
variable with local variable/names. When I need to shorten the code, I'll
simply alias it to a local name, no need for syntax change or new keyword.

class C(object):
def __init__(self):
self.a = 2
self.b = 2
self.c = 3
def x(self):
#return ((-self.b + math.sqrt(self.b**2 - 4 * self.a * self.c)) /
(2 * self.a)), ((-self.b - math.sqrt(self.b**2 - 4 * self.a * self.c)) /
(2 * self.a))

a, b, c = self.a, self.b, self.c
sq = math.sqrt
return ((-b + sq(b**2 - 4*a*c)) / (2*a)), ((-b - sq(b**2 -
4*a*c)) / (2*a))

 

[Lie Ryan]

I think we have to test this on newbies. [snip]

Now that's talking like a programmer!

Ideas on how such a survey could be conducted? Anyone?

If this dead horse is revived because of that reason, then I'd go with
changing the error message to something that is less confusing to
newbies[1].

+ googol

I remember being tripped with the (thinking that python miscounted the
number of argument) when I was new. This has the advantage of backward
compatibility and no syntax change, just less misleading error message.

[1] anything could work, but I like this one: (c is an instance of
class C)
if the code is: c.foo(...), Error: "TypeError: c.foo() takes exactly 3
argument"
while if the code is: C.foo(...), Error: "C.foo() takes exactly 4
arguments"
You can implement c.foo as a curried C.foo function, catch C.foo's
TypeError exception then reraise it as c.foo exception.

I'm not sure that I'd find that less confusing. Because a c.foo() *does*
take four arguments, not three. It's just that the first one is implicit
(Right?).

It's not implicit, we explicitly pass c (the object instance), although
not in the argument list. So c.foo takes 3 arguments while C.foo takes 4
arguments.

In other words:
from functools import partial
c = C() -> c.attr = partial(C.attr, c)

Note the error message I gave:
"TypeError: c.foo() takes exactly 3 arguments"
"TypeError: C.foo() takes exactly 4 arguments"

There are two differences there, not only one claims to accept three and
the other 4 arguments, but also the capitalization of c/C. Here is a
clearer example:

inst = cls()
"TypeError: inst.foo() takes exactly 3 arguments"
"TypeError: cls.foo() takes exactly 4 arguments"

for comparison, python's current (2.5) error message is:
"TypeError: foo() takes exactly 4 arguments"

in addition, with this proposal we'll know how foo is being called.

The following is a quick and dirty implementation of such error message.
Note: There are still some unresolved problems though:
1. instance.[func name] is hardcoded, as I don't know how to get the
instance's name from the instance creation itself
2. Class Invoking from class gives TypeError: foo()... instead of
TypeError: Class.foo()...
3. most definitely not to be used on real application

from types import MethodType
import re
errmess = re.compile(r'(.*?) (.*?) (\d*) (arguments?) \((\d*) given\)')
def usenewexc(obj):
def wrap(f):
def wrap_(*args, **kargs):
try:
print args, kargs
return f(*args, **kargs)
except TypeError, e:
re_mess = errmess.match(e.message)
fname = re_mess.group(1)
interm = re_mess.group(2) if re_mess.group(3) != '1' else
'takes'
reqargs = int(re_mess.group(3)) - 1 if re_mess.group(3) !
= '1' else 'no'
argue_s = re_mess.group(4) if re_mess.group(3) != '1'
else 'arguments'
givenargs = int(re_mess.group(5)) - 1
raise TypeError('%s.%s %s %s %s (%s given)' %
('instance', fname, interm, reqargs, argue_s, givenargs))
return wrap_
for attrname in dir(obj):
attr = obj.__getattribute__(attrname)
if type(attr) == MethodType:
obj.__setattr__(attrname, wrap(attr))
return obj

class A(object):
def foo(self):
print ''
pass
a = usenewexc(A())
A.foo(a, 2)

 

[Bruno Desthuilliers]

Philip Slate a écrit :

And I'd rather say you're trolling,

Almost, indeed. But not as much as you !-)

 

[Christopher]

I'd like this new way of defining methods, what do you guys think?
Anyone ready for writing a PEP?

I don't really see any advantage. IMHO, it is not clearer, it is not
more concise, it makes the definition of class shared variables look
really out of place. It also makes the new programmer wonder where
the function attaches if you *don't* specify self. I also give it a
-1.

 

[anthony.tolle]

I'd be inclined to think that this defines an instancemethod on an
existing object a.  In other word, I'd read the following two lines as
more or less equivalent.

def a.add(b): return a+b

a.add = lambda b: a+b

Just as the following are equivalent:

def foo(): return bar

foo = lambda: bar

I had been -0 on this, but now I think I'm -1.

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.

 

[anthony.tolle]

I'd be inclined to think that this defines an instancemethod on an
existing object a.  In other word, I'd read the following two lines as
more or less equivalent.

def a.add(b): return a+b

a.add = lambda b: a+b

Just as the following are equivalent:

def foo(): return bar

foo = lambda: bar

I had been -0 on this, but now I think I'm -1.

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 the very purpose Carl hinted at...

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.

 

[anthony.tolle]

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

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

The above example should have read as follows:

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

 

[Ben Kaplan]

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.

I agree, this would be much nicer and would not require any special
cases. I'm not convinced that this is needed, but at least this won't
confuse newbies as much.

 

[Aaron Brady]

And I'd rather say you're trolling, but that's ok since you're
preaching to the converted. You conveniently forgot to mention the C++/
Eiffel/Smalltalk/pretty-much-every-OO-lang "brainwashed" developers
too. In reality Python, with its kludgy OO and objects being
essentially glorified dicts, is the odd one out, not the other way
around.

That's true. But what would a Python-brainwashed developer be?

 

[Arnaud Delobelle]

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

 

[Reedick, Andrew]

-----Original Message-----
From: [email protected] [mailtoython-
[email protected]] On Behalf Of Aaron Brady
Sent: Monday, December 08, 2008 3:27 PM
To: (e-mail address removed)
Subject: Re: Guido's new method definition idea

And I'd rather say you're trolling, but that's ok since you're
preaching to the converted. You conveniently forgot to mention the C++/
Eiffel/Smalltalk/pretty-much-every-OO-lang "brainwashed" developers
too. In reality Python, with its kludgy OO and objects being
essentially glorified dicts, is the odd one out, not the other way
around.

That's true. But what would a Python-brainwashed developer be?

Anyone who believes that writing beautiful, unencumbered code is efficient, while still believing that discovering type casting errors at runtime isn't grossly inefficient.


Or given whitespace delimited code, Python developers believe that nothing is important.

;-)



*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

 

[Patrick Mullen]

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

Why not? "def ob.func" is fundamentally "def ob.__dict__["func"]" anyway.

I like this idea much better than the original proposal, even though
it is pretty much unrelated.

 

[Aaron Brady]

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

I agree that it's an extension (extrapolation) of the 'def self.meth'
notation. For 'func_name', would you use the quoted string? Would
you allow arbitrary expressions for the string, and the dictionary to
add to? For example:

def dict_val( )[ "name%i"% int_val( ) ]( self, arg, arg, arg ): ...

It's not much worse than: (Unproduced)

def anon( self, arg, arg, arg ): ...
dict_val( )[ "name%i"% int_val( ) ]= anon

#or if you really want the target before the def:

@assign( dict_val( ), "name%i"% int_val( ) )
def _( self, arg, arg, arg ): ...

And the latter are already both legal. But there have been PEPs
accepted before that abbreviate 2 lines into 1.

 

[william tanksley]

I'd like this new way of defining methods, what do you guys think?
Anyone ready for writing a PEP?

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. This is a good thing because it makes it easy to refer to
methods consistently.

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.

Unfortunately, writing a PEP is sadly outside my skillset.

Daniel

-Wm

 

[greg]

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

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

I agree -- this would be a much better use of the syntax,
and I'd like to see this possibility left open.

 

[Aaron Brady]

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.

I claim that the burden of proof rests with the author of the
proposal.