python interview layout

Recently, I came across interview layout on comp.lang.python by
Tim Chase, I can not withstand temptation of reciting:

Basic Python:
=============
- do they know a tuple/list/dict when they see it?
- when to use list vs. tuple vs. dict. vs. set
- can they use list comprehensions (and know when not to
abuse them? :)
- can they use tuple unpacking for assignment?
- string building...do they use "+=" or do they build a list
and use .join() to recombine them efficiently
- truth-value testing questions and observations (do they
write "if x == True" or do they just write "if x")
- basic file-processing (iterating over a file's lines)
- basic understanding of exception handling
Broader Basic Python:
=====================
- questions about the standard library ("do you know if
there's a standard library for doing X?", or "in which
library would you find [common functionality Y]?") Most
of these are related to the more common libraries such as
os/os.path/sys/re/itertools
- questions about iterators/generators
- questions about map/reduce/sum/etc family of functions
- questions about "special" methods (____)
More Advanced Python:
=====================
- can they manipulate functions as first-class objects
(Python makes it easy, but do they know how)
- more detailed questions about the std. libraries (such as
datetime/email/csv/zipfile/networking/optparse/unittest)
- questions about testing (unittests/doctests)
- questions about docstrings vs. comments, and the "Why" of
them
- more detailed questions about regular expressions
- questions about mutability
- keyword/list parameters and unpacked kwd args
- questions about popular 3rd-party toolkits (BeautifulSoup,
pyparsing...mostly if they know about them and when to use
them, not so much about implementation details)
- questions about monkey-patching
- questions about PDB
- questions about properties vs. getters/setters
- questions about classmethods
- questions about scope/name-resolution
- use of lambda
Python History:
===============
- decorators added in which version?
- "batteries included" SQL-capible DB in which version?
- the difference between "class Foo" and "class Foo(object)"
- questions from "import this" about pythonic code
Python Resources:
=================
- what do they know about various Python web frameworks
(knowing a few names is usually good enough, though
knowledge about the frameworks is a nice plus) such as
Django, TurboGears, Zope, etc.
- what do they know about various Python GUI frameworks and
the pros/cons of them (tkinter, wx, pykde, etc)
- where do they go with Python related questions (c.l.p,
google, google-groups, etc)
Other Process-releated things:
==============================
- do they use revision control
(RCS/CVS/Subversion/Mercurial/Git...anything but VSS) and
know how to use it well
- do they write automated tests for their code
Touchy-feely things:
====================
- tabs vs. spaces, and their reasoning
- reason for choosing Python
- choice of editor/IDE

Mercurial merging tip

This trick helps doing a lot of merges in a commandline

hg merge `hgrev dev`

where hgrev is a bash function for finding the changeset hash:

hgrev() { local headname=$1; local rev=`hg head $headname | head -n 1 | gawk '{split($2,a,":"); print a[2]}'`; echo $rev }

write a readable code

Readability is a king. In a language, which major success happened mostly due to its improvements in readability, it is all about profound and aesthetic forms. Have you thought about it that way - the code as we read it is not the same code as we write it. Indeed, the "encoding" and "decoding" paradigm is a constantly reversed process during the software development. But what I personally find the most irritating is an expression "to write code" or simply "to code", which is irresponsibly attributed to the program composing activity. It is not only the semantics that suffers, but the very creative soul of the intellectual act.

Coding is all about translating a language of the concept into a language of the program. But in practice, not code, but stenographic writing is what is so often produced as an output. A perfect programming solution is already a language itself. An average developer is first lured by promising advantages of certain language, then steadily and dogmatically converted by its "exciting" lovelinesses, finally starts desperately advocating for something which he does not really masters or senses. All this painful evolution is normally cycled, when our newly matured adept continues the bloody expansion by converting new casualties. But the trick with any formal language is that it is not more than a handy instrument to put a group of symbols in a grammatically arranged joint. All the work, left there untouched, is to be conducted by the author of the program. It is the author who declares variables and drives the semantical wheel of specifying the identificators. It is he who governs the distribution of complexity through vast functionality. It is he who makes things come alive by telling the story behind the algorithm.

So, the real question is how definitive a good program could be? The code which is self-explanatory is a masterpiece of an inter-human communication (omitting the presence of computer as a mere necessity), thus automatically must be graded as a program. Such code does not require any artificial documentation or redundant comments. Such code is a pure logical semantics - above any formalism or hyper-consistency.

The introduction of the post was indeed a dramatical overkill. A reasonable need for an example must bring the discussion to a firm ground.

Python is one of those languages that, although intended to grasp the impossible - propose a constitution for perfect formalization - and, IMHO, failed, nonetheless has done better than most of its competitors. It is always up to python developer to resolve the design dogma "there is one and only one way to do something".

The following equivalent statements are a good example based on os module usage for some strings (a, b, c):

assert(os.path.join('a', 'b', 'c') ==  os.sep.join(('a', 'b', 'c')))

Mastering the ability to conclude which construction maybe preferable to the code readability can turn out to be an important asset in producing consistent code.

Another important example is:

a = ''
assert(len(a) <= 0 == not a)

Implicit casting of a string or a list variables of zero length to boolean False, may turn out to be priceless in producing shorter, but more readable forms.

There are even more examples. Most of them must be known from studying PEP8 (Programming Recommendations). Others are an important piece of valuable practical knowledge, collected with time.