[Traits] feature request

Hi Dave Morrill,

I see from the implementation (from trunk) that the CHasTraits class 
defines a _trait_change_notify method that is used in the trait_set 
method to disable/enable notifications.  Unfortunately, there is no way 
to determine from Python if this flag has been set or not.  This is 
needed if you want to create a Property trait that does the right thing 
in its set method.  For example:

class Test(HasTraits):
     x = Property(Float)
     _x = Float
     def _get_x(self):
	return self._x
     def _set_x(self, value):
	old = self._x
	self._x = value
	if old != new:
	    self.trait_property_changed('x', old, new)

Clearly, this will break the trait_set method when 
trait_change_notify=False.  I propose to add a 
_get_trait_change_notify() to the ctraits.c to be able to get this so 
users can write:

  if self._get_trait_change_notify():
      ...

etc. to work around this.

(Continue reading)

Martin Chilvers | 6 Sep 11:51

Re: [Traits] feature request

G'day,

Prabhu Ramachandran wrote:
> Hi Dave Morrill,
> 
> I see from the implementation (from trunk) that the CHasTraits class 
> defines a _trait_change_notify method that is used in the trait_set 
> method to disable/enable notifications.  Unfortunately, there is no way 
> to determine from Python if this flag has been set or not.  This is 
> needed if you want to create a Property trait that does the right thing 
> in its set method.  For example:
> 
> class Test(HasTraits):
>     x = Property(Float)
>     _x = Float
>     def _get_x(self):
>     return self._x
>     def _set_x(self, value):
>     old = self._x
>     self._x = value
>     if old != new:
>         self.trait_property_changed('x', old, new)
> 
> Clearly, this will break the trait_set method when 
> trait_change_notify=False.  I propose to add a 
> _get_trait_change_notify() to the ctraits.c to be able to get this so 
> users can write:
> 
>  if self._get_trait_change_notify():
>      ...
(Continue reading)

Re: [Traits] feature request

Martin Chilvers wrote:
>> Clearly, this will break the trait_set method when 
>> trait_change_notify=False.  I propose to add a 
>> _get_trait_change_notify() to the ctraits.c to be able to get this so 
>> users can write:
>>
>>  if self._get_trait_change_notify():
>>      ...
>>
>> etc. to work around this.
> 
> Hmmm... I wouldn't want to have to put this line in every property setter... smells like 
> duplication... Couldn't the 'trait_property_changed' method handle the check?

Hmm, thats a good point and the patch would be extremely simple too. 
Just do nothing if the flag has been set.  So here is an updated patch 
and test case.

cheers,
prabhu
from enthought.traits.api import HasTraits, Float, Int

import unittest

class Test(HasTraits):
    x = Float
    _test = Int(0)
    def _x_changed(self, value):
(Continue reading)

Martin Chilvers | 6 Sep 17:20

Re: [Traits] feature request

G'day,

Prabhu Ramachandran wrote:
> Martin Chilvers wrote:
>>> Clearly, this will break the trait_set method when 
>>> trait_change_notify=False.  I propose to add a 
>>> _get_trait_change_notify() to the ctraits.c to be able to get this so 
>>> users can write:
>>>
>>>  if self._get_trait_change_notify():
>>>      ...
>>>
>>> etc. to work around this.
>>
>> Hmmm... I wouldn't want to have to put this line in every property 
>> setter... smells like duplication... Couldn't the 
>> 'trait_property_changed' method handle the check?
> 
> Hmm, thats a good point and the patch would be extremely simple too. 
> Just do nothing if the flag has been set.  So here is an updated patch 
> and test case.

Nice!

I don't want to preach to the converted (and I'm not ranting here - for a change!), but this issue 
is an excellent example of API design by thinking about the intent of the code as opposed to the 
technical steps required to get it done...

This is another area where TDD helps out - by forcing you to consider how you would use your API 
first, as opposed to what we sometimes do which is to write the low-level stuff and then see how the 
(Continue reading)

