The built-in function page (http://docs.python.org/dev/py3k/library/functions.html) is pretty long. Each function has an anchor but unlike the built-in types section there is no quick way to get an overview or jump to a specific function (like open or print) short of scrolling through 22 pages. It would be nice to have an index of all built-in functions linked to the specific entry on the built-in functions page. This could be either somehow added to the index page (http://docs.python.org/dev/py3k/library/index.html) or to the top of the built-in functions page itself. For efficient use of real-estate multiple function names could be on one single line alphabetically sorted and separated by spaces.

+1 on the general idea. I applied the patch and built the documentation to see what the output looks like: The hotlinks are here and work, that’s cool, but I think the table wastes space. You could use five columns without damaging usability (that is, summoning the hateful horizontal scrollbar), even in 800×600 with an uncollapsed sidebar.
Alternative ideas like using a special unordered list with automatic CSS 3 flowing or replacing the manual table with a new Sphinx directive would take a lot of time, so consider I’m +1 on whatever you decide best.

Here's a new patch with a 5 column tables. I had to use some rst trickery to make a decent header that works both in the HTML and Latex outputs. I put the title in the middle cell (the 3rd) of the header and left the others empty. The column cells are a little wider but they are still OK at 800x600.
Éric how do you like this version? I could also drop the header altogether, but I don't like the headless table too much.

I like this version. HTML and LaTex build without warning; all-pdf takes forever and spits out a metric ton of messages, so I haven’t checked its result.
The markup trickery is unfortunate, though, I’d like a pronouncement from Georg about that.

I don't think it's worth changing it. The table still provides a good overview, and having them at the end won't prevent people to find their doc.
Both the table and the page could be divided in sections though, if we find a way to group all the functions that makes enough sense (e.g. put together int/dict/list/set/etc, getattr/setattr/delattr, but then it's difficult to add more groups without maxing them too small).

Dividing the table in sections makes sense to me; it provides the kind of grouping that is helpful sometimes, but cannot be kept when sorting alphabetically. So when the table is grouped, the actual docs can remain alphabetized.