Re: Reasoning behind 'self' parameter in classes?
Robert Dailey wrote: Hi, I want to point out first of all that I'm not as familiar with Python as I should be, and for that reason I question a lot of things because I'm mainly a C++ programmer and I'm used to certain conveniences. Having said that... I've always been curious (more so than annoyed) as to why one must explicitly specify a self parameter for member functions in a class in Python. This seems very C like to me, since to do object oriented programming in C you must devote one parameter to the object itself. In a higher order language like Python, I would not have expected (and thus am rather surprised) that this pattern would apply. Is there any particular reason why 'self' parameters must be specified explicitly? I am curious to understand the philosophy and design behind this. In Python 3 will there be any plans to eliminate this syntactic artifact? As I said, it's not terribly annoying to me but it seems like more of a hack than anything else. I would feel a bit better if I didn't have to see it. I don't mean to start any syntax wars or anything, so I hope everyone will keep an open mind and simply explain the design, rather than defend it. I'm interested in only facts, and not opinions. This is an example of a response I'm looking for: The self parameter is required because the parser is a bit old and needs to know the exact object you're referencing This is _not_ an example of what I'm looking for: Specifying self is a great mysterious thing that we should never question. Do not question the language! The language is mighty! Don't bring C++ to Python! I appreciate the community's time. -- http://mail.python.org/mailman/listinfo/python-list There was a massive thread attack a sacred python cow that brought up a lot of reasons why this is the case. If you can ignore the flames, you'll find some good info there. But it might not be wise to bring it up again a week after it happened last time. -Matt -- http://mail.python.org/mailman/listinfo/python-list
Re: Reasoning behind 'self' parameter in classes?
Robert Dailey wrote: This is an example of a response I'm looking for: The self parameter is required because the parser is a bit old and needs to know the exact object you're referencing This is _not_ an example of what I'm looking for: Specifying self is a great mysterious thing that we should never question. Do not question the language! The language is mighty! Don't bring C++ to Python! Fredrik Lundh has written a very clear explanation of this at http://effbot.org/pyfaq/why-must-self-be-used-explicitly-in-method-definitions-and-calls.htm (or http://bit.ly/3EUiCf if you don't feel like stitching that URL back together...) -- http://mail.python.org/mailman/listinfo/python-list
Re: Reasoning behind 'self' parameter in classes?
Matthew Fitzgibbons wrote: Robert Dailey wrote: I've always been curious (more so than annoyed) as to why one must explicitly specify a self parameter for member functions in a class in Python. This seems very C like to me, since to do object oriented programming in C you must devote one parameter to the object itself. In a higher order language like Python, I would not have expected (and thus am rather surprised) that this pattern would apply. Is there any particular reason why 'self' parameters must be specified explicitly? I am curious to understand the philosophy and design behind this. Think about the implications of a language without real declarations and it will come to you. John Nagle Animats -- http://mail.python.org/mailman/listinfo/python-list
Re: Reasoning behind 'self' parameter in classes?
Brett g Porter: Fredrik Lundh has written a very clear explanation of this athttp://effbot.org/pyfaq/why-must-self-be-used-explicitly-in-method-de... Today lot of people know that Ruby exists, so such FAQ explanation must explain why Python doesn't use a shorter syntax like for example @foo to denote instance attributes (and maybe @@baz for the class attributes). Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
Re: Reasoning behind 'self' parameter in classes?
On Wed, Jul 30, 2008 at 1:03 PM, Brett g Porter [EMAIL PROTECTED] wrote: Robert Dailey wrote: This is an example of a response I'm looking for: The self parameter is required because the parser is a bit old and needs to know the exact object you're referencing This is _not_ an example of what I'm looking for: Specifying self is a great mysterious thing that we should never question. Do not question the language! The language is mighty! Don't bring C++ to Python! Fredrik Lundh has written a very clear explanation of this at http://effbot.org/pyfaq/why-must-self-be-used-explicitly-in-method-definitions-and-calls.htm (or http://bit.ly/3EUiCf if you don't feel like stitching that URL back together...) This sounds like an article of opinion. He's not really given any reasons other than Well, it makes this easier or look better. True that declarations are the determining factor in C/C++, however I was thinking of more or less an implied 'self'. For example: # Consider this normal syntax: class MyFoo: def DoFoo( self ): self._member = 6 # Elimintating 'self' in the parameter list should still work as far as the # interpreter is concerned, since 'self' in this case now acts like 'this' # in C++. The below code should be equivalent. class MyFoo: def DoFoo(): self._member = 6 Given the code samples above, is there any technical reason why this cannot be done? Thanks for the input guys, and thanks more over for keeping this easy-going. -- http://mail.python.org/mailman/listinfo/python-list
Re: Reasoning behind 'self' parameter in classes?
On Wed, Jul 30, 2008 at 12:27 PM, Robert Dailey [EMAIL PROTECTED] wrote: Given the code samples above, is there any technical reason why this cannot be done? Thanks for the input guys, and thanks more over for keeping this easy-going. -- http://mail.python.org/mailman/listinfo/python-list Well, the linked thread gives many reasons, but as mentioned it is a flamewar thread. Philosophically python is not an object oriented language per say, it has an object system, a not bolted on one I might add, but it doesn't force developers to use that methodology. You can be functional or procedural if you'd rather. Following this philosophy, when methods were designed, they were merely functions that got passed an instance as the first argument. The parser followed this design choice. As far as I understand it, the underlying method object is not different from a function argument, thus it cannot have any magic arguments built in. The only magic involved is the fact that the object, when calling a method, will pass its instance as the first argument. I don't believe there is any chance of this changing in python 3, python 4 is anyone's guess... This does allow some good things that come for free, like adding methods later, or changing functions into methods or methods into functions. If you start out developing a class, but feel a class is too bulky, you can delete the class line, dedent the methods, and have a set of functions instead for free. Or, if you have functions that are set up to take instances as their first argument already, you can bundle them up into a class very easily. If by hack you mean using features already available in the language to accomplish things, that kind of is what it is, and that's kind of what python is about. New syntax for a new feature is uncommon, but it happens. New syntax that breaks old code is very uncommon, and is only now coming out in python 3. And the biggest change in python 3 is to eliminate added syntax, such as print being a statement, and make the code reuse more python features rather than have every feature exist as an island. Print being a function, for instance, lets you use the same syntax for it that you use for other functions, making everything clearer and more unified. A common thing programmers might do when upgrading their code is to turn print statements into better logging functions - if print was a function in the first place this would be an easier task. Eliminating self doesn't accomplish much, and changes of this nature just don't get done without a good reason. It takes away something that might be annoying, but doesn't add anything. The benefits of changing have to be significant for a code change to break the existing syntax. Many people are upset even about some of the changes in python 3, that the benefits don't outweight the cost of change, and most of those changes are less damaging than playing around with the self businss would be :) So no, self not a mysterious thing that we should never question. Self is an understood thing that has been questioned very often (weekly, monthly) for many many years - there are not enough good reasons to bother with changing it, and there enough good reasons for it that it's best to keep it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Reasoning behind 'self' parameter in classes?
On Wed, Jul 30, 2008 at 2:46 PM, Matthew Fitzgibbons [EMAIL PROTECTED]wrote: Robert Dailey wrote: On Wed, Jul 30, 2008 at 1:03 PM, Brett g Porter [EMAIL PROTECTED]mailto: [EMAIL PROTECTED] wrote: Robert Dailey wrote: This is an example of a response I'm looking for: The self parameter is required because the parser is a bit old and needs to know the exact object you're referencing This is _not_ an example of what I'm looking for: Specifying self is a great mysterious thing that we should never question. Do not question the language! The language is mighty! Don't bring C++ to Python! Fredrik Lundh has written a very clear explanation of this at http://effbot.org/pyfaq/why-must-self-be-used-explicitly-in-method-definitions-and-calls.htm (or http://bit.ly/3EUiCf if you don't feel like stitching that URL back together...) This sounds like an article of opinion. He's not really given any reasons other than Well, it makes this easier or look better. True that declarations are the determining factor in C/C++, however I was thinking of more or less an implied 'self'. For example: # Consider this normal syntax: class MyFoo: def DoFoo( self ): self._member = 6 # Elimintating 'self' in the parameter list should still work as far as the # interpreter is concerned, since 'self' in this case now acts like 'this' # in C++. The below code should be equivalent. class MyFoo: def DoFoo(): self._member = 6 Given the code samples above, is there any technical reason why this cannot be done? Thanks for the input guys, and thanks more over for keeping this easy-going. -- http://mail.python.org/mailman/listinfo/python-list Your first example could be written: class MyFoo(object): def do_foo(the_foo_instance): the_foo_instance._member = 6 'self' is not special the way 'this' is in C++. It's just a name for an object reference just like any other name for any other object reference. -Matt Yes, I realize that it can have any name. But this does not change its purpose. It was simply an example. In the second code snippet I gave you, 'self' would become a reserved word and a user would have to use that to reference the object from which the function was called. -- http://mail.python.org/mailman/listinfo/python-list
Re: Reasoning behind 'self' parameter in classes?
On Wed, Jul 30, 2008 at 2:48 PM, Patrick Mullen [EMAIL PROTECTED]wrote: Well, the linked thread gives many reasons, but as mentioned it is a flamewar thread. Philosophically python is not an object oriented language per say, it has an object system, a not bolted on one I might add, but it doesn't force developers to use that methodology. You can be functional or procedural if you'd rather. Following this philosophy, when methods were designed, they were merely functions that got passed an instance as the first argument. The parser followed this design choice. As far as I understand it, the underlying method object is not different from a function argument, thus it cannot have any magic arguments built in. The only magic involved is the fact that the object, when calling a method, will pass its instance as the first argument. I don't believe there is any chance of this changing in python 3, python 4 is anyone's guess... This does allow some good things that come for free, like adding methods later, or changing functions into methods or methods into functions. If you start out developing a class, but feel a class is too bulky, you can delete the class line, dedent the methods, and have a set of functions instead for free. Or, if you have functions that are set up to take instances as their first argument already, you can bundle them up into a class very easily. If by hack you mean using features already available in the language to accomplish things, that kind of is what it is, and that's kind of what python is about. New syntax for a new feature is uncommon, but it happens. New syntax that breaks old code is very uncommon, and is only now coming out in python 3. And the biggest change in python 3 is to eliminate added syntax, such as print being a statement, and make the code reuse more python features rather than have every feature exist as an island. Print being a function, for instance, lets you use the same syntax for it that you use for other functions, making everything clearer and more unified. A common thing programmers might do when upgrading their code is to turn print statements into better logging functions - if print was a function in the first place this would be an easier task. Eliminating self doesn't accomplish much, and changes of this nature just don't get done without a good reason. It takes away something that might be annoying, but doesn't add anything. The benefits of changing have to be significant for a code change to break the existing syntax. Many people are upset even about some of the changes in python 3, that the benefits don't outweight the cost of change, and most of those changes are less damaging than playing around with the self businss would be :) So no, self not a mysterious thing that we should never question. Self is an understood thing that has been questioned very often (weekly, monthly) for many many years - there are not enough good reasons to bother with changing it, and there enough good reasons for it that it's best to keep it. This is quite possibly the best explanation yet. Thank you very much for this. You bring much insight into the feature. You see, a lot of people I've worked with have complained about the 'self' parameter. While this has never bothered me personally, other people find it a flaw in the language. I often argue with my coworkers that Python is better than Ruby (This is of course opinionated and biased), but sometimes I find I cannot defend python when I need to, and in the argument of 'self' I find that to be one of those situations. Anyway, I appreciate everyone taking the time to explain this to me. I'm sure you guys are at the point of copy/paste of your responses on these topics :) They're far too frequent it seems. In any case, I still appreciate the responses. This topic can die now, I would hate to see it continue and another flame war to start. -- http://mail.python.org/mailman/listinfo/python-list
