[Python-Dev] PEP 362 Third Revision

[R. David Murray]

On Thu, 14 Jun 2012 07:50:42 -0700, Alexandre Zani <alexandre.zani at gmail.com> wrote:
> On Thu, Jun 14, 2012 at 6:50 AM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
> > On 2012-06-14, at 8:06 AM, Victor Stinner wrote:
> >> Hum, why not using a attribute with a string value instead of 3
> >> attribute? For example:
> >> * argtype: "index", "varargs", "keyword" or "keyword_only"
> >>
> >> It would avoid a possible inconsitency (ex: is_args=True and
> >> is_kwargs=True). And it would help to implement something like a C
> >> switch/case using a dict: argtype => function for functions using
> >> signatures.
> >
> > Originally, I thought the the line:
> >
> > Â  if parameters.is_args
> >
> > is better looking that:
> >
> > Â  if parameters.kind == 'vararg'
> >
> > But, I like your arguments regarding inconsistency and dispatch
> > through a dict (someone may find it useful). Â Also, Larry gave
> > another one - who knows if we add another type of arguments in
> > the future.
> >
> > I guess if nobody really wants to keep 'is_args', we can alter the
> > PEP.
> >
> > Let's consider replacement of 'Parameter.is_*' set of attributes with
> > a single 'Parameter.kind' attribute, which will have the following
> > possible values: 'positional', 'vararg', 'keyword-only', 'varkwarg'.
> >
> > (I think 'positional' is more intuitive than 'index'?)
> >
> 
> I disagree largely for readability reasons. As the PEP stands, I can
> look at a Parameter object and immediately understand what the
> different possible values are by just listing its attributes. The kind
> attribute makes that harder.
> 
> 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.

I don't have strong feelings about this, but to me the fact that there
are values of the individual parameters that if they occur on the same
object at the same time would be invalid is a code smell.  If the thing
can be one and only one of a list of possible types, it makes sense to
me that this be indicated as a single attribute with a list of possible
values, rather than a set of boolean options, one for each type.

For the attribute error issue, we could have module attributes that give
names to the strings:

    if parameter.kind == inspect.VARARG_KIND:
        stuff

Or if we don't want that in the stdlib, the individual programmer who
cares about it can define their own constants.

--David