On Thu, Jun 14, 2012 at 1:45 PM, Yury Selivanov <yselivanov.ml at gmail.com> wrote: > On 2012-06-14, at 4:24 PM, Benjamin Peterson wrote: > >> 2012/6/14 Alexandre Zani <alexandre.zani at gmail.com>: >>> On Thu, Jun 14, 2012 at 12:57 PM, Antoine Pitrou <solipsis at pitrou.net> wrote: >>>> On Thu, 14 Jun 2012 12:46:38 -0700 >>>> Ethan Furman <ethan at stoneleaf.us> wrote: >>>>> >>>>> This is no different from what we have with strings now: >>>>> >>>>> --> 'aA'.islower() >>>>> False >>>>> --> 'aA'.isupper() >>>>> False >>>>> --> 'a'.islower() >>>>> True >>>>> --> 'A'.isupper() >>>>> True >>>>> >>>>> We know that a string cannot be both all-upper and all-lower at the same >>>>> time; >>>> >>>> We know that because it's common wisdom for everyone (although who knows >>>> what oddities the unicode consortium may come up with in the future). >>>> Whether a given function argument may be of several kinds at the same >>>> time is much less obvious to most people. >>> >>> Is it obvious to most people? No. Is it obvious to most users of this >>> functionality? I would expect so. This isn't some implementation >>> detail, this is a characteristic of python parameters. If you don't >>> understand it, you are probably not the audience for signature. >> >> Consequently, the "kind" model should match up very well with their >> understanding that a parameter can only be one "kind" at a time. > > I myself now like the 'kind' attribute more than 'is_*' family. > Brett and Larry also voted for it, as well the majority here. > > I'll amend the PEP this evening to replace 'is_args', 'is_kwargs', > and 'is_keyword_only' with a 'kind' attribute, with possible > values: 'positional', 'vararg', 'varkw', 'kwonly'. > > Parameter class will have four constants, respectively: > > class Parameter: > KIND_POSITIONAL = 'positional' > KIND_VARARG = 'vararg' > KIND_VARKW = 'varkw' > KIND_KWONLY = 'kwonly' > > 'Parameter.is_implemented' will be renamed to 'Parameter.implemented' > > Is everybody OK with this? Thoughts? > > I, for instance, like 'varkwarg' more than 'varkw' (+ it is more > consistent with **kwargs) > > - > Yury How about keyword instead of kwonly? I find kwonly clear when side-by-side with varkw, but ambiguous standalone. I like the idea of using args and kwargs just because those are the defacto standard way we refer to that type of argument.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4