As discussed on python-dev here:
http://mail.python.org/pipermail/python-dev/2005-September/056396.html

This is a more complete version.  It seems to speed up
code that makes heavy use of append by about 1.5 - 2.0 %

Logged In: YES 
user_id=80475

-0 on this one. It really needs a much larger improvement
(30% to 50%) to be worth it.  The new ceval.c code for
LIST_APPEND will slightly slow-down the list comprehension
case that the opcode was originally designed for.  Also, it
slows-down the peepholer with a string comparison test for
every attribute lookup making it the slowest and most
frequently executed code in the peepholer.  

The implementation is limited to the simplest case,
x.append(y) and cannot handle general expressions such
x.append(y+y).  It would likely be better to implement this
sort of transformation through AST when it is complete.

If it goes in anyway, be sure to add a test to make sure
descriptors still work (i.e. a non-data descriptor called
"append" for a user defined class).

Logged In: YES 
user_id=4771

I vote -1 on this:

* these peephole transformations need a lot of care
  to get perfectly right.  For example, I think that
  you are not checking that there is really a LOAD_XXX
  between LOAD_ATTR and CALL_FUNCTION, which means that
  you'll incorrectly match e.g. the bytecode of the line
  'f(x.prepend < x.append)' and turn it into something
  very broken.

* I don't remember seeing ever discussed the fact that
  CALL_METHOD-style optimizations are a semantic
  change: in 'x.append(f())', the LOAD_ATTR occurs
  before the call to f(), whereas with the
  optimization it occurs after.  No sane code should
  rely on that, but the language specification tends
  to promize a left-to-right evaluation order unless
  otherwise specified.

Logged In: YES 
user_id=33168

Response to Armin:
1) I think you are correct there is a problem with f(x.pp <
x.append).  2) I don't know if there was a discussion on the
semantic changes.

Response to Raymond:
The improvement is on the order of 50% for code that just
does L.append().  It was ~2% for Tim's program that is
referenced in the mail thread.  ie, it was the total program
speed up, not just a simple test specifically for this feature.

I'm not real keen on this patch as it's too targetted.  I
think the arguments could be overcome, however, time is
better spent on a more general solution.