Re: Python, Possibly OO, Terminology Question

  • From: David Tseng <davidct1209@xxxxxxxxx>
  • To: programmingblind@xxxxxxxxxxxxx
  • Date: Wed, 27 Jul 2011 14:42:25 -0700

For the purists out there, classes, functions, methods, procedures,
etc are all sort of related.  You can think of a class as a function
in python with some setup/teardown facilities, a closure, and a symbol
table mapping it's instance variables/functions.  I don't think any
language shows this better than javascript, but python comes pretty
close.

But, I think Jamal's right Jim, you should just dive in and see how
things behave in practice and stop letting me and others confuse you
:).

On 7/27/11, Q <q@xxxxxxxxxxxxxxxxxx> wrote:
> Okay. First, everything is an object as you mentioned. This is
> somewhat-important.
> Now, functions vs. methods.
> Generally in Python function means standalone callable. When I say
> callable, I'm referring to an object which has a __call__ method.  So
> when it comes down to it, functions are simply objects that define
> __call__. But of course, we generally don't create these function
> objects manually. That's just what happens when the interpreter reads in
> a def block.
> So, a function is a regular callable that does not take an instance as
> its first argument.
> def test():
>   print "hello, world!"
>
> While you could attach these types of functions to a class:
> class Tester(object):
>   pass
>
> Tester.test = test
>
> note what happens when you instantiate that class and try to use them:
> t=Tester()
> t.test()
> TypeError: test() takes no arguments (1 given)
> Because Python tries to pass the class instance in as the first argument
> to that function, and it takes none.
> Now, there's absolutely no reason you couldn't do something like:
> def other_test(self):
>   print "Hi there!"
>
> and attach other_test to Tester.
> And this would actually work just fine. It wouldn't be a true method
> object, which has a couple of other attributes on it (try dir on a
> function object and a method object for comparison)
> Now, you mentioned static methods. How we create these is with the
> staticmethod decorator.
> Observe:
>
> class SomeClassWithStaticMethods(object):
>
>   @staticmethod
>   def something_inside_the_class_namespace():
>    return "I was called!"
>
> You can call this static method on any class object or instance. So you
> could go
>
> SomeClassWithStaticMethods.something_inside_the_class_namespace()
> or
> c = SomeClassWithStaticMethods()
> c.something_inside_the_class_namespace()
>
> but this is rarely-needed, generally better is putting a regular
> function inside the class's module. This would only be required if you
> explicitly want to have the function inside the class namespace, I.E. a
> module with several unrelated classes.
> Then, we have class methods, marked with the @classmethod decorator.
> These are extremely-useful. They operate on class objects instead of
> instance objects.
>
> class Something(object):
>
>   @classmethod
>   def do_funky_things_to_the_class(cls):
>    #You could do all kinds of hackery in here on the class object before
> its already instantiated or whatever. cls contains the class object, and
> it's conventional to use cls in this case where self is for instance
> methods.
>    cls.some_attribute = 1 #all instances of this class will have
> some_attribute set to 1 if you call this
>
> I hope this untangles things a little. If you don't understand anything
> feel free to ask, but do do a lot of exploration with dir. also check
> out the inspect module to let you poke around at the internals and see
> what's going on a bit under the covers.
> And if I'm mistaken about anything here, someone on list please-do
> correct me as this is all stuff I've derived from usage.
>
>       Q
>
>
>
>
>
> On 7/27/2011 4:07 PM, Jamal Mazrui wrote:
>> Yes, I think a function at the module level in Python is like a static
>> method of that module.  The module, moreover, is like a singleton object.
>>
>> Although these nuances can be interesting to discuss, let me encourage
>> folks not to get hung up on terminology, thinking that one cannot code
>> productively until certain theory or terminology is mastered.  I say
>> try to understand as much theory as one can at the time, but then set
>> aside a solid grasp of some aspects for now if they seems elusive.
>>
>> I think that learning is usually best achieved through an iterative
>> process that involves both learning and applying ideas.  If one
>> postpones actual application, there is only so far that one's
>> understanding can go.  On the other hand, after experiencing the
>> results of applied understanding, one can try to learn more, apply it
>> in code, debug, regroup, etc.
>>
>> Jamal
>>
>> On 7/27/2011 3:45 PM, Homme, James wrote:
>>> Hi,
>>> Forgot to copy the list. This sounds like static methods in other
>>> languages. Is that anywhere in the universe?
>>>
>>> Jim
>>>
>>> -----Original Message-----
>>> From: David Tseng [mailto:davidct1209@xxxxxxxxx]
>>> Sent: Wednesday, July 27, 2011 3:40 PM
>>> To: programmingblind@xxxxxxxxxxxxx
>>> Cc: Homme, James
>>> Subject: Re: Python, Possibly OO, Terminology Question
>>>
>>> With respect to python's innate "object orientedness" where
>>> everything's an object, you can think of functions and methods as
>>> binding or associated with other objects.  A function or method that's
>>> "associated" with a class object, takes the class object as its first
>>> parameter as you stated.  However, you can just as easily bind a
>>> function or method to a class without that first "self" parameter.
>>> The distinction lies in what the function or method is bound to.  In
>>> the former, the function/method binds to an instance of that class
>>> while the latter binds to the class itself.
>>>
>>> For example,
>>> class foo:
>>>    def instance(self):
>>>      pass
>>>
>>>    def non_instance():
>>>      pass
>>>
>>> I'd encourage you to not take any of our words for it and try it out
>>> yourself.  Try typing the follwing into an interpreter.
>>>>>> foo.non_instance
>>>>>> foo
>>>>>> foo.instance
>>>>>> f = foo()
>>>>>> f.non_instance
>>>>>> f.instance
>>>
>>>
>>>
>>> On 7/27/11, Jamal Mazrui<empower@xxxxxxxxx>  wrote:
>>>> I think the terms function, method, procedure, subroutine, or code
>>>> block
>>>> are generally synonymous.  They refer to a programming construct that
>>>> receives 0 or more parameters, executes code with those parameters as
>>>> data, and then returns 0 or more result values.
>>>>
>>>> A particular term may be used to emphasize an aspect of the context
>>>> under discussion.  For example, a method implies being an aspect of an
>>>> object.  A subroutine implies that there is no meaningful return value.
>>>>    A code block implies an in-line definition with access to
>>>> surrounding
>>>> variables.
>>>>
>>>> In general, however, I think there are not fine distinctions among
>>>> these
>>>> terms.
>>>>
>>>> Jamal
>>>>
>>>> On 7/27/2011 11:14 AM, Homme, James wrote:
>>>>> Hi,
>>>>>
>>>>> I'm right at the point where I'm concerned about learning this the
>>>>> wrong
>>>>> way, so I'm asking now before it's cemented into my head. Is it
>>>>> appropriate to use the term function and the term method
>>>>> interchangeably? If so, why? If not, why not? I realize that in
>>>>> Python,
>>>>> when you have methods in the definition of a class, they always have
>>>>> self as the first argument, so that helps you realize that you are
>>>>> looking at a method. I also know that if you make a program that
>>>>> has no
>>>>> classes in it, that you can use functions, and they don't look like
>>>>> they
>>>>> are attached to a class, but one of the books I was looking at says
>>>>> that
>>>>> everything in Python is an object, even if the code doesn't look like
>>>>> that, but I'm trying to avoid dragging that into this discussion to
>>>>> possibly artificially keep concepts separate in order to learn them.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Jim
>>>>>
>>>>> Jim Homme,
>>>>>
>>>>> Usability Services,
>>>>>
>>>>> Phone: 412-544-1810.
>>>>>
>>>>>
>>>>> This e-mail and any attachments to it are confidential and are
>>>>> intended
>>>>> solely for use of the individual or entity to whom they are addressed.
>>>>> If you have received this e-mail in error, please notify the sender
>>>>> immediately and then delete it. If you are not the intended recipient,
>>>>> you must not keep, use, disclose, copy or distribute this e-mail
>>>>> without
>>>>> the author's prior permission. The views expressed in this e-mail
>>>>> message do not necessarily represent the views of Highmark Inc., its
>>>>> subsidiaries, or affiliates.
>>>> __________
>>>> View the list's information and change your settings at
>>>> //www.freelists.org/list/programmingblind
>>>>
>>>>
>>> __________
>>> View the list's information and change your settings at
>>> //www.freelists.org/list/programmingblind
>>>
>>>
>> __________
>> View the list's information and change your settings at
>> //www.freelists.org/list/programmingblind
>>
>
> __________
> View the list's information and change your settings at
> //www.freelists.org/list/programmingblind
>
>
__________
View the list's information and change your settings at 
//www.freelists.org/list/programmingblind

Other related posts:

  1. Home
  2. programmingblind
  3. Archive
  4. 07-2011