is_<whatever_you_are_testing_for> as method or property?

Chris Angelico rosuav at gmail.com
Fri Dec 12 16:14:35 EST 2014


On Sat, Dec 13, 2014 at 8:03 AM, Mateusz Loskot <mateusz at loskot.net> wrote:
> On 12 December 2014 at 12:26, Chris Angelico <rosuav at gmail.com> wrote:
>> On Fri, Dec 12, 2014 at 10:21 PM, Mateusz Loskot <mateusz at loskot.net> wrote:
>>> I've got several cases which are not obvious to me.
>>> For instance, class Foo has a boolean attribute, read-write,
>>> which I see a couple of realisations for possible:
>>>
>>
>> 0) Attribute only.
>>
>> class Foo:
>>     pass
>>
>> Foo().default = True
>>
>> Unless you need something more than this, go with this style. Much simpler.
>
>
> Agreed, in general, but if the question was related to such simple case,
> I wouldn't bother asking it.
>
> I mentioned, setting the new value involves more changes to Foo()
> instance, so i's not possible to capture it with just an assignment.
> Hence, the discussion between property vs method.

It's still worth mentioning, for completeness. Plenty of people come
from C++ or Java and simply don't realize that direct attribute access
makes fine sense. Your statement here talks about a read-write boolean
attribute, so starting off with the simplest way of doing that - an
actual attribute - emphasizes the commonness of this.

So, your subsequent design decisions are based around the fact that
you cannot simply assign to .default and have it do the right thing.
Are you even able to set default to False? For instance, you might
have a system where there must always be one "default", and so you
can't make this one not-default, but you could make a different one
the default, which will un-default-ify this one as a side effect. In
that case, a "make_default()" method makes the most sense. But if you
can independently and cheaply set any instance's default flag, you
could have the actual attribute, and then a set_default() method,
which updates it. Plenty of Python classes recommend not arbitrarily
altering certain attributes.

ChrisA



More information about the Python-list mailing list