On 6/14/2012 1:10 PM, Brett Cannon wrote:


On Thu, Jun 14, 2012 at 12:39 PM, Yury Selivanov
<yselivanov...@gmail.com <mailto:yselivanov...@gmail.com>> wrote:

    On 2012-06-14, at 12:32 PM, Benjamin Peterson wrote:

     > 2012/6/14 Yury Selivanov <yselivanov...@gmail.com
    <mailto:yselivanov...@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...@gmail.com <mailto:yselivanov...@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.

My opinion: I don't like the multiple radio-button attributes either. It is one attribute with multiple values. We use constants elsewhere. In the absence of an enum type that maps ints to a string, the constants should be strings for display and printing.

--
Terry Jan Reedy

_______________________________________________
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

Reply via email to