Something I'd like to bring up at the language summit next week if we have time (suggestion: limit it to 20 minutes), lets start discussion now:<br><br>1) Should _<i>all_</i> Python base types support keyword arguments on all of their methods.<br>

2) Should _<i>all_</i> stdlib extension modules support keyword arguments on all of their functions and methods?<br><br>Assumptions: any newly supported keyword arguments would have meaningful names (and the documentation updated to reflect their name).<br>

<br>How should "_<i>all_</i>" be defined in each of the above.<div><br></div><div>One example against _<i>all_</i> is trivial single-argument functions such as chr().</div><div>One example for is the str.find method's start parameter being more obvious if named.</div>

<div><br></div><div>An example of a rule of thumb that could be proposed:</div><div>  * All optional arguments should also be accepted as keywords.</div><div>  * Any public function or method that require multiple arguments should accept them as keywords.</div>

<div><br></div><div>Why propose this?  For consistency and to promote readable code.  A reasonably often heard complaint from people new to Python that I have heard is how some things work as keyword arguments and some don't.  Pure Python code can't (easily without gross hacks) be written to refuse to accept keyword arguments, the standard types and library should not be different.</div>

<div><br></div><div>Documentation and docstrings have at times been inconsistent in the past with respect to what they call arguments and would be cleaned up as part of this to match the actual keyword argument accepted (that is worth doing on its own even without changing what the code accepts).</div>

<div><br></div><div>A decision with discussion notes on this may be PEP worthy.</div><div><br></div><div>for reference - this is <a href="http://bugs.python.org/issue8706">http://bugs.python.org/issue8706</a></div><div><div>

<br></div><div>-gps</div></div>