Using Git to checkout the Python source code
The Python developers have decided to move from Subversion to Mercurial. However, that's taking some time to implement. For those who want a DVCS now, there are Git repositories on svn.python.org that allow efficient use of Git. I wrote a set of instructions on the Python wiki. The initial setup is a little complicated but day to day use is convenient, IMHO.
Why would you want to use Git? I can only speak for myself, but I was an early adopter of Subversion. I lead the push while at the MEMS Exchange to switch from CVS to Subversion (version 0.17.0 in 2002, I believe) . At the time, CVS's extremely poor support for moving and renaming files was hampering our ability to refactor our source code. Subversion was a definite improvement and is still a decent choice for an internally developed project. It's model of svn up doing a rebase of local changes is intuitive for most users.
Subversion still has a number of deficiencies for serious developers. For one, the handling of multiple branches of development is awkward enough that many users avoid branches (I understand SVN is getting better in this regard). Less notable but just as importantly, IMHO, it lacks many tools for dealing with changes as patches. Often I would dump a change using svn diff, edit the patch, and the apply the new patch to a different branch. Since moving to Git, I rarely have to resort to manual patch editing (instead using tools like git rebase, git format-patch, git add -i, git cherry-pick, etc).
As a tip to someone dipping their toe in the Git waters, it is critical to understand the difference between merging changes and rebasing changes. Git sort of defaults to merging but in the vast majority of cases you want to rebase instead. As an example, for one of my projects I've probably done hundreds of rebase operations and only about three merges (those three are because we have a long lived branch for a variant of the software that can't be done using configuration files). When I speak of "merge" I don't mean what Git calls a "fast-forward merge" since that's not really a merge a all. Instead, the destination branch is a strict subset of the source branch and changes are just being appending to the head version. Subversion defaults to doing rebasing rather than merging. When you run svn up your local changes are being rebased on the HEAD revision from the repository.
Git definitely has a learning curve. When I first started using it I was often confused. However, after about a week I realized it was much better than any other VCS that I had experienced. I now consider a DVCS with similar capabilities an essential developer's tool, just like a good text editor.