On 14 June 2012 15:50, Alexandre Zani <alexandre.z...@gmail.com> wrote: > Comparing with strings is error prone. If I do param.is_varargs > (adding an s at the end of the attribute name) I will see an attribute > error and know what is going on. If I do the same mistake with the > kind attribute param.kind == "varargs", the expression will just > always be False without any explanation.
Agreed. Particularly in this case, a lot of the possible values are far from completely standardised terms, so misspellings are quite possible. Apart from the varargs case mentioned, I'd have to look at the docs to know what name was used for the kind of a "normal" parameter. To be honest, I'm not too keen in is_args/is_kwargs as names, but they are short and match common usage. I could go with is_vararg and is_kwarg (or is_varargs and is_kwargs, but I hate the abbreviation varkwarg :-)) because they are closer parallels, but either way this is trivial bikeshedding, not worth spending time on. If anyone *really* wants a "kind" string, parameter_kind(param) isn't hard to define in your app, and you can choose your own terms... So my view is -1 to a "kind" parameter, and +1 to the current is_XXX names simply because there's no point bikeshedding. Oh, and +1 to the PEP as a whole :-) Paul. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
