is_<whatever_you_are_testing_for> as method or property?

[Mateusz Loskot]

On 12 December 2014 at 22:14, Chris Angelico <rosuav at gmail.com> wrote:
> 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.

Of course, very good point.

> Plenty of people come from C++

That's me.

> 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.

Yes, I see your point now.

> 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?

Right. The particular case (with is_default and make_default members)
I'm discussing is similar to this:

class Window:
   def close(self):
      # operate window so it gets closed

   @property
   def is_closed(self)
      # query state of window

> 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.

Yes, makes sense. Thanks for brainstorming those ideas deeper.

Best regards,
-- 
Mateusz  Loskot, http://mateusz.loskot.net