spir wrote:
Hello,
I have noticed a rather strong and nearly systematic opposition to (new) keywords. Cannot really figure out why. Would someone clearly expose the reasoning behind keeping the keyword set as small as possible? (I thought at not preventing users to use the same words as names, but this reason does not seem to hold. On the contrary: non-keyword builtins bite painfully!)
However, using builtin names as attribute or method names is often quite useful and sensible. You can't do that with keywords - those are disallowed everywhere other than in the syntactic constructs that rely on them. You can see the ugly workarounds that are needed in the case of a couple of existing keywords like 'class' (where people have to use 'cls', 'class_' or 'klass' instead) and 'assert' (generally replaced with either 'assert_' or 'assertTrue'). In addition to the above and to what Ben said, every new keyword also means going through the whole __future__ and DeprecationWarning dance in order to warn people about the introduction of the new keyword without breaking existing code. Any users whose code triggers those warnings will have to expend additional effort to port their application to the Python version where the new keyword is enabled by default. That last point is enough of a reason to dislike the idea of new keywords purely from the point of view of aggregate development effort (i.e. not just effort from the core devs, but the porting effort from all the affected third part developers as well). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------