bug#15295: which-func-mode slow in long Python tuple

[Dale]

	I happen to have a Python source file that has a relatively long tuple 
at the module top level, i.e. a Python source file containing:

----------
foo = (
    "item 1",
    "item 2",
    # ...and so on for ~500 lines
)
----------

I also use which-function-mode.  If I go to the end of that tuple and 
move the cursor in to it, Emacs becomes unusably slow.  It will appear 
to lock up and eat 100% CPU for 10-20 seconds each time I move the 
cursor within the end of that tuple.  Emacs remains responsive at the 
top of the tuple.

	I think this is happening because python-info-current-defun is slow 
when dealing with long tuples.  (Maybe lists, dicts, and other things 
too; I only tested tuples.)  Here's some elisp to produce a test case 
and benchmark python-info-current-defun:

----------
(progn
  (set-buffer (generate-new-buffer "*test*"))
  (python-mode)
  (insert "foo = (\n")
  (dotimes (_ 500) (insert "    \"bar\",\n"))
  (insert ")\n")
  (forward-line -2)
  (message "%S" (benchmark-run (python-info-current-defun))))
----------

This makes a python-mode buffer named "*test*" containing only a 
500-item Python tuple, as in my above example.  On my hardware, the 
above benchmark-run yields a result such as "(7.364507 131 
0.9572049999999979)", i.e. 7.3 seconds to run.

	Once that *test* buffer is created, feel free to turn on 
which-function-mode in there and see that Emacs locks up every time you 
move the cursor around in the end of that tuple.  (which-function-mode 
seems to be taking about twice the time reported by benchmark-run. 
Perhaps it's calling python-info-current-defun twice?)

	I have reproduced this behavior with "emacs -Q" using an Emacs I just 
built from trunk, looks like revision 114162.  (I get Emacs from Git, 
where the master branch is 0f1532f2fe2.)  I have also reproduced this 
with python.el from the emacs-24 branch, looks like revision 111403.

        Thanks to everyone who develops Emacs, an indispensable tool for me!

Dale