[Python-Dev] PEP 362 Third Revision

Alexandre Zani alexandre.zani at gmail.com
Thu Jun 14 20:36:03 CEST 2012


On Thu, Jun 14, 2012 at 10:10 AM, Brett Cannon <brett at python.org> wrote:
>
>
> On Thu, Jun 14, 2012 at 12:39 PM, Yury Selivanov <yselivanov.ml at gmail.com>
> wrote:
>>
>> On 2012-06-14, at 12:32 PM, Benjamin Peterson wrote:
>>
>> > 2012/6/14 Yury Selivanov <yselivanov.ml at gmail.com>:
>> >> On 2012-06-14, at 11:24 AM, Brett Cannon wrote:
>> >>> On Thu, Jun 14, 2012 at 9:50 AM, Yury Selivanov
>> >>> <yselivanov.ml at gmail.com> wrote:
>> >>>
>> >>> [SNIP]
>> >>>
>> >>> 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'?)
>> >>>
>> >>>
>> >>> +1 if this change is made.
>> >>
>> >> How about adding 'kind' and keeping 'is_*' attributes,
>> >> but making them read-only dynamic properties, i.e.:
>> >>
>> >>   class Parameter:
>> >>       ...
>> >>
>> >>       @property
>> >>       def is_vararg(self):
>> >>           return self.kind == 'vararg'
>> >>
>> >>       ...
>> >>
>> >> ?
>> >
>> > Seems a bit bloatly to me. (One way to do it.)
>>
>> Yes, but on the other hand it solves "strings are error prone"
>> argument, keeps all 'is_*' attributes in sync, and makes them
>> read-only.
>>
>> 'kind' property may do validation on set, to diminish mistakes
>> probability even further.
>
>
> I agree with Benjamin, it goes against TOOWTDI without enough of a
> justification to break the rule. Just make the strings constants on the
> Parameter class and you solve the lack of enum issue.
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/alexandre.zani%40gmail.com
>

I don't think it really breaks TOOWTDI because you're talking about
two use-cases. In one case, you're checking if something is a
particular kind of parameter. In the other case, you're doing some
sort of dict-based dispatch. I also think is_args etc is cleaner to
use when doing a comparison:

if param.is_arg:

vs

if param.kind == param.ARG:

That said, it's not a huge deal and so I won't push this any more than
I already have.


More information about the Python-Dev mailing list