Python Tips ahoy!

On the eve of Talk Like a Pirate Day, I am announcing a new personal project. A little site I'm going to call pytips, Python Tips, Yellow Monkey Land, or maybe something else. Its going to serve up recipes and tips for Python, and eventually other languages as well.

So why am I doing this?

Four reasons:

1. I think the Python community could be well served by such a site.
2. I want to practice in another framework besides Zope and Plone.
3. I need to keep my relational database skills from getting rusty.
4. Sounds like fun!

I'm going to do this in Pylons. I thought about Django, and maybe I'll make a port of it at some point. Shouldn't be too hard, right?

Lambdas no more

When I was first learning Python I loved it all. It was a breath of fresh air. So easy, so powerful, and so uplifting. Python solved so many problems on a project I was doing that we switched from Java to Python because work I anticipated would take me 45 days in Java I managed to do in 90 minutes of Python. And this was my first real Python effort!

So everything was great, right?

Wrong.

Lambdas just plain escaped me. Experience in Java, Perl, PHP, Foxpro and ColdFusion left me unprepared for them. Took me ages to grok it. Finally after several weeks of tooling around with them, it clicked one marvelous day.

For a while I had happy fun with Lambdas. They were so cute. I could minimize my code a bit and could hang with awesome Pythonistas and share quips with Lisp programmers. Not that I knew any Lisp programmers, but if I did know them then I could talk about Lambdas too.

However, I quickly found myself resorting back to the 'standard' Python function/method way of doing things. In a nutshell, I found it much easier to read my code. Comments were much more clear. And the time it took to write out a couple extra lines of code wasn't all that bad.

Look, I'm really lazy, and I hate writing extra lines of code. Yet I think in the long run avoiding lambdas is worth it. Sometimes concise != good.

TurboGears merges with Pylons

I'm not an expert on either. In 2006 I spent about 4 or 5 weeks working with Pylons. A couple months later, I spent a couple weeks playing with TurboGears. Both were very interesting. I really tried to like Pylons but hated the Myghty which was what you had to play with via views. TurboGears back end wasn't as much fun as Pylons, but the front end used Kid as the template language for views.

That said, both frameworks really embodied things I like. They employed NIH and DRY all over the place with a vengeance. Sure, Django is a bit 'hip', but nix the scaffolding and all you have is Yet-Another-*SP-Template-Language combined with non-Pythonisms in a not-quite-RoR framework.

Well, once the Pylons and TurboGears marriage happens, Python's choice of quality frameworks will be down by one, but in a good way. Pylons will do the backend and you can load in TurboGears to be the front end. And with use of Genshi as the template attribute language. Yeah, Genshi isn't TAL, but it isn't that far off.

Links of interest:
http://compoundthinking.com/blog/index.php/2007/06/27/turbogears-11-and-beyond/
http://www.blueskyonmars.com/2007/06/27/turbogears-2-a-reinvention-and-back-to-its-roots/

Psuedo Code to Real Code

We always say it about Python, that our hand scratch code often becomes real code. That what other people sue to map out their thought processes is what we code in.

Well, over last weekend I was coding away on a personal project and typed in 150 lines of code. When I started to debug, I found I was done.

Not bad.

Playing with Catalog brains

So after a month of doing a lot of work with Plone content type modules, references, relations, catalog searches and teaching graphic designers basic TAL concepts, I've picked up some interesting habits.

First off, brains are better than tuples. And unlike in my previous post
, I now now that to get a full object off a brain you can just do something like this: [div repeat="item itemBrain/getObject"][/div].

I also ran into problems with objects that are related to objects with are related to objects which are related to objects. How do you find them and make sure you don't have duplicates and all of them are published? Well, I wrote a method to handle that. You run it on the context and give a list of the necessary default accessors. Maybe the Relation product has something for it already, and people will make fun of me. Or maybe not...

Anyway, Plone isn't just fun, its productive. I can't wait for our project to hit the real world.

A thought on methods in Plone

Note: Because of the limitations of blogger, I am replacing the '<' and '>' in XHTML statements with '[' and ']'.

We just did a sprint on our big project at work. My first step was to create a bunch of methods in the content types that would traverse between items via the reference catalog (yes Virginia, we are using the Relations product along with Association Classes get ArchGenXML).

Our first thought was to return a tuple of the title, description, and url of the referred item. Well, that turned out to be annoying because:

[div content="python:item[1]"]

is not as much fun as:

[div content="item/description"]

Also, for the graphic designers, having them start doing 'python:' everywhere just seemed like fighting a battle we didn't need to fight.

Then we decided to return a dictionary containing title, url, and description. And in some cases, acronym, image, and more. Now we have:

[div content="item/description"]

Hooray! Except that there are about 10+ and growing examples now of times when we missed something that needed to be returned.

So it hit me, why not just return the darn catalog brain? Sure, reference_catalog doesn't return a usable URL (you have to strip off the /at_reference/md5_hash), but I've already written an often reused python script that does this called cleanUrl. If we went this method, we get:

[div content="itemBrain/description"]

And if we hit another snag where we need to also return field x, y, and z, we have them do this:

[div define="item python:itemBrain.getObject()" content="item/funnyQuote"]

Plone Introspection

So you have a Plone content type with some fields. What are the properties of that content type? Well, you can look it up by finding in your file system the product that content type comes from, then examining the schema and finding out your information. Of course, if the product extends another product, then you have to look up that other product.

Bleah.

Introspection is what we really want. Python has it in spades. On pretty much any object in Python I can wrap it in dir() or help(), or check the __dict__ attribute. But you can't do this easily in Plone. Cooking up a universal instrospection view is something that ought to be done for my CMS of choice. I know there are lots of various barely documented utility methods I can find. I can wrap it up in a product and just use it by having a special introspection view that lays out some pretty HTML.

Sigh.

My coworker Reed pointed out that Zope 3, and the Five stuff in Zope 2 uses Interfaces that give some neat tricks you can do for introspection. I think I'll give that method a try. I think thats the right way to go because:

1. The Zope 3 specification handles introspection much more gracefully than Zope 2. And the methods for doing it seem better documented.
2. The technology is going that way anyhow.