Positronic Vibrations

Tuesday, September 29, 2009

Prototypes in Python

I'm in love with prototype-based languages, but there only a few to play with ECMAScript (Javascript) and Self. Since I'm learning Python, I thought it would be a good experiment to implement prototypes in Python. For one thing, I would get to learn some of the meta capabilities and other advanced features. A pure thought experiment just for learning and seeing how far I could push another paradigm onto Python. Here is what I came up with:

class Prototype(object):
    def __init__(self, *args):
        self._parents = []
        for each in args:
            self._parents.append(each)
        
    def clone(self, *args):
        return self.__class__(self, *args)
    
    def __getattr__(self, name):
        for each in self._parents:
            try:
                return getattr(each, name)
            except AttributeError:
                pass
        raise AttributeError(name)

The implementation is suprisingly simple: three methods!

The first is the initialize method for new instances. It takes a list of objects that we will use as the parents of our new object. Of course, by simply calling Prototype's constructor with no arguments, we get a clean object. I made the ability to have multiple inheritance simple because of Self.

The second method is the clone method and it simply calls the constructor for another object makes itself the first parent with the rest of the arguments becoming the other parents. Nothing to it!

The last method is the real meat. It only get called by the Python engine when an attribute fails to be looked up. All I do is call each parent and if one succeeds, it returns the answer. This is a depth first search of the parent hierarchy. Simple.

And that's all we need to implement prototypes in Python. Now, I just need to explain some practical uses of this in some later blog entries.

How do I know all of this works? Here's my tests:

import unittest
class Test(unittest.TestCase):

    def testSimple(self):
        parent = Prototype()
        child = parent.clone()
        
        parent.value = 0
        self.assertEquals(0, child.value)
        child.value = 1
        
        self.assertEquals(1, child.value)
        self.assertEquals(0, parent.value)
        
        self.failUnlessRaises(AttributeError, lambda:parent.unknown)
    
    def testMultipleParents(self):
        parent1 = Prototype()
        parent2 = Prototype()
        child = parent1.clone(parent2)
        
        parent2.value = 2
        self.failUnlessRaises(AttributeError, lambda:parent1.value)
        self.assertEquals(2, child.value)

If anyone sees anything wrong in my implementation or un-Pythonic let me know. I'm still learning, but I thought it would be cool to show my progress.

Labels: prototypes, Python

Comments

You can actually shorten your constructor down to self._parents = list(args).

By kesmit, at 9:28 AM
Welcome to the world of Python. You will like it here.

By MikeHoss, at 9:48 PM
You shouldn't copy objects so deeply. You have to make a class-like thing. You create a new object with a proto attribute. Then when an attribute is requested you find it in the local attributes. If it's not found you search in the proto, and so on until the proto is None. Your way you always copy the whole object, and it becomes heavy in memory terms.

By Luca Bruno aka Lethalman, at 3:43 AM
Thanks Kesmit and MikeHoss!

To Luca, Where am I copying deeply? The clone method creates a brand new object and it is not a copy. The parents attribute is the proto attribute you were talking of. The __getattr__ is only called when an attribute is not found and then it searches for it in the parents (and if they are Prototypes, then they will do the same.

How am I copying the entire object? I want to make sure I'm not doing something wrong.

By Blaine, at 6:14 AM

Sunday, September 13, 2009

Constraints in Python

With every language that I learn, I pay close attention to my work flow. I take note of anything that gets in the way of getting my task accomplished. In a perfect language, I should never have to worry about the language ever. A free flow of ideas should come out. Whenever I find myself totally immersed in a problem, I keep track of what made it so. Recently, the one feature that surprised me the most was Python's forced indention. At first I thought, how nice not to use curly brackets to denote scope, but what about that white space? But, I put my best foot forward and worked on some code. I must admit that I love it now! It makes code more readable by keeping the rules consistent (you have to be or your code will have bugs). Formatting my code is now one less worry I have. I am forced to indent as I go along. This constraint is liberating in the fact that it allows me concentrate on the problem at hand and is one less thing to worry about. No more worrying about if the curly braces go on the same line or not depending on local coding standards. It makes code easier to read across Python programmers. In fact, I have yet to meet a Python program that I could not understand easily from first glance which is a rare accomplishment in other languages.

I also love the constraint about one line lambdas. I thought it was going to drive me crazy, but I have embraced completely. It keeps your lambda functions short and sweet like they really should be. But, the best side effect is that if that lambda needs to grow, you simply move it out to a named function automatically making your code more readable. Excellent.

Both of the features that I just mentioned are merely constraints that take away thinking about the language and force you to write readable code. I always like and embrace the design decisions to constrain the coder to make more maintainable code. The less I have to think about the language, the more time I spend on the problem I am trying to solve and that's the way it should be. It just amazed me that sometimes I find them in the strangest of ways. I would have never thought that forced indention or one lined lambdas would bring me so much coding pleasure.

Labels: Python

Comments

I had kind of the same feeling you mention here. As Smalltalker, at first I didn't like the indentation, but when I have had to start coding python I discovered that it's useful.

But, I must say that anyway I believe Smalltalk is always a step ahead. Why? Because you have prettyprint. You can write your code in a faster way and get it automatically formated in a standard way.

But, also, I think it could be taken forward in this way: Suppose you don't like the prettyprint why of formatting. You can modify the IDE to show you the code prettyprintted in the way you most like, anytime, and save it in the standard formatting for your office standards, for example.

By tenuki, at 3:23 PM
I always use automatic formatting in any language I use. I thought it was cool that it is unneeded in Python. It's also nice that the formatting is the same from developer to developer, no more taste wars.

The more the language takes away mundane issues (formatting), the more time you have to think about your problem at hand which is the whole point of languages.

By Blaine, at 7:06 PM
Yes. Your point is clear!

By tenuki, at 8:21 PM
Glad to hear from another convert.

By Ron Smith, at 10:27 PM

Saturday, September 12, 2009

The Dead Year

This blog has been dead for a year and it's not been a lack of passion. I had some rather large life changing events to deal with. I have emerged stronger than ever before and I plan to start posting regularly here again. To let you know what to expect, I hope to do some new articles on my exploration of Python and Django. I've been enjoying my time with Python quite a bit. I also hope to spend some time digging into Google's V8 ECMAScript. It's time for me to kick this blog back into gear. Hold on!

Labels: misc

Comments

Good luck to you, Blaine. Have you stopped doing Smalltalk development altogether?

By jim, at 7:41 AM
Glad to see you're back.

By Ben, at 8:18 AM
awesome! Welcome back man!

By Matt Secoske, at 8:44 AM
Glad to hear you'll be writing again, and that you've come through the challenges you've faced this year.

By Eugene Wallingford, at 2:19 PM
Glad to hear you'll be writing again. I enjoy you stuff. I'm even more glad that you've survived your trials this year.

By Eugene Wallingford, at 2:19 PM
Glad to have you back. That which does not kill you makes you stronger!

By Sam Griffith Jr., at 9:58 PM