Software configuration management is HARD. Every sudden backwards incompatible change (warranted or not) makes it harder. Mutli-arg append is not hurting anyone as much as a sudden change to it would. It would be better to leave append() alone and publicize its near-term removal rather than cause random, part-time supported modules to stop working because their programmers may be too busy to update them right now. So no, I'm not stepping up to do it. But I'm also saying that the better "lazy" option is to put something in a prominent place in the documentation and otherwise leave it alone. <aside> As far as I am concerned, a formal warning-based deprecation mechanism is necessary for Python's continued evolution. Perhaps we can even expose the deprecation flag to the programmer so we can say: if deprecation: print "This module isn't supported anymore." if deprecation: print "Use method FooEx instead." If we had a deprecation mechanism, maybe introducing new keywords would not be quite so painful. Version x deprecates, version y adds the keyword. Mayhap we should also deprecate implicit truncating integral division while we are at it... </aside> -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made possible the modern world." - from "Advent of the Algorithm" David Berlinski http://www.opengroup.com/mabooks/015/0151003386.shtml