[traits] init issue...

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[traits] init issue...

fred-2
Hi all,

In the following CME, color's Colormap1 is well initialized, but not
color's Colormap2.

I could add in _colormap_default(self):

  return Colormap2(parent=self,
                   color=self.color)

but what I don't understand is that _default_color()'s Colormap2
is well called, but the color is bad (ie white, not red).

Why?


TIA

Cheers,

--
Fred

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev

cme.py (860 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [traits] init issue...

Thomas Lecocq
Fred,

your email is quite unclear

If i get it well:

you wonder why Colormap1.color is well defined, while Colormap2.color is not ? right ?


Thomas

Date: Tue, 8 Feb 2011 12:36:42 +0100
From: [hidden email]
To: [hidden email]
Subject: [Enthought-Dev] [traits] init issue...

Hi all,

In the following CME, color's Colormap1 is well initialized, but not
color's Colormap2.

I could add in _colormap_default(self):

return Colormap2(parent=self,
color=self.color)

but what I don't understand is that _default_color()'s Colormap2
is well called, but the color is bad (ie white, not red).

Why?


TIA

Cheers,

--
Fred

_______________________________________________ Enthought-Dev mailing list [hidden email] https://mail.enthought.com/mailman/listinfo/enthought-dev
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: [traits] init issue...

fred-2
Le 08/02/2011 12:50, Thomas Lecocq a écrit :
> Fred,
>
> your email is quite unclear
Oops, sorry.
>
> If i get it well:
>
> you wonder why Colormap1.color is well defined, while Colormap2.color is
> not ? right ?
I wonder why Colormap2.color is not well defined, although its
_default_color() is called.

(And I do understand why Colormap1.color is well defined ;-))

Cheers,

--
Fred
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: [traits] init issue...

Didrik Pinte-2
In reply to this post by fred-2
Fred,

If you had the following lines to your main :

    assert my_class.color == my_class.colormap1.color
    assert my_class.color == my_class.colormap2.color

you will see that color gets passed along correctly. Now, it seems
there is an issue with the editor.

Regarding the colormap1,  you break all the traits machinery by now
calling the HasTraits.__init__ method which is bad ;-)

-- Didrik
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: [traits] init issue...

fred-2
Le 08/02/2011 13:13, Didrik Pinte a écrit :

> Fred,
>
> If you had the following lines to your main :
>
>      assert my_class.color == my_class.colormap1.color
>      assert my_class.color == my_class.colormap2.color
>
> you will see that color gets passed along correctly. Now, it seems
> there is an issue with the editor.
>
> Regarding the colormap1,  you break all the traits machinery by now
> calling the HasTraits.__init__ method which is bad ;-)
Mmmh, I'm afraid I don't understand you here.

Calling __init__ method seems to give correct results.
And using _trait_default, not.

But, in fact, I don't want to use __init__ calls.

--
Fred
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: [traits] init issue...

Didrik Pinte-2
On Tue, Feb 8, 2011 at 1:55 PM, Fred <[hidden email]> wrote:

> Le 08/02/2011 13:13, Didrik Pinte a écrit :
>> Fred,
>>
>> If you had the following lines to your main :
>>
>>      assert my_class.color == my_class.colormap1.color
>>      assert my_class.color == my_class.colormap2.color
>>
>> you will see that color gets passed along correctly. Now, it seems
>> there is an issue with the editor.
>>
>> Regarding the colormap1,  you break all the traits machinery by now
>> calling the HasTraits.__init__ method which is bad ;-)
> Mmmh, I'm afraid I don't understand you here.

If you look at the content of the color attributes of your different
classes, they are initialised correctly using the default method (or
the __init__ call).
The issue is not at the model level but at the view level.

>
> Calling __init__ method seems to give correct results.
> And using _trait_default, not.

It does give the correct results. I am trying to understand what
happens in the view/editor. This is strange.

-- Didrik
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: [traits] init issue...

Warren Weckesser


On Tue, Feb 8, 2011 at 9:19 AM, Didrik Pinte <[hidden email]> wrote:
On Tue, Feb 8, 2011 at 1:55 PM, Fred <[hidden email]> wrote:
> Le 08/02/2011 13:13, Didrik Pinte a écrit :
>> Fred,
>>
>> If you had the following lines to your main :
>>
>>      assert my_class.color == my_class.colormap1.color
>>      assert my_class.color == my_class.colormap2.color
>>
>> you will see that color gets passed along correctly. Now, it seems
>> there is an issue with the editor.
>>
>> Regarding the colormap1,  you break all the traits machinery by now
>> calling the HasTraits.__init__ method which is bad ;-)
> Mmmh, I'm afraid I don't understand you here.

If you look at the content of the color attributes of your different
classes, they are initialised correctly using the default method (or
the __init__ call).
The issue is not at the model level but at the view level.

>
> Calling __init__ method seems to give correct results.
> And using _trait_default, not.

It does give the correct results. I am trying to understand what
happens in the view/editor. This is strange.



'Color' is a mapped Traits, so the 'color' trait will have a corresponding shadow trait called 'color_'.  In the attached file, I create a default function for both 'color' and 'color_'.  This works, but it should not be necessary.

There may be an initialization order problem with 'color' and 'parent'.

I also fixed the __init__() function of Colormap1 so that the 'parent' trait is created correctly, but that problem was not the main issue here.

Warren


-- Didrik
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev


_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev

