Getting a patch ready for checkin (corrected, documented, reviewed, and tested) is only part of the battle. The real challenge of language design is figuring out whether something should be done.
Adding optional parameters to a method makes its invocation slower and makes the API harder to learn and remember. There has not yet been a thorough discussion of use cases. In particular, people should scan their existing, deployed codebase for examples of where a particular code fragment would have been improved. We should then compare the fragment with and without the feature -- how much more concise is it, how much is performance improved/harmed, is the code more or less readable, etc. If the perf gain is small and the use cases are infrequent, the addition is likely unwarranted. There is an entire class of feature requests that are more appropriate as recipes than for inclusion in the language. If python had accepted most requests like this, it would have become somewhat bloated and unattractive. -- http://mail.python.org/mailman/listinfo/python-list
