Inheritence is fun!

Imagine this view in python:

class MyFirstForm(formbase.PageForm): lots and lots of finicky code.

Now lets say we want to capture everything in that view, but give it a slightly different behavior. How about this?

class MySecondForm(formbase.SubPageForm,FeedbackForm): pass

So what does this do?

Well, in Python what this does is make the second class inherit the properties of a similar base class, then overwrite it with the properties of the first form. The order of precedence in inheritance in Python is very clear and straightforward. The result is a wonderful case of object oriented code reuse.

I believe Ruby does it in a very similar fashion.

Visit the Greater Lipsum Project at your own peril

Don't say that I did not warn you, but kf has added her Greater Lipsum project to Google Code.

Now that I've posted this link to an exploit of forbidden knowledge, I can hear the keening of the Deep Ones all the time. What once sounding like insane cries of the damned now is starting to sound all too sweet.

Genius will be rewarded

KF is a business analyst for NASA. She is smart. Too smart for her own good. For she has gained the arcane knowledge of the Python Programming Language and dared to write her own lipsum generator. One serving up snippets of the works of H.P Lovecraft. I give unto you the Cthulhu Lipsum Generator!

Or not.

I'm not going to be responsible for those who dare to use her tool.

Her mad, mad, mad genius will be reward. Just not by me!

:o

P.S. If she puts it up on google code I'll link to it and let you use your own judgement.

Phoenix

Don't forget, I work for the people who made this happen!

http://nasascience.nasa.gov/missions/phoenix
http://www.nasa.gov/mission_pages/phoenix/main/
http://apod.nasa.gov/apod/ap080525m.html

To Shell is to love Python

One thing I like about Python is the shell. Or if you have rights, the iPython shell. Combine that with PDB (Python Debugger) and you get quick, accurate insights into the behavior of snippets of code. You can tweak things to your heart's delight. I think list comprehension would not be as much fun as it is if python did not have a shell.