Re: [Traits] feature request

Martin Chilvers wrote:
> Prabhu Ramachandran wrote:
>> Hmm, thats a good point and the patch would be extremely simple too. 
>> Just do nothing if the flag has been set.  So here is an updated patch 
>> and test case.
> 
> Nice!

Thanks.

> I don't want to preach to the converted (and I'm not ranting here - for a change!), but this issue 
> is an excellent example of API design by thinking about the intent of the code as opposed to the 
> technical steps required to get it done...
[...]

> I'm not criticising here because as developers we often just think about the steps to get something 
> done, and its only when somebody else comes to use our code that we realise that the API is maybe a 
> bit odd! It is interesting to me that when you stand back and ask the 'what would I want to write 
> here?' question, it really seems to help with API designs.. I definitely think that personally 
> asking that question has significantly improved my code over the last couple of years (and made me 
> cringe when I look back at some of the crap APIs I came up with when letting the API 'bubble up' 
> from the low-level details of how things actually get done).
> 
> I know this sounds such an obvious and simple idea, its amazing how often it gets overlooked...

This is true in many other fields too.  For example teaching is one of 
the best ways to learn for precisely the same reason.  When you try to 
teach (well!) you try to go beyond just learning the details.  The same 
happens when you explain something you think you know well to someone 
else, you see something you sometimes haven't and go "Aha!".
(Continue reading)

Gael Varoquaux | 6 Sep 18:57
Favicon

Re: [Traits] feature request

On Sat, Sep 06, 2008 at 10:00:41PM +0530, Prabhu Ramachandran wrote:
> This is true in many other fields too.  For example teaching is one of 
> the best ways to learn for precisely the same reason.

Absolutely, and a good way to develop a feel for your API, is to try to
teach it, and record what are the part that are difficult to teach, and
where are the users surprised, than try to fix them.

Gaƫl
Martin Chilvers | 6 Sep 23:45

Re: [Traits] feature request

Gael Varoquaux wrote:
> On Sat, Sep 06, 2008 at 10:00:41PM +0530, Prabhu Ramachandran wrote:
>> This is true in many other fields too.  For example teaching is one of 
>> the best ways to learn for precisely the same reason.
> 
> Absolutely, and a good way to develop a feel for your API, is to try to
> teach it, and record what are the part that are difficult to teach, and
> where are the users surprised, than try to fix them.

Exactly! An Enthought developer from days gone by renamed the 'principle of least astonishment' to 
the 'principle of least disappointment' ;^)

Martin
Peter Wang | 7 Sep 15:56

Re: [Traits] feature request

On Sep 6, 2008, at 11:30 AM, Prabhu Ramachandran wrote:

> This is true in many other fields too.  For example teaching is one of
> the best ways to learn for precisely the same reason.  When you try to
> teach (well!) you try to go beyond just learning the details.  The  
> same
> happens when you explain something you think you know well to someone
> else, you see something you sometimes haven't and go "Aha!".

My dad has always said that if you really understand something, you  
should be able to teach it to a bunch of undergrads.

-Peter
bryce hendrix | 8 Sep 17:01

Re: [Traits] feature request

Peter Wang wrote:
On Sep 6, 2008, at 11:30 AM, Prabhu Ramachandran wrote:
This is true in many other fields too. For example teaching is one of the best ways to learn for precisely the same reason. When you try to teach (well!) you try to go beyond just learning the details. The same happens when you explain something you think you know well to someone else, you see something you sometimes haven't and go "Aha!".
My dad has always said that if you really understand something, you should be able to teach it to a bunch of undergrads.

And if you don't understand it well enough, get your TA to teach the class?

Bryce
_______________________________________________
Enthought-dev mailing list
Enthought-dev@...
https://mail.enthought.com/mailman/listinfo/enthought-dev

Gmane