multiple values for keyword argument

[Patty]

Well - this is all timely email.  I just spent the day configuring my HP mini netbook running Windows 7 with all the right software based on recomendations from folks on this list, from the Python Tutor list and an email group of former colleagues where I spelled out exactly all the programming languages and stuff I ideally wanted.  It has been very enlightening and actually not so difficult!  Asking pays off!  And I made a few realizations - I had some misperceptions about some software packages and -- I had been thinking about this 'self' business since yesterday.  And you and Ethan and Ben Finney from yesterday (the last email msg I read last night, might know) are right -- I was being stubborn and wanting to do things *my* way and I was telling myself that when it comes time to do this for a future employer, well I will just change my code in the appropriate places to 'self' and will start using 'self' when I start working for them.  And a little thought  in the back of my head ... I wonder if the employer would be a little annoyed by that  :) 

OK - I need my hand slapped sometimes and I see that you all are trying to prevent me from developing a bad habit.  A few comments below:


"Steven D'Aprano" <steve+comp.lang.python at pearwood.info> wrote in message news:4d453127$0$29965$c3e8da3$5496439d at news.astraweb.com...
> On Sat, 29 Jan 2011 10:39:49 -0800, patty wrote:
> 
>> I am glad you said this.  I have been avoiding understanding this
>> 'self', just accepting it :}  For the time being, since my programs I am
>> creating are for my own use, I think I will make my own names up, that
>> are descriptive to me as the programmer, it's all going to be
>> interpreted anyway.  And the other email equating to C's argv, etc. -
>> now I get it.
> 
> 
> That's a shame, because `self` is actually very simple once you 
> understand the basic principles of object-oriented programming.
> 
> What names would you choose? Unless you're writing descriptors, or using 
> class methods, both of which should be considered advanced usage (highly 
> advanced for descriptors, moderately so for class methods), it's not like 
> every method needs a different descriptive first argument. In English, 
> "self", "this", "me" or "instance" would be good names. What else would 
> you use?

That is the thing, I can get quite creative.  I envisioned myself giving it a name something like 'instancecalledfrommain'  probably scrunched up to 'instfrmmain'
Weird descriptive names like that.  I keep thinking of it as a variable, so I keep thinking of what it is used for underlying its name.  Back to the I-can-do-anything-I-want
mindset.  

I have saved the messages in this thread and other ones from the last month or so about 'self' so I think I will gather them together and read them more carefully including your very good explanations below.


> 
> 
> The idea of method syntax is that you start with an instance of some 
> class:
> 
> mystring = "hello world"  # an instance of the str class
> 
> In procedural languages like C or Pascal, you would call a function and 
> give the string as an argument. Python supports this programming model, 
> and uses it for built-ins like len:
> 
> len(mystring)
> => returns 11
> 
> 

And I am more comfortable in the C and Pascal worlds as a base so I see why I go this direction.  



> Object oriented programming uses a different syntax. Instead of 
> 
> function(instance)
> 
> as above, we take the instance argument outside the brackets. For example:
> 
> mystring.upper()  # instead of upper(mystring)
> => returns "HELLO WORLD"
> 
> If there are any extra arguments needed, they go inside the brackets as 
> normal.
> 
> So far, this is just a change of syntax. It's like saying "The cat of my 
> brother's" vs. "my brother's cat" -- the meaning is the same, but the 
> syntax differs. 

And I am a linguist so now you are Really talking ;)



The real advantages of object oriented programming and 
> methods come elsewhere (e.g. encapsulation and inheritance).
> 
>    [Aside: when I was learning this, the hardest part I found was
>    remembering which things were functions, and which were methods. 
>    I kept writing (wrongly!) things like:
> 
>    "hello world".len()
>    upper("hello world")
> 
>    Unfortunately there is no easy way to recognise what will be a
>    function like len, and which are methods like upper. That will 
>    come with experience.

Oh!  I do this!  I seem to use this syntax interchangably.  I really need to memorize this carefully.


> 
> Back to function/procedural syntax versus object oriented syntax... 
> 
> One difference, though, is when you write a method definition. Because 
> the method you write starts off life as an ordinary function, you need to 
> write it *as if* it were a function you call like len() above. Here's how 
> you might write a method in a class:
> 
> class MyClass:
>    def method(self, extra):
>        pass
> 
> When you then call the method:
> 
> instance = MyClass()
> instance.method("something extra")
> 
> Python automatically changes the syntax for you, and passes two arguments 
> to the function as if you did this:
> 
> # pseudo-code
> set self = instance
> set extra = "something extra
> extract "method" from MyClass
> call method(self, extra)
> 
> We call the first argument something like "self" because it will ALWAYS 
> be the instance itself. Unlike a regular function, which can have 
> anything passed as the first argument, and therefore you should give it a 
> descriptive name, the method's first argument is provided automatically 
> for you and will always be the instance you started with.
> 
> 
> 
> I hope this helps.


Immensely
> 
> 
> 
> 
> -- 
> Steven
> -- 
> http://mail.python.org/mailman/listinfo/python-list
> 
>

Wow!  Thanks so much!    

Patty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20110130/8083bcae/attachment.html>