I think one of my future prerequisites for new languages (not that I'm looking) is that the language have a shell.

Apologies to Chris

Who is Chris and why does he get an apology?

Chris is a co-worker of mine. He's more than a co-worker, he saved my soul. About three years ago he introduced me to Python, SVN, Trac, and Plone. He also first pointed me at Pylons and Django. He has pointed me at open source alternatives. He fended for me with certain NASA functionaries. He is honest, visionary, brilliant, opinionated, creative, funny, witty, well-spoken, principled, and has helped me in a thousand ways. If he was the boasting type I would probably still be calling him my python mentor.

That is Chris.

So why the apology?

This past Friday afternoon another coworker was asked to give a certain relatively important someone (aka a VIP) a short bulleted list (5-6 items) of innovations on our big project to go onto that VIP's periodic personal review which was due the next day. Not to NASA. Not to anyone important. It was just the normal sort of crud that goes into self-reviews. The other coworker turned to me and suggested I provide the list.

And then I turned to Chris and asked him for some input. Chris refused for several good reasons:

• A short list did not do justice to our project.
• A longer list would require effort that would require approval. Approval from our manager who had left for the weekend.
  

At this point what I should have done is said, 'Nevermind, I'll just do it myself.' If he got pissed then things would have rolled over eventually and we would grumble/laugh about it over drinks at some point. However, instead I tried to convince Chris that this was no big deal and that we ought to spend five minutes getting it done.

See, cause I really respect Chris, I'm always looking for his approval on things. And sometimes thats the wrong thing to do. I should have stopped listening to him, told him definitively that I was going to do this, and done it. Instead I waffled, fighting my desire to get his approval and my knowledge that a battle over a five minute task was not a battle worth fighting.

I did some stuff in retrospect that looks stupid. The worst was that I wrote an email to my boss, sent it, then got Outlook to recall it. When I found that Chris had written one of his masterful detailed lists I didn't tell him that his effort, while exemplary, really complicated things for me.

You see, some battles are worth fighting. Some are not. I agree that the list I was asked to provide did not do our project justice, but I also recognize that this was NOT intended for general distribution. Provoking this fight wouldn't score a victory of any value, just make a VIP's job a little harder, and incur their ire. I have no problem with fighting good fights, but in my opinion this fight just wasn't one of those good fights.

A better fight would have been for documented processes, requirements software, nixing the cubes, collaborative software, and for work on new and exciting projects.

So late that night after 5-10 minutes of effort I put together a list and sent it to the VIP. Then I started to think about sending a note of explanation to Chris. I note I never sent. Why? General stupidity on my part. I was trying to figure out how to write it in a way that kept his approval. I procrastinated over the weekend, which really was not the thing to do.

Chris found out on Monday what I had done. From his perspective I'm a/an @#$%-#$@ for not only providing the list and for not being straight with him. I can't really say I can blame him. I knew the former was going to happen, the latter could have been avoided if I had been forthright from the start.

I'm not sure anything I write can make a difference at this point. Apologies are just words, and words are easy to say. Which is why if I'm going to say anything its going to be public and in a place associated with me.

My apologies Chris.

I love graphing

I don't mean charting (pie, bar, line, etc). I mean drawing edges and nodes and showing relations between objects of all sorts. That means between data objects, code objects, people, companies, and so much more. Its lots of fun and writing clean, extensible code to do it is a blast for me.

Mostly I work in graphviz using Python. I played with PyDot for a while but wasn't happy with it so I tend to write some base code to handle things in a way that ended up being duplicated by the GvGen project. Which is very nicely done.

However, there are limits to graphviz. Graphviz doesn't do animation or make 3-d images are two big items. However, its nice and light as a renderer which is very important especially for generating content for the web on the fly. Nevertheless I've done wonderful things like mapping out relations between 150 applications or reverse engineering ZODB content into UML.

So imagine my delight when I found Ubigraph this morning. It does 3-d graphs and animates things. I don't think it will replace Graphviz because it does different things. I haven't played with it yet but I will.

The problem with comparing Pylons to Django

...is that my experiences with Pylons are from nearly two years ago. My experiences with Django are ongoing. So any comparison I do will be completely unfair. But lets do a little anyway because there are some issues I want to raise.

ORM non-Issue
I don't have any issues here with either framework. At the time played with Pylons I think it used SQLObject. Now you can use SQLAlchemy. If you want, Pylons can also handle Python's DB-API if you want a bit of pain with your SQL. Django has its own ORM. Personally, I'm happy with any ORM to handle all the mundane tasks, and all three ORMs have good enough documentation to make working with them a snap. So ORM is a non-issue.

Routing non-Issue
Pylons routing of URLs to methods was easy. Django has an easy method too. I'm sure some folks might take issue with some of the finer points but I haven't ran into any killer issues myself. I think both let us specify things ending with slashes, or '.php' if we have a sense of humor. So routing is a non-issue.

Django Templates versus Myghty/Mako
The problem is my own lack of discipline. It can be so easy to start adding in more and more logic into your views. I would rather call python modules with python methods written in python then cook up fancy logic in a view-focused templating engine. Yet again and again I do the stupid, and mix my content with presentation. So I want a templating system that limits what I can do with it.

When I did Pylons the default templating system was Myghty, patterned after a Perl library called html::mason. I did not like Myghty. Since then, Pylons adopted Mako. The same things that made me not like Myghty appear to be in Mako. Too much power! I can mix my business logic code too easily with the view stuff.

I like Django templates because it has good, hard limits on what you can do. You aren't cooking up creative ways to do logic in views. You are just simply writing views. In return, it gives you a bunch of default utility methods/filters that do a bunch of repetitive work.

A common alternative with Django is Jinja templates. I think Jinja might give application developers Myghty/Mako like power. So I'm not very interested in Jinja.

Django versus Pylons Documentation
I like good on-line documentation. Its very hard to do, and Django has done a smashing job with tutorials and on-line books. Pylons has some really good stuff, and I know that they've improved, but they are still not there with Django.

Admin Interface
So I create an application and have a table with 5 status values. The application goes to production. Turns out I mispelled a status title and it needs to be fixed.

In Django I log in as an admin, go to the errant record, and fix it. To make that work I just added an internal class to the Status model.

In Pylons (and I might be wrong), I can't do this. I either have to log into my database directly, or write a snippet of code to correct the problem, or code in an administrative module myself.

Summary
This comparison was totally unfair. I'm skipping a lot of wonderful things about Pylons. Things like Pylon's unbelievable flexibility in choosing components, the rails-like webhelpers, and the collective smarts of the people who work on the project. Or its close friendship with the latest versions of Turbogears, which probably smashes the admin interface issue right out of the ballpark.

So, in conclusion I'll play it completely safe and say that Django and Pylons are both good stuff. I just prefer working with Django.