cme2.py (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [traits] init issue...

Warren Weckesser


On Tue, Feb 8, 2011 at 10:15 AM, Warren Weckesser <[hidden email]> wrote:


On Tue, Feb 8, 2011 at 9:19 AM, Didrik Pinte <[hidden email]> wrote:
On Tue, Feb 8, 2011 at 1:55 PM, Fred <[hidden email]> wrote:
> Le 08/02/2011 13:13, Didrik Pinte a écrit :
>> Fred,
>>
>> If you had the following lines to your main :
>>
>>      assert my_class.color == my_class.colormap1.color
>>      assert my_class.color == my_class.colormap2.color
>>
>> you will see that color gets passed along correctly. Now, it seems
>> there is an issue with the editor.
>>
>> Regarding the colormap1,  you break all the traits machinery by now
>> calling the HasTraits.__init__ method which is bad ;-)
> Mmmh, I'm afraid I don't understand you here.

If you look at the content of the color attributes of your different
classes, they are initialised correctly using the default method (or
the __init__ call).
The issue is not at the model level but at the view level.

>
> Calling __init__ method seems to give correct results.
> And using _trait_default, not.

It does give the correct results. I am trying to understand what
happens in the view/editor. This is strange.



'Color' is a mapped Traits, so the 'color' trait will have a corresponding shadow trait called 'color_'.  In the attached file, I create a default function for both 'color' and 'color_'.  This works, but it should not be necessary.


Uncomment the definition of _color__default() to see what I meant--I had been experimenting, and in the version of cme2.py that I attached, _color__ defuault() is commented out.

Warren


There may be an initialization order problem with 'color' and 'parent'.

I also fixed the __init__() function of Colormap1 so that the 'parent' trait is created correctly, but that problem was not the main issue here.

Warren


-- Didrik
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: [traits] init issue...

Warren Weckesser


On Tue, Feb 8, 2011 at 10:20 AM, Warren Weckesser <[hidden email]> wrote:


On Tue, Feb 8, 2011 at 10:15 AM, Warren Weckesser <[hidden email]> wrote:


On Tue, Feb 8, 2011 at 9:19 AM, Didrik Pinte <[hidden email]> wrote:
On Tue, Feb 8, 2011 at 1:55 PM, Fred <[hidden email]> wrote:
> Le 08/02/2011 13:13, Didrik Pinte a écrit :
>> Fred,
>>
>> If you had the following lines to your main :
>>
>>      assert my_class.color == my_class.colormap1.color
>>      assert my_class.color == my_class.colormap2.color
>>
>> you will see that color gets passed along correctly. Now, it seems
>> there is an issue with the editor.
>>
>> Regarding the colormap1,  you break all the traits machinery by now
>> calling the HasTraits.__init__ method which is bad ;-)
> Mmmh, I'm afraid I don't understand you here.

If you look at the content of the color attributes of your different
classes, they are initialised correctly using the default method (or
the __init__ call).
The issue is not at the model level but at the view level.

>
> Calling __init__ method seems to give correct results.
> And using _trait_default, not.

It does give the correct results. I am trying to understand what
happens in the view/editor. This is strange.



'Color' is a mapped Traits, so the 'color' trait will have a corresponding shadow trait called 'color_'.  In the attached file, I create a default function for both 'color' and 'color_'.  This works, but it should not be necessary.


Uncomment the definition of _color__default() to see what I meant--I had been experimenting, and in the version of cme2.py that I attached, _color__ defuault() is commented out.


Looks like setting the default of a mapped traits using the static method has problems.

Simplified example:

-----
from enthought.traits.api import Trait, HasTraits


SmallInt = Trait('zero', dict(zero=0, one=1, two=2, three=3, four=4, five=5))


class Foo(HasTraits):

    value = SmallInt
   
    def _value_default(self):
        return 'one'


if __name__ == "__main__":
    w = Foo()
    print w.value, w.value_
    w.value = 'three'
    print w.value, w.value_
-----

prints:
one 0
three 3


Warren


 

Warren


There may be an initialization order problem with 'color' and 'parent'.

I also fixed the __init__() function of Colormap1 so that the 'parent' trait is created correctly, but that problem was not the main issue here.

Warren


-- Didrik
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev




_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: [traits] init issue...

fred-2
In reply to this post by fred-2
Hi all,

Is anybody has news about this issue?

https://mail.enthought.com/pipermail/enthought-dev/2011-February/028343.html

TIA


Cheers,

--
Fred
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: [traits] init issue...

Warren Weckesser


On Fri, Apr 8, 2011 at 8:16 AM, Fred <[hidden email]> wrote:
Hi all,

Is anybody has news about this issue? 

https://mail.enthought.com/pipermail/enthought-dev/2011-February/028343.html


Not that I know of.  Anthony Scopatz is organizing an ETS sprint this weekend--perhaps a sprinter could take a look at this.

Warren
 

TIA


Cheers,

--
Fred
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev


_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: [traits] init issue...

fred-2
Le 15/04/2011 22:17, Warren Weckesser a écrit :

> Not that I know of.  Anthony Scopatz is organizing an ETS sprint this
> weekend--perhaps a sprinter could take a look at this.
Should be great!

Cheers,

--
Fred
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: [traits] init issue...

Fred
In reply to this post by fred-2
Le 08/04/2011 15:16, Fred a écrit :
> Hi all,
>
> Is anybody has news about this issue?
>
> https://mail.enthought.com/pipermail/enthought-dev/2011-February/028343.html
Hi all,

I still have this issue...

Could somebody glance at it?


TIA.



Cheers,


--
Fred
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev