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.