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
