Re: Why do class methods always need 'self' as the first parameter?
Prasad, Ramit ramit.pra...@jpmorgan.com writes: It seems to me that if I add a function to the list of class attributes it will automatically wrap with self but adding it to the object directly will not wrap the function as a method. Can somebody explain why? I would have thought that any function added to an object would be a method (unless decorated as a class method). The special magic to transform a function into a method is only applied for functions found as attributes of the class, not for instance attributes. It is a matter of design. Hmm, or does the decoration just tell Python not to turn an object's function into a method? I.e. Is the decorator basically just the syntactic sugar for doing the above? The classmethod decorator transforms the method (or actually the function) into a different kind of object (a class method). -- Piet van Oostrum p...@vanoostrum.org WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4] -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
Chris Torek nos...@torek.net writes:
[snip]
Instead, we have a syntax where you, the programmer, write out the
name of the local variable that binds to the first parameter. This
means the first parameter is visible. Except, it is only visible
at the function definition -- when you have the instance and call
the instance or class method:
black_knight = K()
black_knight.meth1('a', 1)
black_knight.meth2(2)
the first parameters (black_knight, and black_knight.__class__,
respectively) are magic, and invisible.
Thus, Python is using the explicit is better than implicit rule
in the definition, but not at the call site. I have no problem with
this. Sometimes I think implicit is better than explicit. In this
case, there is no need to distinguish, at the calls to meth1() and
meth2(), as to whether they are class or instance methods. At
the *calls* they would just be distractions.
It *is* explicit also at the call site. It only is written at the left of the
dot rather than at the right of the parenthesis. And that is necessary to
locate which definition of the method applies. It would be silly to repeat this
information after the parenthesis. Not only silly, it would be stupid as it
would be a source of errors, and an example of DRY.
--
Piet van Oostrum p...@vanoostrum.org
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
Chris Torek nos...@torek.net writes: [snip] when you have [an] instance and call [an] instance or class method: [note: I have changed the names very slightly here, and removed additional arguments, on purpose] black_knight = K() black_knight.spam() black_knight.eggs() the first parameters ... are magic, and invisible. Thus, Python is using the explicit is better than implicit rule in the definition, but not at the call site. ... In article m2wrdnf53u@cochabamba.vanoostrum.org Piet van Oostrum p...@vanoostrum.org wrote: It *is* explicit also at the call site. It only is written at the left of the dot rather than at the right of the parenthesis. It cannot possibly be explicit. The first parameter to one of the method functions is black_knight, but the first parameter to the other method is black_knight.__class__. Which one is which? Is spam() the instance method and eggs() the class method, or is spam() the class method and eggs the instance method? (One does not, and should not, have to *care*, which is kind of the point here. :-) ) And that is necessary to locate which definition of the method applies. By that I assume you mean the name black_knight here. But the name is not required to make the call; see the last line of the following code fragment: funclist = [] ... black_knight = K() funclist.append(black_knight.spam) funclist.append(black_knight.eggs) ... # At this point, let's say len(funclist) 2, # and some number of funclist[i] entries are ordinary # functions that have no special first parameter. random.choice(funclist)() It would be silly to repeat this information after the parenthesis. Not only silly, it would be stupid as it would be a source of errors, and an example of DRY. Indeed. But I believe the above is a demonstration of how the self or cls parameter is in fact implicit, not explicit. (I am using python 2.x, and doing this in the interpreter: random.choice(funclist) -- without the parentheses to call the function -- produces: bound method K.[name omitted] of __main__.K object at 0x249f50 bound method type.[name omitted] of class '__main__.K' function ordinary at 0x682b0 The first is the instance method, whose name I am still keeping secret; the second is the class method; and the third is the ordinary function I added to the list. The actual functions print their own name and their parameters if any, and one can see that the class and instance methods get one parameter, and the ordinary function gets none.) -- In-Real-Life: Chris Torek, Wind River Systems Intel require I note that my opinions are not those of WRS or Intel Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603 email: gmail (figure it out) http://web.torek.net/torek/index.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
On Aug 31, 9:35 am, T. Goodchild tgoodch...@gmail.com wrote: I’m new to Python, and I love it. The philosophy of the language (and of the community as a whole) is beautiful to me. Welcome aboard mate! But one of the things that bugs me Oh here we go! :-) is the requirement that all class methods have 'self' as their first parameter. On a gut level, to me this seems to be at odds with Python’s dedication to simplicity. It will will seem odd at first. I too hated typing all those selfs all the time. But believe me my new friend in no time those selfs will roll of your fingers with great ease. You'll forget how much you hate them and find much more to complain about. Like for instance: I really lament the missing redundancy of Explicit Lexical Scoping in python. For me global variables should have to be qualified. For example, consider Python’s indent-sensitive syntax. [...] and the result was a significantly improved signal-to-noise ratio in the readability of Python code. Yes, forced indention is my favorite aspect of Python! So why is 'self' necessary on class methods? It could be that Guido has a exaggerated self importance and just liked the sound of all those selfs whist reading source code. However i believe the real reason is really readability! It takes a while to understand this aspect because the natural human response is to be lazy (for instance i could have used used to in the previous sentence if i was slothful). We are all inherently lazy beings who need structure to keep us from spiraling out of control into the abyss of selfishness. GvR: Computer Scientist and Behavioral psychologist. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
On Tue, 6 Sep 2011 11:10 am Chris Torek wrote: black_knight = K() black_knight.spam() black_knight.eggs() the first parameters ... are magic, and invisible. Thus, Python is using the explicit is better than implicit rule in the definition, but not at the call site. ... In article m2wrdnf53u@cochabamba.vanoostrum.org Piet van Oostrum p...@vanoostrum.org wrote: It *is* explicit also at the call site. It only is written at the left of the dot rather than at the right of the parenthesis. It cannot possibly be explicit. The first parameter to one of the method functions is black_knight, but the first parameter to the other method is black_knight.__class__. I think you are expecting more explicitness than actually required. There are degrees of explicitness: - The current President of the United States is a black man. - On 6th September 2011, the duly constituted President of the United States of America is a black man. - On 6th September 2011, the duly constituted government official with the title of President of the nation known as the United States of America is an individual member of the species Homo sapiens with XY chromosomes and of recent African ancestry. As opposed to implicit: - He is a black guy. There is no requirement for every last gory detail to be overtly specified in full. I quote from WordNet: explicit adj 1: precisely and clearly expressed or readily observable; leaving nothing to implication; explicit instructions; she made her wishes explicit; explicit sexual scenes [syn: expressed] [ant: implicit] 2: in accordance with fact or the primary meaning of a term [syn: denotative] Note the second definition in particular: in accordance with the primary meaning of a term: the primary meaning of class method is that it receives the class rather than the instance as first argument. The explicit is better than implicit Zen should, in my opinion, be best understood as a recommendation that code should, in general, avoid getting input from context. In general, functions should avoid trying to decide which behaviour is wanted according to context or the environment: def func(x): if running_in_a_terminal(): print The answer is, (x+1)/2 else: printer = find_a_printer() if printer is not None: printer.send((x+1)/2, header=func(%r)%x, footer=Page 1) else: # Try sending email to the current user, the default user, # postmaster or root in that order. msg = make_email(The answer is, (x+1)/2) for user in [get_current_user(), DEFAULT_USER, root@localhost.localdomain, ...]: result = send_mail(msg, to=user) if result == 0: break else: # Fall back on beeping the speakers in Morse code ... (what if I want to beep the speakers from the terminal?), but not as a prohibition against code like this: def factorial(x): # Return the factorial of the integer part of x. n = int(x) if n = 1: return 1 return n*factorial(n-1) There's no need to require the user to explicitly call int(x) before calling factorial just to satisfy the Zen. A function is free to process arguments as required, even to throw out information (e.g. float - int, instance - class). What it shouldn't do is *add* information implied by context (or at least, it should be very cautious in doing so, and document it carefully, and preferably allow the caller to easily override such implied data). Which one is which? Is spam() the instance method and eggs() the class method, or is spam() the class method and eggs the instance method? (One does not, and should not, have to *care*, which is kind of the point here. :-) ) You can't tell just from the syntax used to call them: function(arg) bound_method(arg) builtin_function_or_method(arg) callable_instance(arg) type(arg) all use the same syntax. There is no requirement that you should be able to tell *everything* about a line of code just from the syntax used. If you want to know whether black_knight.spam is an instance method or a class method, or something else, use introspection to find out. By that I assume you mean the name black_knight here. But the name is not required to make the call; see the last line of the following code fragment: funclist = [] ... black_knight = K() funclist.append(black_knight.spam) funclist.append(black_knight.eggs) ... # At this point, let's say len(funclist) 2, # and some number of funclist[i] entries are ordinary # functions that have no special first parameter. random.choice(funclist)() Irrelevant. The instance used for the bound method is explicitly specified when you create it. But there's no requirement that you need to explicitly specify the instance every single time you
Re: Why do class methods always need 'self' as the first parameter?
On Sep 1, 8:26 am, Ian Kelly ian.g.ke...@gmail.com wrote:
On Thu, Sep 1, 2011 at 6:45 AM, John Roth johnro...@gmail.com wrote:
I personally consider this to be a wart. Some time ago I did an
implementation analysis. The gist is that, if self and cls were made
special variables that returned the current instance and class
respectively, then the compiler could determine whether a function was
an instance or class method. If it then marked the code object
appropriately you could get rid of all of the wrappers and the
attendant run-time overhead.
I don't see how you could get rid of the wrappers. Methods would
still need to be bound, somehow, so that code like this will work:
methods = {}
for obj in objs:
if obj.is_flagged:
methods[obj.user_id] = obj.do_work
else:
methods[obj.user_id] = obj.do_other_work
# ...
methods[some_user_id]()
Without method wrappers, how does the interpreter figure out which
instance is bound to the method being called?
Cheers,
Ian
Good question.
Currently the instance wrapper is created during method instantiation,
so the instance is obviously available at that point. There are two
rather obvious ways of remembering it. One is to use the invocation
stack, which has the instance. Another would be for the compiler to
create a local variable for the instance and possibly the class and
fill them in at instantiation time. Both of these require fixing the
names self and cls so the compiler knows what to do with them. The
first would require giving these two names their own bytecodes, the
second makes them simple local variables the same as the ones in the
method headers. The latter also allows them to be changed by the
method, which is probably not the world's best programming practice
although it's possible now.
John Roth
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
On Fri, Sep 2, 2011 at 11:51 AM, John Roth johnro...@gmail.com wrote:
I don't see how you could get rid of the wrappers. Methods would
still need to be bound, somehow, so that code like this will work:
methods = {}
for obj in objs:
if obj.is_flagged:
methods[obj.user_id] = obj.do_work
else:
methods[obj.user_id] = obj.do_other_work
# ...
methods[some_user_id]()
Without method wrappers, how does the interpreter figure out which
instance is bound to the method being called?
Cheers,
Ian
Good question.
Currently the instance wrapper is created during method instantiation,
so the instance is obviously available at that point. There are two
rather obvious ways of remembering it. One is to use the invocation
stack, which has the instance. Another would be for the compiler to
create a local variable for the instance and possibly the class and
fill them in at instantiation time. Both of these require fixing the
names self and cls so the compiler knows what to do with them. The
first would require giving these two names their own bytecodes, the
second makes them simple local variables the same as the ones in the
method headers. The latter also allows them to be changed by the
method, which is probably not the world's best programming practice
although it's possible now.
That's not what I asked. Both of those options are storing the
instance within a stack frame, once it's been called. I'm asking how
you would remember the instance during the interval from the time when
the method
is accessed until when it has been called.
In the code above, the method is accessed just before it is stored in
the dictionary. That is when the method wrapper is currently created,
and the instance is available. It is not called until much later,
possibly not even within the same function. How would you remember
the instance over that period without wrapping the function?
Cheers,
Ian
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
On Sep 2, 2:30 pm, Ian Kelly ian.g.ke...@gmail.com wrote:
On Fri, Sep 2, 2011 at 11:51 AM, John Roth johnro...@gmail.com wrote:
I don't see how you could get rid of the wrappers. Methods would
still need to be bound, somehow, so that code like this will work:
methods = {}
for obj in objs:
if obj.is_flagged:
methods[obj.user_id] = obj.do_work
else:
methods[obj.user_id] = obj.do_other_work
# ...
methods[some_user_id]()
Without method wrappers, how does the interpreter figure out which
instance is bound to the method being called?
Cheers,
Ian
Good question.
Currently the instance wrapper is created during method instantiation,
so the instance is obviously available at that point. There are two
rather obvious ways of remembering it. One is to use the invocation
stack, which has the instance. Another would be for the compiler to
create a local variable for the instance and possibly the class and
fill them in at instantiation time. Both of these require fixing the
names self and cls so the compiler knows what to do with them. The
first would require giving these two names their own bytecodes, the
second makes them simple local variables the same as the ones in the
method headers. The latter also allows them to be changed by the
method, which is probably not the world's best programming practice
although it's possible now.
That's not what I asked. Both of those options are storing the
instance within a stack frame, once it's been called. I'm asking how
you would remember the instance during the interval from the time when
the method
is accessed until when it has been called.
In the code above, the method is accessed just before it is stored in
the dictionary. That is when the method wrapper is currently created,
and the instance is available. It is not called until much later,
possibly not even within the same function. How would you remember
the instance over that period without wrapping the function?
Cheers,
Ian
I see what you're saying now - I didn't get your example the first
time. So the optimization of eliminating the instance wrapper is only
possible if it's retrieved via the instance and then called
immediately. That would seem to be a useful optimization if it was
possible - I wonder if PyPy is doing it since they've got that fancy
JIT, and it would seem that an immediate call after retrieving the
method is overwhelmingly more frequent than saving it for later.
I think it's still true that calling the underlying function object
through the instance wrapper requires remaking the parameter list,
which seems to be another piece of unnecessary overhead, unless
there's a fast path through the call machinery that treats the
instance specially.
It does, however, decouple the two issues so I can't claim the
optimization as a benefit. Drat.
John Roth
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
On Aug 31, 5:35 pm, T. Goodchild tgoodch...@gmail.com wrote: I’m new to Python, and I love it. The philosophy of the language (and of the community as a whole) is beautiful to me. But one of the things that bugs me is the requirement that all class methods have 'self' as their first parameter. On a gut level, to me this seems to be at odds with Python’s dedication to simplicity. For example, consider Python’s indent-sensitive syntax. Although other languages didn’t use indentation to specify scope, programmers always used indentation anyways. Making indentation took a common practice, made it a rule, and the result was a significantly improved signal-to-noise ratio in the readability of Python code. So why is 'self' necessary on class methods? It seems to me that the most common practice is that class methods *almost always* operate on the instance that called them. It would make more sense to me if this was assumed by default, and for static methods (methods that are part of a class, but never associated with a specific instance) to be labelled instead. Just curious about the rationale behind this part of the language. It's required to make distinction between objects inside the calss and outside of it. Seems pretty logical to me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
On Aug 31, 5:35 pm, T. Goodchild tgoodch...@gmail.com wrote: So why is 'self' necessary on class methods? Just curious about the rationale behind this part of the language. When instance variables are accessed with the 'self.varname' syntax, it is clear to the programmer that an instance variable is accessed, and not some global. Other languages have weird syntax conventions like that you have to prepend all instance attributes with an '@', and in languages like C++ where there is not necessarily such a syntactic requirement, many programmers use ad-hoc constructs like '_varname' or 'm_varname' to make the distinction clear. It seems to me that the most common practice is that class methods *almost always* operate on the instance that called them. It would make more sense to me if this was assumed by default, and for static methods (methods that are part of a class, but never associated with a specific instance) to be labelled instead. Yes, you have a point there. My personal preference would be to optimize for the most common case, while exceptions to the norm are still possible, but perhaps a bit more verbose. Greetings -- Learn to value yourself, which means: fight for your happiness. - Ayn Rand -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
On Aug 31, 8:35 am, T. Goodchild tgoodch...@gmail.com wrote: I’m new to Python, and I love it. The philosophy of the language (and of the community as a whole) is beautiful to me. But one of the things that bugs me is the requirement that all class methods have 'self' as their first parameter. On a gut level, to me this seems to be at odds with Python’s dedication to simplicity. For example, consider Python’s indent-sensitive syntax. Although other languages didn’t use indentation to specify scope, programmers always used indentation anyways. Making indentation took a common practice, made it a rule, and the result was a significantly improved signal-to-noise ratio in the readability of Python code. So why is 'self' necessary on class methods? It seems to me that the most common practice is that class methods *almost always* operate on the instance that called them. It would make more sense to me if this was assumed by default, and for static methods (methods that are part of a class, but never associated with a specific instance) to be labelled instead. Just curious about the rationale behind this part of the language. I personally consider this to be a wart. Some time ago I did an implementation analysis. The gist is that, if self and cls were made special variables that returned the current instance and class respectively, then the compiler could determine whether a function was an instance or class method. If it then marked the code object appropriately you could get rid of all of the wrappers and the attendant run-time overhead. I've never published the analysis because that train has already left the shed. The earliest it could be considered would be 4.0, which isn't even on the horizon. John Roth -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
On Thu, Sep 1, 2011 at 6:45 AM, John Roth johnro...@gmail.com wrote:
I personally consider this to be a wart. Some time ago I did an
implementation analysis. The gist is that, if self and cls were made
special variables that returned the current instance and class
respectively, then the compiler could determine whether a function was
an instance or class method. If it then marked the code object
appropriately you could get rid of all of the wrappers and the
attendant run-time overhead.
I don't see how you could get rid of the wrappers. Methods would
still need to be bound, somehow, so that code like this will work:
methods = {}
for obj in objs:
if obj.is_flagged:
methods[obj.user_id] = obj.do_work
else:
methods[obj.user_id] = obj.do_other_work
# ...
methods[some_user_id]()
Without method wrappers, how does the interpreter figure out which
instance is bound to the method being called?
Cheers,
Ian
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
In 0dc26f12-2541-4d41-8678-4fa53f347...@g9g2000yqb.googlegroups.com T. Goodchild tgoodch...@gmail.com writes: So why is 'self' necessary on class methods? It seems to me that the most common practice is that class methods *almost always* operate on the instance that called them. It would make more sense to me if this was assumed by default, and for static methods (methods that are part of a class, but never associated with a specific instance) to be labelled instead. Just curious about the rationale behind this part of the language. How would a method access instance variables without 'self'? They probably could have made 'self' a magical attribute that just appears out of thin air instead of being passed as an argument, like 'this' in C++. But would that really provide any benefit? -- John Gordon A is for Amy, who fell down the stairs gor...@panix.com B is for Basil, assaulted by bears -- Edward Gorey, The Gashlycrumb Tinies -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
On 8/31/2011 7:35 AM T. Goodchild said... Just curious about the rationale behind this part of the language. http://docs.python.org/faq/design.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
On 2011-08-31, T. Goodchild tgoodch...@gmail.com wrote: I?m new to Python, and I love it. The philosophy of the language (and of the community as a whole) is beautiful to me. But one of the things that bugs me is the requirement that all class methods have 'self' as their first parameter. On a gut level, to me this seems to be at odds with Python?s dedication to simplicity. Think it through carefully, and you'll probably agree with Python's design. But not necessarily. In any case, this is a very common complaint, so check out the Python FAQ. http://docs.python.org/faq/design.html#why-self -- Neil Cerutti A politician is an arse upon which everyone has sat except a man. e. e. cummings -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
Hello, 2011/8/31 T. Goodchild tgoodch...@gmail.com: But one of the things that bugs me is the requirement that all class methods have 'self' as their first parameter. On a gut level, to me this seems to be at odds with Python’s dedication to simplicity. I think the answer to this question is part of the zen of python: Explicit is better than implicit. http://www.python.org/dev/peps/pep-0020/ Regards, Javier -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
T. Goodchild wrote: So why is 'self' necessary on class methods? I assume you are talking about the declaration in the method signature: def method(self, args): ... rather than why methods have to be called using self.method. If not, there's already a FAQ for that second question: http://docs.python.org/faq/design.html#why-self It seems to me that the most common practice is that class methods *almost always* operate on the instance that called them. By the way, what you're calling class methods are actually *instance* methods, because they receive the instance self as the first parameter. Python does have class methods, which receive the class, not the instance, as the first parameter. These are usually written something like this: class K(object): @classmethod def spam(cls, args): print cls # always prints class K, never the instance Just like self, the name cls is a convention only. Class methods are usually used for alternate constructors. There are also static methods, which don't receive any special first argument, plus any other sort of method you can invent, by creating descriptors... but that's getting into fairly advanced territory. They're generally specialised, and don't see much use. As you can see, the terminology is not exactly the same as Java. It would make more sense to me if this was assumed by default, ... Well here's the thing. Python methods are wrappers around function objects. The method wrapper knows which instance is involved (because of the descriptor magic which I alluded to above), but the function doesn't and can't. Or at least not without horrible run-time hacks. By treating self as an ordinary parameter which needs to be declared, you can do cool stuff like bound and unbound methods: f = instance.upper # this is a bound method g = str.upper # this is an unbound method The bound method f already has the instance self filled in, so to speak. So you can now just call it, and it will work: f() = returns INSTANCE The unbound method still needs the instance supplied. This makes it perfect for code like this: for instance in (hello, world): print g(instance) especially if you don't know what g will be until run-time. (E.g. will it be str.upper, str.lower, str.title?) Because methods require that first argument to be given explicitly, unbound methods are practically ordinary functions. They're so like functions that in Python 3, they're done away with altogether, and the unwrapped function object will be returned instead. You can also do nifty stuff like dynamic method injections: def func(a, b): ... print(a, b) ... class K(object): ... pass ... K.func = func # dynamically inject a method instance = K() instance.func(23) (__main__.K object at 0xb7f0a4cc, 23) and it all just works. You can even inject a method onto the instance, although it takes a bit more effort to make that work. All this is possible without nasty hacks because self is treated as just an ordinary parameter of functions. Otherwise, the compiler would need to know whether the function was being called from inside a method wrapper or not, and change the function signature appropriately, and that just gets too ugly and messy for words. So for the cost of having to declare self as an argument, we get: * instant visual recognition of what's intended as a method (the first argument is called self) and what isn't * a nicely consistent treatment of function signatures at all times * clean semantics for the local variable namespace * the same mechanism (with minor adjustments) can be used for class and static methods * bound and unbound methods semantics plus as a bonus, plenty of ongoing arguments about whether or not having to explicitly list self as a parameter is a good thing or not, thus keeping people busy arguing on mailing lists instead of coding wink -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
John Gordon wrote: In 0dc26f12-2541-4d41-8678-4fa53f347...@g9g2000yqb.googlegroups.com T. Goodchild tgoodch...@gmail.com writes: So why is 'self' necessary on class methods? It seems to me that the most common practice is that class methods *almost always* operate on the instance that called them. It would make more sense to me if this was assumed by default, and for static methods (methods that are part of a class, but never associated with a specific instance) to be labelled instead. Just curious about the rationale behind this part of the language. How would a method access instance variables without 'self'? If Python had compile time declarations, the compiler could know whether x=1 was referring to a local variable x or an attribute x. The reader might not, but the compiler would :) By the way, although the Python docs are a little inconsistent, the usual term here is attribute rather than instance variable. Attributes need not live on the instance: they can also live on the class, a superclass, or be computed at run-time via at least three different mechanisms I can think of (__getattribute__, __getattr__, properties). Local variables are treated a bit differently from attributes, but broadly speaking, if you need a dot to access something, it's an attribute, if you don't, it's a name binding (or variable). Python even has two different sorts of errors for variable lookup failures: NameError (or UnboundLocalError) for un-dotted names, and AttributeError for dotted names. They probably could have made 'self' a magical attribute that just appears out of thin air instead of being passed as an argument, like 'this' in C++. But would that really provide any benefit? Well obviously the C++ people thought so :) The effort to type self, in method signatures is pretty low. I don't think it is a problem. But other languages are free to choose differently. Cobra, for example, is explicitly derived from Python in many ways, but it drops the self (as well as other changes). http://cobra-language.com/docs/python/ -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
On 2011-08-31, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Well obviously the C++ people thought so :) Well _that's_ certainly a ringing endorsement in the context of designing a language that's easy to understand and use. ;) -- Grant Edwards grant.b.edwardsYow! Where's SANDY DUNCAN? at gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
On 8/31/2011 10:35 AM, T. Goodchild wrote: But one of the things that bugs me is the requirement that all class methods have 'self' as their first parameter. On a gut level, to me this seems to be at odds with Python’s dedication to simplicity. Actually, it is a consequence of Python's dedication to simplicity. A method is simply a function that is an attribute of a class. (This is even clearer in Py 3.) Hence, there is no special syntax for methods. Consider def double(obj): return 2*obj.value class C: def __init__(self, val): self.value = val c = C(3) C.double = double c.doub = double # not c.double as that would mask access to C.double in c.double() below print(double(c), C.double(c), c.double(), c.doub(c)) # 6 6 6 6 -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
RE: Why do class methods always need 'self' as the first parameter?
def double(obj): return 2*obj.value class C: def __init__(self, val): self.value = val c = C(3) C.double = double c.doub = double # not c.double as that would mask access to C.double in c.double() below print(double(c), C.double(c), c.double(), c.doub(c)) Sorry if I get some of the following terminology wrong, I get a bit confused on Python terms. I hope the following is still coherent. (Is there a dictionary of Python terminology?) Given the above example I get this print c.double(c) TypeError: double() takes exactly 1 argument (2 given) print c.doub(c) 6 It seems to me that if I add a function to the list of class attributes it will automatically wrap with self but adding it to the object directly will not wrap the function as a method. Can somebody explain why? I would have thought that any function added to an object would be a method (unless decorated as a class method). Hmm, or does the decoration just tell Python not to turn an object's function into a method? I.e. Is the decorator basically just the syntactic sugar for doing the above? Ramit Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology 712 Main Street | Houston, TX 77002 work phone: 713 - 216 - 5423 This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
On Wed, Aug 31, 2011 at 10:12 AM, Prasad, Ramit ramit.pra...@jpmorgan.com wrote: def double(obj): return 2*obj.value class C: def __init__(self, val): self.value = val c = C(3) C.double = double c.doub = double # not c.double as that would mask access to C.double in c.double() below print(double(c), C.double(c), c.double(), c.doub(c)) Sorry if I get some of the following terminology wrong, I get a bit confused on Python terms. I hope the following is still coherent. (Is there a dictionary of Python terminology?) The documentation has a glossary: http://docs.python.org/glossary.html It's not entirely comprehensive though. Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
In article 0dc26f12-2541-4d41-8678-4fa53f347...@g9g2000yqb.googlegroups.com
T. Goodchild asked, in part:
... One of the things that bugs me is the requirement that all class
methods have 'self' as their first parameter.
In article 4e5e5628$0$29977$c3e8da3$54964...@news.astraweb.com
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
[Comprehensive reply, noting that these are actually instance
methods, and that there are class and static methods as well]:
Python does have class methods, which receive the class, not the instance,
as the first parameter. These are usually written something like this:
class K(object):
@classmethod
def spam(cls, args):
print cls # always prints class K, never the instance
Just like self, the name cls is a convention only. Class methods are usually
used for alternate constructors.
There are also static methods, which don't receive any special first
argument, plus any other sort of method you can invent, by creating
descriptors... but that's getting into fairly advanced territory. ...
[rest snipped]
I am not sure whether T. Goodchild was asking any of the above or
perhaps also one other possible question: if an instance method
is going to receive an automatic first self parameter, why require
the programmer to write that parameter in the def? For instance
we *could* have:
class K(object):
def meth1(arg1, arg2):
self.arg1 = arg1 # self is magically available
self.arg2 = arg2
@classmethod
def meth2(arg):
use(cls) # cls is magically available
and so on. This would work fine. It just requires a bit of implicit
sneakiness in the compiler: an instance method magically creates
a local variable named self that binds to the invisible first
parameter, and a class method magically creates a local variable
named cls that binds to the invisible first parameter, and so
on.
Instead, we have a syntax where you, the programmer, write out the
name of the local variable that binds to the first parameter. This
means the first parameter is visible. Except, it is only visible
at the function definition -- when you have the instance and call
the instance or class method:
black_knight = K()
black_knight.meth1('a', 1)
black_knight.meth2(2)
the first parameters (black_knight, and black_knight.__class__,
respectively) are magic, and invisible.
Thus, Python is using the explicit is better than implicit rule
in the definition, but not at the call site. I have no problem with
this. Sometimes I think implicit is better than explicit. In this
case, there is no need to distinguish, at the calls to meth1() and
meth2(), as to whether they are class or instance methods. At
the *calls* they would just be distractions.
At the *definitions*, they are not as distraction-y since it is
important to know, during the definition, whether you are operating
on an instance (meth1) or the class itself (meth2), or for that
matter on neither (static methods). One could determine this from
the absence or presence of @classmethod or @staticmethod, but
the minor redundancy in the def statement seems, well, minor.
Also, as a bonus, it lets you obfuscate the code by using a name
other than self or cls. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Intel require I note that my opinions are not those of WRS or Intel
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
On Wed, Aug 31, 2011 at 11:12 AM, Prasad, Ramit ramit.pra...@jpmorgan.com wrote: It seems to me that if I add a function to the list of class attributes it will automatically wrap with self but adding it to the object directly will not wrap the function as a method. Can somebody explain why? I would have thought that any function added to an object would be a method (unless decorated as a class method). Because things stored on the class are generally viewed as part of the class definition, whereas things stored on an instance are generally viewed as data -- a function stored on an object instance is usually just meant to be a function. Consider the following code: class Sorter(object): def __init__(self, keyfunc): self.keyfunc = keyfunc def sort(self, item_list): item_list.sort(key=self.keyfunc) sorter = Sorter(lambda x: x.id) sorter.sort(some_list_of_items) If adding keyfunc as an attribute to the object wrapped it up as a method, it would break, since the function is not expecting a self argument. More technically, because descriptors are only invoked when they're stored on the class. Hmm, or does the decoration just tell Python not to turn an object's function into a method? I.e. Is the decorator basically just the syntactic sugar for doing the above? If you mean the staticmethod decorator, yes, it pretty much just wraps the function as a staticmethod instance to prevent it from being wrapped into an ordinary method when it's accessed. Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
On 8/31/2011 1:12 PM, Prasad, Ramit wrote: def double(obj): return 2*obj.value class C: def __init__(self, val): self.value = val c = C(3) C.double = double c.doub = double # not c.double as that would mask access to C.double in c.double() print(double(c), C.double(c), c.double(), c.doub(c)) Above is 3.2 code. To be exactly equivalent with 2.x, you need class C(object): Sorry if I get some of the following terminology wrong, I get a bit confused on Python terms. I hope the following is still coherent. (Is there a dictionary of Python terminology?) Given the above example I get this print c.double(c) TypeError: double() takes exactly 1 argument (2 given) Right, because c.double() translates to C.double(c), and c.double(x) translates to C.double(c,x), which is not valid. print c.doub(c) 6 It seems to me that if I add a function to the list of class attributes it will automatically wrap with self When accessed via an instance of the class, the instance is automagically added as the first argument to be bound to the first parameter. The name 'self' is a convention, not a requirement. but adding it to the object directly will not wrap the function as a method. Can somebody explain why? Someone else did. Not wrapping is normal, wrapping is a special case. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
Chris Torek wrote: There are also static methods, which don't receive any special first argument, plus any other sort of method you can invent, by creating descriptors... but that's getting into fairly advanced territory. ... [rest snipped] I am not sure whether T. Goodchild was asking any of the above or perhaps also one other possible question: if an instance method is going to receive an automatic first self parameter, why require the programmer to write that parameter in the def? Er, yes, just like I suggested in my opening paragraph, and as I answered following the bit you marked as snipped :) For instance we *could* have: class K(object): def meth1(arg1, arg2): self.arg1 = arg1 # self is magically available self.arg2 = arg2 @classmethod def meth2(arg): use(cls) # cls is magically available and so on. This would work fine. It just requires a bit of implicit sneakiness in the compiler: an instance method magically creates a local variable named self that binds to the invisible first parameter, and a class method magically creates a local variable named cls that binds to the invisible first parameter, and so on. It would need more than a bit, because methods are just wrappers around functions. One way would be for Python to give that up, and require methods to be special built-in types like functions. That adds complexity to the compiler, and (very likely) would decrease the level of dynamism possible. Another way would be for the compiler to perform darkest black magic to determine whether the function was being called from inside a method or not. That would be complicated and fragile. [...] At the *definitions*, they are not as distraction-y since it is important to know, during the definition, whether you are operating on an instance (meth1) or the class itself (meth2), or for that matter on neither (static methods). One could determine this from the absence or presence of @classmethod or @staticmethod classmethod and staticmethod are functions, not declarations. You can't assume that @classmethod is the only way to get a class method: the metaclass could do it, or you could inject one in from the outside. You can dynamically change the state of a method from instance method to class method and back again at run-time. Python classes have a lot of dynamism made possible by the fact that methods are just wrappers around functions with an explicitly declared self. That dynamism is rarely used, but not *that* rarely, and is very useful when used. Implicit self would likely negate all that. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
On Thu, Sep 1, 2011 at 10:48 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Python classes have a lot of dynamism made possible by the fact that methods are just wrappers around functions with an explicitly declared self. That dynamism is rarely used, but not *that* rarely, and is very useful when used. Implicit self would likely negate all that. Hmm. Got any examples sitting around? I'm curious as to what you can do with this. I'm like a kid with a new chemistry set - what happens if I mix a little of everything together?... ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
On Wed, Aug 31, 2011 at 7:47 PM, Chris Angelico ros...@gmail.com wrote: On Thu, Sep 1, 2011 at 10:48 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Python classes have a lot of dynamism made possible by the fact that methods are just wrappers around functions with an explicitly declared self. That dynamism is rarely used, but not *that* rarely, and is very useful when used. Implicit self would likely negate all that. Hmm. Got any examples sitting around? I'm curious as to what you can do with this. I'm like a kid with a new chemistry set - what happens if I mix a little of everything together?... First thing that comes to mind is calling a base class's implementation of a method: class X(Y): def __init__(self, value): Y.__init__(self) self.value = value -eric ChrisA -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do class methods always need 'self' as the first parameter?
In article 4e5ed670$0$29981$c3e8da3$54964...@news.astraweb.com Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Er, yes, just like I suggested in my opening paragraph, and as I answered following the bit you marked as snipped :) Oops, so you did (went back and re-read it). Must have gotten interrupted and lost track. :-) [A different hack would] requires a bit of implicit sneakiness in the compiler: an instance method magically creates a local variable named self that binds to the invisible first parameter, and a class method magically creates a local variable named cls that binds to the invisible first parameter, and so on. It would need more than a bit, because methods are just wrappers around functions. Well, depends on how the hack would be done. :-) For instance, the @decorator might turn on something that undoes or replaces the self parameter. That is, with ordinary class functions and methods: class HackyNotQuitePythonVersion: def ordinary(arg): self.arg = arg would compile to (approximately): class PythonVersion: def __mrap(self, *args, **kwargs): def ordinary(arg): self.arg = arg ordinary(*args, **kwargs) ordinary = __mrap (add the usual other manipulations to suit here, i.e., all the stuff for making introspection work right, i.e., @functools.wraps). @staticmethod would suppress the wrapper entirely, while @classmethod would change it to one that binds the cls argument. (Any function without some appropriate @whatever gets the Method Wrapper __mrap. @staticmethod tells the class builder not to add any wrapper, and @classmethod tells it to add the Class Wrapper __crap. [The name tells you what I think of the above code. :-) ]) (Note subtle ground for bugs here: if you then actually define a self parameter, it shadows the outer-scope one from the wrapper. So while I am not even proposing that anyone should do this in the first place, it has more downsides than mere implementation complexity.) Another way would be for the compiler to perform darkest black magic to determine whether the function was being called from inside a method or not. That would be complicated and fragile. Yes, even worse than my outlined implementation above, I think. classmethod and staticmethod are functions, not declarations. They are decorator functions, but to someone *reading the code* they are also declarations of sort. This is all I meant: they tell the (human) reader/programmer which secret arguments to expect. You can't assume that @classmethod is the only way to get a class method: the metaclass could do it, or you could inject one in from the outside. Yes, but that would all still work, as in this not-quite-Python (worsened-Python) language, whoever writes those metaclasses and other decorators would continue to do whatever icky stuff was required (e.g., __mrap and __crap above). It would mean yet more things for people to know about, but then, metaclasses and decorators *always* mean that: @hmm def spam(): return magic Is magic something supplied by the decorator? You have to look at the decorator to find out, as the rather horrid example I have attached shows. (Note: I am doing all this is python 2.x on the laptop. Using global, in @hmm, is evil, but it works. I did not bother trying to write a metaclass that inserts __mrap, etc., but I believe it can be done.) Python classes have a lot of dynamism made possible by the fact that methods are just wrappers around functions with an explicitly declared self. That dynamism is rarely used, but not *that* rarely, and is very useful when used. Implicit self would likely negate all that. I do not believe it would *negate* it, just *complicate* it. But that is not a good thing either. :-) - horrible example / test code below import functools def hmm(func): @functools.wraps(func) def wrapper(*args, **kwargs): global magic, rlevel try: save = magic, rlevel restore = True rlevel += 1 except NameError: restore = False rlevel = 1 magic = func.__name__ + and eggs ret = func(*args, **kwargs) if restore: magic, rlevel = save else: del magic, rlevel return ret return wrapper @hmm def ham(): if rlevel 2: print spam() return magic @hmm def spam(): return magic print ham() try: print magic except NameError: print 'name magic is not available here, as desired' try: print rlevel except NameError: print 'name rlevel is not available here, as desired' class X(object): def __mrap(self, *args, **kwargs): def xset(arg): self.arg = arg xset(*args, **kwargs) xset = __mrap def __mrap(self, *args, **kwargs): def show(): print self.arg show(*args, **kwargs) show = __mrap x =
