Q:

Password salts: prepending vs. appending

I just looked at the implementation of password hashing in Django and noticed that it prepends the salt, so the hash is created like sha1(salt + password), for example. 
In my opinion, salts are good for two purposes

Preventing rainbow table lookups
Alright, prepending/appending the salt doesn't really make a difference for rainbow tables. 
Hardening against brute-force/dictionary attacks
This is what my question is about.  If someone wants to attack a single password from a stolen password database, he needs to try a lot of passwords (e.g. dictionary words or [A-Za-z0-9] permutations). 
Let's assume my password is "abcdef", the salt is "salt" and the attacker tries all [a-z]{6} passwords. 
With a prepended salt, one must calculate hash("salt"), store the hash algorithm's state and then go on from that point for each permutation.  That is, going through all permutations would take 26^6 copy-hash-algorithm's-state-struct operations and 26^6 hash(permutation of [a-z]{6}) operations.  As copying the hash algorithm's state is freakin fast, the salt hardly adds any complexity here, no matter how long it is. 
But, with an appended salt, the attacker must calculate hash(permutation of [a-z]{6} + salt) for each permutation, leading to 26^10 hash operations.  So obviously, appending salts adds complexity depending on the salt length. 

I don't believe this is for historical reasons because Django is rather new.  So what's the sense in prepending salts? 

A:

Do neither, use a standard Key derivation function like PBKDF2.  Never roll your own crypto.  It's much too easy to get it wrong.  PBKDF2 uses many iterations to protect against bruteforce which is a much bigger improvement than the simple ordering. 
And your trick pre-calculating the internal state of the hash-function after processing the salt probably isn't that easy to pull off unless the length of the salt corresponds to the block-length of the underlying block-cypher.