The most important thing about Python is that it is Pythonic.

I recently spammed my friends and co-workers with a success story and commented about how Python could be the salvation of a certain project with a particularly gnarled PHP based front end.

I was cautioned by a wise and pragmatistic friend:

Why not suggest Lisp?
http://www.paulgraham.com/avg.html

Latching on to a single language / platform / religion does not guarantee success or salvation.

I appreciate the good advice, but I don't honestly believe that Python is a magical panacea. In fact I don't want to latch on to Python as a single language or platform. Python has been described as "the ultimate glue language" in that it is well suited to tie various other languages and platforms together. What I do want is to explore Python and convince as many people as I can (who I need or want to work with) that Python is currently the best candidate for the default language to use when implementing solutions to the problems we need to solve.

Lisp is the language which forced me to learn a new way of thinking about representing a problem's solution in code and I am a better programmer for it. It introduced me to the concepts of Functional Programming and non-imperative languages.

• Imperative Programming describes an algorithm in terms of how a processor will execute it. Processor friendly.
  
• Functional Programming describes an algorithm in terms of the mathematical relationship between the problem and the solution. Problem friendly.
  
• Declarative Programming describes an algorithm in terms of logical assertions and rules. Human friendly.
  

Lisp is a very very powerful language. It is probably the most prolific implementation of a Functional language. Learning Lisp also made me realize just how powerful a fully dynamic language could be. I've come to think of Lisp as perhaps the most powerful language.

All languages are equally powerful in the sense of being Turing equivalent, but that's not the sense of the word programmers care about. (No one wants to program a Turing machine.) The kind of power programmers care about may not be formally definable, but one way to explain it would be to say that it refers to features you could only get in the less powerful language by writing an interpreter for the more powerful language in it

--Paul Graham http://www.paulgraham.com/avg.html

Ok, so what? Any dynamic language meets this definition power. Perl, Ruby, Python, maybe even PHP (just to list a few of the popular kids). What makes one any more desirable than the others? Religion?

Yes, religion. I'm using a particularly specific definition of religion and I'm using it loosely:

Religion: The collective customs and traditions of a body of people that have formed an organization or an institution to pursue the study of a specific teaching or belief.

Perl has a underlying philosophy: "There's more than one way to do it" (Which Ruby has adopted).

PHP's underlying philosophy is less of a philosophy and more of an excuse:

PHP is not about purity in CS principles or architecture, it is about solving the ugly web problem with an admittedly ugly, but extremely convenient solution.

--Rasmus Lerdorf (the creator of PHP)

The nearest thing Lisp has to a philosophy may be the koan-like description, "The programmable programming language."

Python's underlying philosophy is all about "One obvious way to do it". The Pythonic philosophy.

The Python community ensures that the language represents a collection of a carefully chosen solutions to common problems. Whenever I am about to code in Python there is one question I ask myself (which is the question I was taught to always ask before ever implementing any solution): "Has someone already solved this problem"? I look at the docs for Python's included modules and if I find one I use it. Any problem that can be solved by simply stringing several python modules together can be solved trivially. Solutions like that start to look more and more like Declarative Programming. When i need to take the next step and actually code a solution myself, again, I turn to the community and look for the pythonic way to code the it. I know this will make my code easier to understand for the python programmers who will need to reuse or maintain it later (quite possibly, me!).

Python is a not magical. Python is not an "end-all-be-all" solution. It's simply the "glue" that allows me to mash pre-existing solutions together to form a solution to even larger problems. I've been pretty happy with most Python implementations but that's just a bonus because the implementation is not the language, it's just the interpreter. In turn the language is just a contract between a software developer and a solution. For me, the most important thing about Python is the philosophy. For me Python is the contract between a great philosophy and the community that follows it.

Stuff that has been bothering me

I've been called a whiner. It is true, and I'd like to apologize right now. I'm not sorry I'm a whiner, but I am sorry that my vocal nature isn't positive more often than it's negative.

My company is, apparently, looking for web-developers. I think we need software developers regardless of web experience. Most web developers have bad habits that are hard to break. I don't think we should be in the business of programming web pages. We should be programming tools for building web pages. We should be hiring web-designers who can be trained to use the tools that our software team develops and our software team should be watching and listening to the needs of our web-designers.

When I see how fast we turn projects around, I'm not unhappy but, I'm not satisfied. When I see the code that we produce I think, "This isn't so great. Man, we could do so much better". This code comes mostly from juniors but also from our seniors (this includes myself). Most of our code is most often seen only by the author until it needs to be fixed or reused.

When I make an implementation choice and I ask peers for feedback I sometimes get "That sounds good, lets do that". Other times I hear "Well, why don't you do it this way..." and we have a discussion (usually very productive). The prior is not due to my ability to produce flawless design, but more usually due to the peer's overloading or lack of investment in the details of that particular project. The later is something that should happen to every implementation decision made by every coder.

I know I'm not the greatest tester (most developers are terrible testers) but I get frustrated when fixing the most basic of bugs that weren't found until weeks or months after the fact. I get especially frustrated when they are bugs in my own code and more so again when it was my own testing that didn't catch it.

I really do think we have the potential to be the best at what we do. All we need is to just do it, and do it right!

>>> import this

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!

Seven deadly sins of programming

• Sin #7 - Excessive Coupling
  
• Sin #6 - Inappropriately Clever Code
  
• Sin #5 - Deferred Refactoring
  
• Sin #4 - Premature Optimization
  
• Sin #3 - Overuse of Virtual
  
• Sin #2 - Overuse of Inheritance
  
• Sin #1 - Premature Generalization