Unification of Methods and Functions

[James Moughan]

< The concept of using a
> global variable __self__ is no surprise at all.  The only thing new in
> a class, compared to a module, is the instance variables, and they can
> be explained in one paragraph.  All methods look just like normal
> functions.  There is no need to explain "static methods" or any other
> form of method.  In fact, I use the term "function" rather than
> "method" to emphasize the similarity.
> 
> I'm especially interested in feedback from users who are now learning
> or have recently learned Python.  

I'd fit there - I've been learning Pyhton for a few weeks, though it's
now my main language.

The first time I saw the 'self' syntax in Python I recoiled slightly,
I'll admit, and I took, oooh,  a few tens of minutes to get used to
including it.  But then I've been programming in Java since 'the
beginning' so loosing the long habits from that may have slowed me
down. :)

IMO the current syntax is very, very clear and makes it *easier* to
understand OOP than any other syntax which I've seen.  If you
understand functions then you understand arguments; it's obvious how
that function would work if it weren't bound to a class, and it's a
simple leap to see the effects of placing a function into a class.

Also, it illuminates your programming in other languages.  Once I saw
the Pythonic methods, it immediately occured to me how to do OOP in a
non-OOP language like C.

Overall IMO this particular syntax is one of the things which makes
Python ideal for teaching OOP.  It's definitely better than waffling
about global variables which change depending on where you are in the
code.  I think if I heard that from a lecturer then I'd switch off
like a light.

>I already know these changes seem
> trivial to many experts.  I've also heard plenty from the people who
> think Python is so complex that we need to start a whole new language
> ( www.prothon.org ).  

I thought that was just some guy who thought it was too complex for
his compiler? :)

Python is a very deep language, but the complexity hits you so late,
and it's so comprehensible in terms of what's gone before that there's
no pain involved.  ( esp. contrasted with something like C++ where I
had to set up rigorous empirical tests to work out what the heck the
basic structures of the laguage were doing...)

Just MHO.

Jam

>I'm looking for a middle ground.  I believe it
> is possible to adopt what is good about Prothon, and not lose ten
> years of software and community development.
> 
> ======= Syntax Examples =============
> 
> ## Proposed Syntax:
> class Cat(Feline):
>     numCats = 0
>     def __init__( n = "unknown", s = "Meow" ):
>         Feline.__init__()
>         Cat.numCats += 1
>         .name  = n           # Set instance variables.
>         .sound = s
>     def show():              # Define a "static method".
>         Feline.show()
>         print "    Cats:", Cat.numCats
>     def talk():
>         print "My name is ...", .name
>         print "I am a %s from %s" % (.genus, .home)
>         Mammal.talk()      # Call an unbound function.
>         print __self__     ### Diagnostic check.
>       
> cat1 = Cat()            # Create instance.
> bf = cat1.talk          # Make a bound function.
> 
> 
> ## Equivalent Python:
> class Cat(Feline):
>     numCats = 0
>     def __init__(self, n = "unknown", s = "Meow" ):
>         Feline.__init__(self)
>         Cat.numCats += 1
>         self.name  = n
>         self.sound = s
>     def show():
>         Feline.show()
>         print "    Cats:", Cat.numCats
>     show = staticmethod(show)
>     def talk(self):
>         print "My name is ...", self.name
>         print "I am a %s from %s" % (self.genus, self.home)
>         Mammal.talk(self)
>         print self
> 
> cat1 = Cat()            # Create instance.
> bf = cat1.talk          # Make a bound function.
> 
> ========= End of Examples =======
> 
> Thanks for your help.
> 
> -- Dave