Pythonic and work

Work has been intersting. First the whole new environment and people to interact with. Second is the work itself which is a lot of python. So I'll rant on a little bit about it while I try to get the urge to figure out something more entertaining hopefully for this weekend.

I was left with a lot of code to "roll back" to an earlier version of a program that runs python script. Some clients get sick of updating you see and getting one of these clients caused the entire library of the person I was replacing to break. It seems he was sent to actually get trained from people who made the program we patch and make our own scripts for behind the scenes instead of fumbling through documentation.

Using some old cold snippets and newer code that works with a lot of guessing has lead to some finally functioning programs. Somewhat slow large and cumbersome programs but workings ones none the less. All this somewhat ugly and done as fast as I could work got me looking into efficiency and good writing style for python and I come across something called "pythonic".

Pythonic is deemed "what experienced python programers expect to see" which sounds snobish, but it seems under that surface is some good things. Though first lets show off a "pythonic" philosophy that's so used in development most programs in Idle will show it jsut by executing the line "import this". The little bit is as follows.

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

A lot of pythons implementation and development follows a lot of this if you look through it. The entire idea of white space indenting is defiantly for readability and some other things can easily be seen in there. Other things such as list comprehension and other advanced programing techniques you don't really discover till you look for them and those were the sort of things that were hitting me over the head. For the past two weeks I've learned a lot about programing in python and got more than a few tricks to use. Mostly called Idioms. While I feel it's bad style to link out of the website if you got a grasp of python heading over to here will show a good amount of them.

It also seems a lot of their techniques are a bit faster than my C/java learnings tend to get me to create. Hopefuly I'll put more of the idioms to use in teh future though for right now I'd settle for being able to import my own modules under the program I work with. You don't miss functions until you have to cut and paste while updating the same functions over and over again.