Pure Python Traits Update

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

Pure Python Traits Update

Aris Koutsiamanis
Hello,

I have written a network simulation app for my PhD and I have used Traits (3.5) with great success.
However, I now need to build a user interface that will allow me to explore the results.
I have already tried Traits UI and have found it to be lacking and have decided to use PyQt.
I need to create classes that inherit from both a PyQt class (e.g. QWidget) and HasTraits to get Traits support within them.
It is unfortunate however, as I found out, that this is not accomplishable because of the known Python limitation of subclassing from more than one C/C++ implemented class.
This is exhibited by the following error:
"TypeError: Error when calling the metaclass bases multiple bases have instance lay-out conflict"

In response I searched further and I have seen that the IPython project has implemented a lightweight pure Python Traits lookalike (IPython.utils.traitlets).
(I tried to use traitlets but it gave me weird errors about default values not being configured correctly.)
There seemed to be a discussion, initiated at SciPy 2009, to merge traitlets and Traits. However, I have not seen evidence of this happening (albeit I have not searched too deeply).

I was wondering whether creating a pure Python Traits version is in the works or if it has been abandoned.

In any case, thanks for all the great tools.

Cheers,
Aris


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

Re: Pure Python Traits Update

Aris Koutsiamanis
Update

Phil Thompson helpfully pointed me towards dip.model (http://www.riverbankcomputing.com/static/Docs/dip/model_tutorial.html).
While dip certainly does solve my problem, it does so at the expense of my using two diffrent traits libraries in different parts of the code (simulation(Traits) and visualization(dip.model)).
The more fundamental issue is that dip.model has the same problem as enthought Traits:
  it is C/C++ based and as a result it cannot support multiple inheritance with other (external) C/C++ based classes.
Obviously, since dip is created by Phil, he has used the same metaclass as PyQt (dip.model.MetaModel which subclasses pyqtWrapperType) and as a result it can at least provide interoperability with PyQt classes.
While this is nice, and much better than not being able to use traits at all, it does limit its potential uses.

Now, I'm no Python metaclass God and I do know that this kind of multiple inheritance is fundamentally limited due to the Python interpreter, however, is it not possible to provide the same functionality dip.model.Model or enthought.traits.api.HasTraits provides while using only pure Python?

Cheers,
Aris



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

Re: Pure Python Traits Update

bryce hendrix-2
In reply to this post by Aris Koutsiamanis
On Sun, Nov 14, 2010 at 3:28 PM, Aris Koutsiamanis <[hidden email]> wrote:
Hello,

I have written a network simulation app for my PhD and I have used Traits (3.5) with great success.
However, I now need to build a user interface that will allow me to explore the results.
I have already tried Traits UI and have found it to be lacking and have decided to use PyQt.
I need to create classes that inherit from both a PyQt class (e.g. QWidget) and HasTraits to get Traits support within them.
It is unfortunate however, as I found out, that this is not accomplishable because of the known Python limitation of subclassing from more than one C/C++ implemented class.
This is exhibited by the following error:
"TypeError: Error when calling the metaclass bases multiple bases have instance lay-out conflict"

In response I searched further and I have seen that the IPython project has implemented a lightweight pure Python Traits lookalike (IPython.utils.traitlets).
(I tried to use traitlets but it gave me weird errors about default values not being configured correctly.)
There seemed to be a discussion, initiated at SciPy 2009, to merge traitlets and Traits. However, I have not seen evidence of this happening (albeit I have not searched too deeply).

I was wondering whether creating a pure Python Traits version is in the works or if it has been abandoned.


Aris,

Traits 1.0 was pure python, I think, but it predates me. Perhaps a Traits old timer will admit to being that old, and still be able to recall what issue Traits 1.0 had (besides speed)?

On a different note- I wouldn't use multiple inheritance. You are most likely trying to combine your Model, View and Controller all into 1 class. Instead, make your view inherit from the desired PyQt class (for simplicity, this can be your view and controller) and have an attribute which is the HasTraits subclass instance (this is the model). You then setup listeners for whatever you want for your model in your view, which you can then update the GUI components.

Bryce
 
In any case, thanks for all the great tools.

Cheers,
Aris


_______________________________________________
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: Pure Python Traits Update

Robert Kern
On Mon, Nov 15, 2010 at 9:39 AM, bryce hendrix <[hidden email]> wrote:

> On Sun, Nov 14, 2010 at 3:28 PM, Aris Koutsiamanis <[hidden email]>
> wrote:
>>
>> Hello,
>>
>> I have written a network simulation app for my PhD and I have used Traits
>> (3.5) with great success.
>> However, I now need to build a user interface that will allow me to
>> explore the results.
>> I have already tried Traits UI and have found it to be lacking and have
>> decided to use PyQt.
>> I need to create classes that inherit from both a PyQt class (e.g.
>> QWidget) and HasTraits to get Traits support within them.
>> It is unfortunate however, as I found out, that this is not accomplishable
>> because of the known Python limitation of subclassing from more than one
>> C/C++ implemented class.
>> This is exhibited by the following error:
>> "TypeError: Error when calling the metaclass bases multiple bases have
>> instance lay-out conflict"
>>
>> In response I searched further and I have seen that the IPython project
>> has implemented a lightweight pure Python Traits lookalike
>> (IPython.utils.traitlets).
>> (I tried to use traitlets but it gave me weird errors about default values
>> not being configured correctly.)
>> There seemed to be a discussion, initiated at SciPy 2009, to merge
>> traitlets and Traits. However, I have not seen evidence of this happening
>> (albeit I have not searched too deeply).
>>
>> I was wondering whether creating a pure Python Traits version is in the
>> works or if it has been abandoned.
>>
>
> Aris,
> Traits 1.0 was pure python, I think, but it predates me. Perhaps a Traits
> old timer will admit to being that old, and still be able to recall what
> issue Traits 1.0 had (besides speed)?

It was pretty different, but you really only need C for the speed.
What prevents us from making a pure Python Traits alongside the
current C Traits is mostly the cost of maintaining two systems with
different sets of bugs.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pure Python Traits Update

Martin Chilvers
In reply to this post by Aris Koutsiamanis
G'day,

On 14/11/2010 22:38, Aris Koutsiamanis wrote:
> Now, I'm no Python metaclass God and I do know that this kind of
> multiple inheritance is fundamentally limited due to the Python
> interpreter, however, is it not possible to provide the same
> functionality dip.model.Model or enthought.traits.api.HasTraits provides
> while using only pure Python?

AFAIK, it should be possible to do everything that Traits does in pure
Python, but I would imagine you would take quite a severe performance
hit... (still, first rule of optimization and all that ;^)...

However, I've often thought that Traits should be implemented first in
pure Python, and then have an optionally built C-extension that gives
the speedup (a la PyProtocols _speedups.pyd or whatever it is called ;^)...

The pure Python version would also allow easy experimentation with new
features etc, and would provide a nice test bed to help ensure the C
version (which is inherently harder to get right) is correct...

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

Re: Pure Python Traits Update

Aris Koutsiamanis
In reply to this post by bryce hendrix-2
Hello Bryce,


Traits 1.0 was pure python, I think, but it predates me. Perhaps a Traits old timer will admit to being that old, and still be able to recall what issue Traits 1.0 had (besides speed)?

On a different note- I wouldn't use multiple inheritance. You are most likely trying to combine your Model, View and Controller all into 1 class.
You are absolutely right, I shouldn't do it like that. 
Instead, make your view inherit from the desired PyQt class (for simplicity, this can be your view and controller) and have an attribute which is the HasTraits subclass instance (this is the model). You then setup listeners for whatever you want for your model in your view, which you can then update the GUI components.
I guess you are proposing something like:
class MyModel(HasTraits):
    a = Int()

class TreeView(QtGui.QTreeView):
def __init__(self):
    self.model = MyModel()

What you are basically proposing is to use composition instead of multiple inheritance, and I will be pursuing this option. However, the limitation remains that you cannot use Traits on a C-based class. Therefore, in scenarios different to mine it may not work out as elegantly.

Aris

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

Re: Pure Python Traits Update

Aris Koutsiamanis
In reply to this post by Martin Chilvers
Hello Martin,

On Mon, Nov 15, 2010 at 5:53 PM, Martin Chilvers <[hidden email]> wrote:
AFAIK, it should be possible to do everything that Traits does in pure
Python, but I would imagine you would take quite a severe performance
hit... (still, first rule of optimization and all that ;^)...

However, I've often thought that Traits should be implemented first in
pure Python, and then have an optionally built C-extension that gives
the speedup (a la PyProtocols _speedups.pyd or whatever it is called ;^)...

The pure Python version would also allow easy experimentation with new
features etc, and would provide a nice test bed to help ensure the C
version (which is inherently harder to get right) is correct...

Martin


that was the gist of what I was asking, i.e. why not pure a Python Traits lib with a secondary C implementation for speed.
It may even be possible to use something like Cython to ease its development.
Of course this all has the overhead that Robert Kern mentioned (doubling the maintenance duties).

I'm currently trying to think of a way to circumvent the need for multiple inheritance through the use of class decorators.
The idea is quite simple, but not being proficient enough in meta-programming, I might have missed something which is a deal breaker.

1. Make a class decorator which dynamically creates a nested class within the decorated class which subclasses HasTraits.
2. Move the defined traits and trait handlers from the decorated class to the hidden nested class
3. Make sure all references to the traits and the trait handlers point to the corresponding nested class traits and handlers
4. Monkey patch / wrap the decorated class __init__ to make sure that a nested class instance is created before it its __init__ runs.
5. Profit!

e.g.:
@traitify
class MyClass(QtGui.QWidget):
    int_trait = Int()
 
    def __init__(self):
        self.int_trait = 10

    @on_trait_change('int_trait')
    def _do_stuff(self):
        print self.int_trait


through the use of the traitify decorator should become the equivalent of:

class MyClass(QtGui.QWidget):
    class MyHiddenDynamiclyCreatedNestedClassWithTraits(HasTraits):
        int_trait = Int()
 
        @on_trait_change('int_trait')
        def _do_stuff(self):
            print self.int_trait

    def __init__(self):
        self._hidden_nested_class_instance = MyClass.MyHiddenDynamiclyCreatedNestedClassWithTraits()
        self._original_init()

    def _do_stuff(self):
        return self._hidden_nested_class_instance._do_stuff()

    int_trait = property(lambda self: self._hidden_nested_class_instance.int_trait, #getter
                         lambda self, value: self._hidden_nested_class_instance.int_trait = value #setter
                        )
Alternatively, I may use __getattr__, __setattr__, __delattr__ to achieve the same effect.
Does this make any sense? Am I just reinventing the wheel and there is a library which achieves the same thing?

Obviously, all these redirects will have a performance penalty, which depending on the case may or may not be justifiable.
Cheers,
Aris


    

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

Re: Pure Python Traits Update

Giraudon Cyril
In reply to this post by Aris Koutsiamanis
Hello,

I've experienced the same issue but with the persistent layer.

I looked for modeling a huge object graph (often greater than the RAM
space of a classical PC).

Some tasks deal with a particular instance of the graph (edition) and
for some tasks the graph has to be analysed entirely.

I decided to use Traits for the business model (because I like Traits)
and ZODB for the persistent layer. Traits brings obverver pattern,  easy
View definition thanks to typed properties, it uses Qt  as backend, PyQt
Editor can be added...
ZODB brings a complete object database, stores objects in a file and use
the RAM as a cache.

To track object changes, ZODB persistent objects must subclass a C/C++
Persistent class. A no Persistent subclass can be persisted, but the
commit action can't know if objects change.

My conclusion was Traits idiom is not compatible with an object
persistent layer but rather a View layer.

This thread shows it is not so easy to determinate the place of Traits
in a ntiers layer data model application, persistence, model,
presentation...

Best Regards and thanks a lot for this great work,

Cyril.

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

Re: Pure Python Traits Update

Brian Granger
A few comments about pure python traits:

* We (IPython devs) plan on maintaining the pure Python traits (traitlets) until a pure Python version of traits exists.
* We have talked to Eric and other Enthought folks about a pure Python version of traits.  They were open to the idea, but I 
think it is mostly a manpower/priority issue.
* Our motivation is that we want the core of IPython to be pure Python and to be portable easily to Jython and IronPython.
* It is possible to do multiple inheritance with PyQt and traitlets.  Here are some helper classes from IPython:


* If there are bugs in traitlets, please file an IPython issue on github:


Cheers,

Brian


On Tue, Nov 16, 2010 at 1:57 AM, Giraudon Cyril <[hidden email]> wrote:
Hello,

I've experienced the same issue but with the persistent layer.

I looked for modeling a huge object graph (often greater than the RAM
space of a classical PC).

Some tasks deal with a particular instance of the graph (edition) and
for some tasks the graph has to be analysed entirely.

I decided to use Traits for the business model (because I like Traits)
and ZODB for the persistent layer. Traits brings obverver pattern,  easy
View definition thanks to typed properties, it uses Qt  as backend, PyQt
Editor can be added...
ZODB brings a complete object database, stores objects in a file and use
the RAM as a cache.

To track object changes, ZODB persistent objects must subclass a C/C++
Persistent class. A no Persistent subclass can be persisted, but the
commit action can't know if objects change.

My conclusion was Traits idiom is not compatible with an object
persistent layer but rather a View layer.

This thread shows it is not so easy to determinate the place of Traits
in a ntiers layer data model application, persistence, model,
presentation...

Best Regards and thanks a lot for this great work,

Cyril.

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



--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
[hidden email]
[hidden email]

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

Re: Pure Python Traits Update

Chris Colbert
I was talking to Eric about this a couple nights ago, since I was recently neck deep in ctraits.c (which I believe is the only C-code in traits) for an unrelated thing. I think I may have a go at porting ctraits to pure Python this weekend. But don't quote me on that  :).


Chris

On Tue, Nov 16, 2010 at 2:27 PM, Brian Granger <[hidden email]> wrote:
A few comments about pure python traits:

* We (IPython devs) plan on maintaining the pure Python traits (traitlets) until a pure Python version of traits exists.
* We have talked to Eric and other Enthought folks about a pure Python version of traits.  They were open to the idea, but I 
think it is mostly a manpower/priority issue.
* Our motivation is that we want the core of IPython to be pure Python and to be portable easily to Jython and IronPython.
* It is possible to do multiple inheritance with PyQt and traitlets.  Here are some helper classes from IPython:


* If there are bugs in traitlets, please file an IPython issue on github:


Cheers,

Brian


On Tue, Nov 16, 2010 at 1:57 AM, Giraudon Cyril <[hidden email]> wrote:
Hello,

I've experienced the same issue but with the persistent layer.

I looked for modeling a huge object graph (often greater than the RAM
space of a classical PC).

Some tasks deal with a particular instance of the graph (edition) and
for some tasks the graph has to be analysed entirely.

I decided to use Traits for the business model (because I like Traits)
and ZODB for the persistent layer. Traits brings obverver pattern,  easy
View definition thanks to typed properties, it uses Qt  as backend, PyQt
Editor can be added...
ZODB brings a complete object database, stores objects in a file and use
the RAM as a cache.

To track object changes, ZODB persistent objects must subclass a C/C++
Persistent class. A no Persistent subclass can be persisted, but the
commit action can't know if objects change.

My conclusion was Traits idiom is not compatible with an object
persistent layer but rather a View layer.

This thread shows it is not so easy to determinate the place of Traits
in a ntiers layer data model application, persistence, model,
presentation...

Best Regards and thanks a lot for this great work,

Cyril.

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



--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
[hidden email]
[hidden email]

_______________________________________________
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: Pure Python Traits Update

Gael Varoquaux
On Fri, Dec 03, 2010 at 03:09:54PM -0600, Chris Colbert wrote:
>    I was talking to Eric about this a couple nights ago, since I was recently
>    neck deep in ctraits.c (which I believe is the only C-code in traits) for
>    an unrelated thing.�I think I may have a go at porting ctraits to pure
>    Python this weekend. But don't quote me on that �:).

Given how often-requested a feature it is, that would really be a great
news and might help traits adoption!

Once you have done, that, the next step is to replace the hand-crafted C
by Cythonizing your Python code, and we have improved maintanability and
portability to Python 3!

Gael

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

Re: Pure Python Traits Update

Ilan Schnell
Portability to 3 is a good point Gael.  Do you mention this
because you are eager to have Mayavi working on Py3k?

- Ilan

On Sat, Dec 4, 2010 at 3:53 AM, Gael Varoquaux
<[hidden email]> wrote:

> On Fri, Dec 03, 2010 at 03:09:54PM -0600, Chris Colbert wrote:
>>    I was talking to Eric about this a couple nights ago, since I was recently
>>    neck deep in ctraits.c (which I believe is the only C-code in traits) for
>>    an unrelated thing. I think I may have a go at porting ctraits to pure
>>    Python this weekend. But don't quote me on that  :).
>
> Given how often-requested a feature it is, that would really be a great
> news and might help traits adoption!
>
> Once you have done, that, the next step is to replace the hand-crafted C
> by Cythonizing your Python code, and we have improved maintanability and
> portability to Python 3!
>
> Gael
>
> _______________________________________________
> 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: Pure Python Traits Update

Gael Varoquaux
On Sat, Dec 04, 2010 at 11:07:52AM -0600, Ilan Schnell wrote:
> Portability to 3 is a good point Gael.  Do you mention this
> because you are eager to have Mayavi working on Py3k?

No. You made me laugh with that suggestion. I am so drowning under
various research and software commitments that I really don't have time
to worry about Mayavi for Python 3 in the near future.

Hopefully we will grow a team (in house, at Neurospin, and who knows,
with outside contributors? :>) in the near future and be able to tackle
this challenge.

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

Re: Pure Python Traits Update

Brian Granger
In reply to this post by Chris Colbert
Chris,

I was talking to Eric about this a couple nights ago, since I was recently neck deep in ctraits.c (which I believe is the only C-code in traits) for an unrelated thing. I think I may have a go at porting ctraits to pure Python this weekend. But don't quote me on that  :).


This would make us very happy!  Keep us posted.

Cheers,

Brian
 

Chris

On Tue, Nov 16, 2010 at 2:27 PM, Brian Granger <[hidden email]> wrote:
A few comments about pure python traits:

* We (IPython devs) plan on maintaining the pure Python traits (traitlets) until a pure Python version of traits exists.
* We have talked to Eric and other Enthought folks about a pure Python version of traits.  They were open to the idea, but I 
think it is mostly a manpower/priority issue.
* Our motivation is that we want the core of IPython to be pure Python and to be portable easily to Jython and IronPython.
* It is possible to do multiple inheritance with PyQt and traitlets.  Here are some helper classes from IPython:


* If there are bugs in traitlets, please file an IPython issue on github:


Cheers,

Brian


On Tue, Nov 16, 2010 at 1:57 AM, Giraudon Cyril <[hidden email]> wrote:
Hello,

I've experienced the same issue but with the persistent layer.

I looked for modeling a huge object graph (often greater than the RAM
space of a classical PC).

Some tasks deal with a particular instance of the graph (edition) and
for some tasks the graph has to be analysed entirely.

I decided to use Traits for the business model (because I like Traits)
and ZODB for the persistent layer. Traits brings obverver pattern,  easy
View definition thanks to typed properties, it uses Qt  as backend, PyQt
Editor can be added...
ZODB brings a complete object database, stores objects in a file and use
the RAM as a cache.

To track object changes, ZODB persistent objects must subclass a C/C++
Persistent class. A no Persistent subclass can be persisted, but the
commit action can't know if objects change.

My conclusion was Traits idiom is not compatible with an object
persistent layer but rather a View layer.

This thread shows it is not so easy to determinate the place of Traits
in a ntiers layer data model application, persistence, model,
presentation...

Best Regards and thanks a lot for this great work,

Cyril.

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



--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
[hidden email]
[hidden email]

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





--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
[hidden email]
[hidden email]

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

Re: Pure Python Traits Update

Chris Colbert
Just an update:

I made good progress over the weekend. I would guestimate ~70% of the way there. I am starting with just a straight C -> Python translation with 100% api compatibility. The resulting code is initially going to be ugly and slow. But once its there and works, I/we can iterate on it to make it faster and clean it up.

In particular there is some weird behavior in the low level traits which I'm not really happy with and would definitely like to change (maintaining the api of course). For example: 
In [40]: class Foo(HasTraits):
   ....:     a = Int
   ....:     
   ....:     

In [41]: f = Foo()

In [42]: f.__class__.__dict__['__class_traits__']
Out[42]: 
{'a': <enthought.traits.traits.CTrait object at 0x11b3920>,
 'trait_added': <enthought.traits.traits.CTrait object at 0x11b3818>,
 'trait_modified': <enthought.traits.traits.CTrait object at 0x162ba80>}

In [43]: f.b
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)

/Users/chris/<ipython console> in <module>()

AttributeError: 'Foo' object has no attribute 'b'

In [44]: f.__class__.__dict__['__class_traits__']
Out[44]: 
{'a': <enthought.traits.traits.CTrait object at 0x11b3920>,
 'b': <enthought.traits.traits.CTrait object at 0x14b95b0>,
 'trait_added': <enthought.traits.traits.CTrait object at 0x11b3818>,
 'trait_modified': <enthought.traits.traits.CTrait object at 0x162ba80>}



That's right, accessing a non-existant attribute will create and add a trait to the class dict. I know *why* traits does this, but I don't like it at all. And think its entirely possible to re-wire the traits lookup semantics to have equivalent behavior with the same api, but not do this wierdness. 

Cheers,

Chris

On Wed, Dec 8, 2010 at 9:27 AM, Brian Granger <[hidden email]> wrote:
Chris,

I was talking to Eric about this a couple nights ago, since I was recently neck deep in ctraits.c (which I believe is the only C-code in traits) for an unrelated thing. I think I may have a go at porting ctraits to pure Python this weekend. But don't quote me on that  :).


This would make us very happy!  Keep us posted.

Cheers,

Brian
 

Chris

On Tue, Nov 16, 2010 at 2:27 PM, Brian Granger <[hidden email]> wrote:
A few comments about pure python traits:

* We (IPython devs) plan on maintaining the pure Python traits (traitlets) until a pure Python version of traits exists.
* We have talked to Eric and other Enthought folks about a pure Python version of traits.  They were open to the idea, but I 
think it is mostly a manpower/priority issue.
* Our motivation is that we want the core of IPython to be pure Python and to be portable easily to Jython and IronPython.
* It is possible to do multiple inheritance with PyQt and traitlets.  Here are some helper classes from IPython:


* If there are bugs in traitlets, please file an IPython issue on github:


Cheers,

Brian


On Tue, Nov 16, 2010 at 1:57 AM, Giraudon Cyril <[hidden email]> wrote:
Hello,

I've experienced the same issue but with the persistent layer.

I looked for modeling a huge object graph (often greater than the RAM
space of a classical PC).

Some tasks deal with a particular instance of the graph (edition) and
for some tasks the graph has to be analysed entirely.

I decided to use Traits for the business model (because I like Traits)
and ZODB for the persistent layer. Traits brings obverver pattern,  easy
View definition thanks to typed properties, it uses Qt  as backend, PyQt
Editor can be added...
ZODB brings a complete object database, stores objects in a file and use
the RAM as a cache.

To track object changes, ZODB persistent objects must subclass a C/C++
Persistent class. A no Persistent subclass can be persisted, but the
commit action can't know if objects change.

My conclusion was Traits idiom is not compatible with an object
persistent layer but rather a View layer.

This thread shows it is not so easy to determinate the place of Traits
in a ntiers layer data model application, persistence, model,
presentation...

Best Regards and thanks a lot for this great work,

Cyril.

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



--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
[hidden email]
[hidden email]

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





--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
[hidden email]
[hidden email]


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

Re: Pure Python Traits Update

Eric Jones

On Dec 8, 2010, at 12:11 PM, Chris Colbert wrote:

Just an update:

I made good progress over the weekend. I would guestimate ~70% of the way there. I am starting with just a straight C -> Python translation with 100% api compatibility. The resulting code is initially going to be ugly and slow. But once its there and works, I/we can iterate on it to make it faster and clean it up.

In particular there is some weird behavior in the low level traits which I'm not really happy with and would definitely like to change (maintaining the api of course). For example: 
In [40]: class Foo(HasTraits):
   ....:     a = Int
   ....:     
   ....:     

In [41]: f = Foo()

In [42]: f.__class__.__dict__['__class_traits__']
Out[42]: 
{'a': <enthought.traits.traits.CTrait object at 0x11b3920>,
 'trait_added': <enthought.traits.traits.CTrait object at 0x11b3818>,
 'trait_modified': <enthought.traits.traits.CTrait object at 0x162ba80>}

In [43]: f.b
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)

/Users/chris/<ipython console> in <module>()

AttributeError: 'Foo' object has no attribute 'b'

In [44]: f.__class__.__dict__['__class_traits__']
Out[44]: 
{'a': <enthought.traits.traits.CTrait object at 0x11b3920>,
 'b': <enthought.traits.traits.CTrait object at 0x14b95b0>,
 'trait_added': <enthought.traits.traits.CTrait object at 0x11b3818>,
 'trait_modified': <enthought.traits.traits.CTrait object at 0x162ba80>}



That's right, accessing a non-existant attribute will create and add a trait to the class dict. I know *why* traits does this, but I don't like it at all. And think its entirely possible to re-wire the traits lookup semantics to have equivalent behavior with the same api, but not do this wierdness. 

Yep.  But, I wonder how much code actually relies on this...  I agree with you that it doesn't seem very good.  I wonder if we could raise a deprecation warning on this that pointed out which line number, etc. the access happened, and then remove the behavior in a future version.

eric



Cheers,

Chris

On Wed, Dec 8, 2010 at 9:27 AM, Brian Granger <[hidden email]> wrote:
Chris,

I was talking to Eric about this a couple nights ago, since I was recently neck deep in ctraits.c (which I believe is the only C-code in traits) for an unrelated thing. I think I may have a go at porting ctraits to pure Python this weekend. But don't quote me on that  :).


This would make us very happy!  Keep us posted.

Cheers,

Brian
 

Chris

On Tue, Nov 16, 2010 at 2:27 PM, Brian Granger <[hidden email]> wrote:
A few comments about pure python traits:

* We (IPython devs) plan on maintaining the pure Python traits (traitlets) until a pure Python version of traits exists.
* We have talked to Eric and other Enthought folks about a pure Python version of traits.  They were open to the idea, but I 
think it is mostly a manpower/priority issue.
* Our motivation is that we want the core of IPython to be pure Python and to be portable easily to Jython and IronPython.
* It is possible to do multiple inheritance with PyQt and traitlets.  Here are some helper classes from IPython:


* If there are bugs in traitlets, please file an IPython issue on github:


Cheers,

Brian


On Tue, Nov 16, 2010 at 1:57 AM, Giraudon Cyril <[hidden email]> wrote:
Hello,

I've experienced the same issue but with the persistent layer.

I looked for modeling a huge object graph (often greater than the RAM
space of a classical PC).

Some tasks deal with a particular instance of the graph (edition) and
for some tasks the graph has to be analysed entirely.

I decided to use Traits for the business model (because I like Traits)
and ZODB for the persistent layer. Traits brings obverver pattern,  easy
View definition thanks to typed properties, it uses Qt  as backend, PyQt
Editor can be added...
ZODB brings a complete object database, stores objects in a file and use
the RAM as a cache.

To track object changes, ZODB persistent objects must subclass a C/C++
Persistent class. A no Persistent subclass can be persisted, but the
commit action can't know if objects change.

My conclusion was Traits idiom is not compatible with an object
persistent layer but rather a View layer.

This thread shows it is not so easy to determinate the place of Traits
in a ntiers layer data model application, persistence, model,
presentation...

Best Regards and thanks a lot for this great work,

Cyril.

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



--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
[hidden email]
[hidden email]

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





--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
[hidden email]
[hidden email]

_______________________________________________
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: Pure Python Traits Update

Brian Granger
In reply to this post by Chris Colbert
Chris,

I made good progress over the weekend. I would guestimate ~70% of the way there. I am starting with just a straight C -> Python translation with 100% api compatibility. The resulting code is initially going to be ugly and slow. But once its there and works, I/we can iterate on it to make it faster and clean it up.


This is fantastic!
 
In particular there is some weird behavior in the low level traits which I'm not really happy with and would definitely like to change (maintaining the api of course). For example: 
In [40]: class Foo(HasTraits):
   ....:     a = Int
   ....:     
   ....:     

In [41]: f = Foo()

In [42]: f.__class__.__dict__['__class_traits__']
Out[42]: 
{'a': <enthought.traits.traits.CTrait object at 0x11b3920>,
 'trait_added': <enthought.traits.traits.CTrait object at 0x11b3818>,
 'trait_modified': <enthought.traits.traits.CTrait object at 0x162ba80>}

In [43]: f.b
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)

/Users/chris/<ipython console> in <module>()

AttributeError: 'Foo' object has no attribute 'b'

In [44]: f.__class__.__dict__['__class_traits__']
Out[44]: 
{'a': <enthought.traits.traits.CTrait object at 0x11b3920>,
 'b': <enthought.traits.traits.CTrait object at 0x14b95b0>,
 'trait_added': <enthought.traits.traits.CTrait object at 0x11b3818>,
 'trait_modified': <enthought.traits.traits.CTrait object at 0x162ba80>}


This is definitely not a good thing and it would be great to fix things like this.
 
That's right, accessing a non-existant attribute will create and add a trait to the class dict. I know *why* traits does this, but I don't like it at all. And think its entirely possible to re-wire the traits lookup semantics to have equivalent behavior with the same api, but not do this wierdness. 


I know of at least 1 other undesirable behavior in traits.  That is that default values are not validated:

In [3]: class Foo(HasTraits):
   ...:     a = Bool('a')
   ...:     

In [4]: f = Foo()

In [5]: f.a
Out[5]: 'a'

Ouch...

We do validate default values in traitlets, but it was non-trivial to get working and required changing the initialization model compared to traits.

Cheers,

Brian
 
Cheers,

Chris

On Wed, Dec 8, 2010 at 9:27 AM, Brian Granger <[hidden email]> wrote:
Chris,

I was talking to Eric about this a couple nights ago, since I was recently neck deep in ctraits.c (which I believe is the only C-code in traits) for an unrelated thing. I think I may have a go at porting ctraits to pure Python this weekend. But don't quote me on that  :).


This would make us very happy!  Keep us posted.

Cheers,

Brian
 

Chris

On Tue, Nov 16, 2010 at 2:27 PM, Brian Granger <[hidden email]> wrote:
A few comments about pure python traits:

* We (IPython devs) plan on maintaining the pure Python traits (traitlets) until a pure Python version of traits exists.
* We have talked to Eric and other Enthought folks about a pure Python version of traits.  They were open to the idea, but I 
think it is mostly a manpower/priority issue.
* Our motivation is that we want the core of IPython to be pure Python and to be portable easily to Jython and IronPython.
* It is possible to do multiple inheritance with PyQt and traitlets.  Here are some helper classes from IPython:


* If there are bugs in traitlets, please file an IPython issue on github:


Cheers,

Brian


On Tue, Nov 16, 2010 at 1:57 AM, Giraudon Cyril <[hidden email]> wrote:
Hello,

I've experienced the same issue but with the persistent layer.

I looked for modeling a huge object graph (often greater than the RAM
space of a classical PC).

Some tasks deal with a particular instance of the graph (edition) and
for some tasks the graph has to be analysed entirely.

I decided to use Traits for the business model (because I like Traits)
and ZODB for the persistent layer. Traits brings obverver pattern,  easy
View definition thanks to typed properties, it uses Qt  as backend, PyQt
Editor can be added...
ZODB brings a complete object database, stores objects in a file and use
the RAM as a cache.

To track object changes, ZODB persistent objects must subclass a C/C++
Persistent class. A no Persistent subclass can be persisted, but the
commit action can't know if objects change.

My conclusion was Traits idiom is not compatible with an object
persistent layer but rather a View layer.

This thread shows it is not so easy to determinate the place of Traits
in a ntiers layer data model application, persistence, model,
presentation...

Best Regards and thanks a lot for this great work,

Cyril.

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



--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
[hidden email]
[hidden email]

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





--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
[hidden email]
[hidden email]




--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
[hidden email]
[hidden email]

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

Re: Pure Python Traits Update

Brian Granger
In reply to this post by Eric Jones


On Wed, Dec 8, 2010 at 10:29 AM, Eric Jones <[hidden email]> wrote:

On Dec 8, 2010, at 12:11 PM, Chris Colbert wrote:

Just an update:

I made good progress over the weekend. I would guestimate ~70% of the way there. I am starting with just a straight C -> Python translation with 100% api compatibility. The resulting code is initially going to be ugly and slow. But once its there and works, I/we can iterate on it to make it faster and clean it up.

In particular there is some weird behavior in the low level traits which I'm not really happy with and would definitely like to change (maintaining the api of course). For example: 
In [40]: class Foo(HasTraits):
   ....:     a = Int
   ....:     
   ....:     

In [41]: f = Foo()

In [42]: f.__class__.__dict__['__class_traits__']
Out[42]: 
{'a': <enthought.traits.traits.CTrait object at 0x11b3920>,
 'trait_added': <enthought.traits.traits.CTrait object at 0x11b3818>,
 'trait_modified': <enthought.traits.traits.CTrait object at 0x162ba80>}

In [43]: f.b
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)

/Users/chris/<ipython console> in <module>()

AttributeError: 'Foo' object has no attribute 'b'

In [44]: f.__class__.__dict__['__class_traits__']
Out[44]: 
{'a': <enthought.traits.traits.CTrait object at 0x11b3920>,
 'b': <enthought.traits.traits.CTrait object at 0x14b95b0>,
 'trait_added': <enthought.traits.traits.CTrait object at 0x11b3818>,
 'trait_modified': <enthought.traits.traits.CTrait object at 0x162ba80>}



That's right, accessing a non-existant attribute will create and add a trait to the class dict. I know *why* traits does this, but I don't like it at all. And think its entirely possible to re-wire the traits lookup semantics to have equivalent behavior with the same api, but not do this wierdness. 

Yep.  But, I wonder how much code actually relies on this...  I agree with you that it doesn't seem very good.  I wonder if we could raise a deprecation warning on this that pointed out which line number, etc. the access happened, and then remove the behavior in a future version.

I think this makes sense.  Enthought has obviously built a lot of code on the current traits API.  It makes sense to be pretty conservative on the API side of traits.

Cheers,


Brian

 



Cheers,

Chris

On Wed, Dec 8, 2010 at 9:27 AM, Brian Granger <[hidden email]> wrote:
Chris,

I was talking to Eric about this a couple nights ago, since I was recently neck deep in ctraits.c (which I believe is the only C-code in traits) for an unrelated thing. I think I may have a go at porting ctraits to pure Python this weekend. But don't quote me on that  :).


This would make us very happy!  Keep us posted.

Cheers,

Brian
 

Chris

On Tue, Nov 16, 2010 at 2:27 PM, Brian Granger <[hidden email]> wrote:
A few comments about pure python traits:

* We (IPython devs) plan on maintaining the pure Python traits (traitlets) until a pure Python version of traits exists.
* We have talked to Eric and other Enthought folks about a pure Python version of traits.  They were open to the idea, but I 
think it is mostly a manpower/priority issue.
* Our motivation is that we want the core of IPython to be pure Python and to be portable easily to Jython and IronPython.
* It is possible to do multiple inheritance with PyQt and traitlets.  Here are some helper classes from IPython:


* If there are bugs in traitlets, please file an IPython issue on github:


Cheers,

Brian


On Tue, Nov 16, 2010 at 1:57 AM, Giraudon Cyril <[hidden email]> wrote:
Hello,

I've experienced the same issue but with the persistent layer.

I looked for modeling a huge object graph (often greater than the RAM
space of a classical PC).

Some tasks deal with a particular instance of the graph (edition) and
for some tasks the graph has to be analysed entirely.

I decided to use Traits for the business model (because I like Traits)
and ZODB for the persistent layer. Traits brings obverver pattern,  easy
View definition thanks to typed properties, it uses Qt  as backend, PyQt
Editor can be added...
ZODB brings a complete object database, stores objects in a file and use
the RAM as a cache.

To track object changes, ZODB persistent objects must subclass a C/C++
Persistent class. A no Persistent subclass can be persisted, but the
commit action can't know if objects change.

My conclusion was Traits idiom is not compatible with an object
persistent layer but rather a View layer.

This thread shows it is not so easy to determinate the place of Traits
in a ntiers layer data model application, persistence, model,
presentation...

Best Regards and thanks a lot for this great work,

Cyril.

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



--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
[hidden email]
[hidden email]

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





--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
[hidden email]
[hidden email]

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




--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
[hidden email]
[hidden email]

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

Re: Pure Python Traits Update

Satrajit Ghosh
In reply to this post by Brian Granger
hi brian and chris,

I know of at least 1 other undesirable behavior in traits.  That is that default values are not validated:

In [3]: class Foo(HasTraits):
   ...:     a = Bool('a')
   ...:     

In [4]: f = Foo()

In [5]: f.a
Out[5]: 'a'

Ouch...

I have used traitlets in the past and this was one specific feature that led us to drop traitlets and use traits. We needed to set our traits to a specific default or Undefined. And traitlets didn't allow Undefined as a default value.
 
We do validate default values in traitlets, but it was non-trivial to get working and required changing the initialization model compared to traits.

So I would be fine with validation of default values as long as Undefined was allowed as a possible default. I understand that we are just one use case, but i think the notion of Undefined for a trait can provide some useful semantics.

chris: we've run into a bunch of bugs with dynamic traits that we have worked around. i'd be happy to beta test, once you have a draft version ready.

cheers,

satra 



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

Re: Pure Python Traits Update

Chris Colbert
In reply to this post by Brian Granger


On Wed, Dec 8, 2010 at 4:42 PM, Brian Granger <[hidden email]> wrote:


On Wed, Dec 8, 2010 at 10:29 AM, Eric Jones <[hidden email]> wrote:

On Dec 8, 2010, at 12:11 PM, Chris Colbert wrote:

Just an update:

I made good progress over the weekend. I would guestimate ~70% of the way there. I am starting with just a straight C -> Python translation with 100% api compatibility. The resulting code is initially going to be ugly and slow. But once its there and works, I/we can iterate on it to make it faster and clean it up.

In particular there is some weird behavior in the low level traits which I'm not really happy with and would definitely like to change (maintaining the api of course). For example: 
In [40]: class Foo(HasTraits):
   ....:     a = Int
   ....:     
   ....:     

In [41]: f = Foo()

In [42]: f.__class__.__dict__['__class_traits__']
Out[42]: 
{'a': <enthought.traits.traits.CTrait object at 0x11b3920>,
 'trait_added': <enthought.traits.traits.CTrait object at 0x11b3818>,
 'trait_modified': <enthought.traits.traits.CTrait object at 0x162ba80>}

In [43]: f.b
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)

/Users/chris/<ipython console> in <module>()

AttributeError: 'Foo' object has no attribute 'b'

In [44]: f.__class__.__dict__['__class_traits__']
Out[44]: 
{'a': <enthought.traits.traits.CTrait object at 0x11b3920>,
 'b': <enthought.traits.traits.CTrait object at 0x14b95b0>,
 'trait_added': <enthought.traits.traits.CTrait object at 0x11b3818>,
 'trait_modified': <enthought.traits.traits.CTrait object at 0x162ba80>}



That's right, accessing a non-existant attribute will create and add a trait to the class dict. I know *why* traits does this, but I don't like it at all. And think its entirely possible to re-wire the traits lookup semantics to have equivalent behavior with the same api, but not do this wierdness. 

Yep.  But, I wonder how much code actually relies on this...  I agree with you that it doesn't seem very good.  I wonder if we could raise a deprecation warning on this that pointed out which line number, etc. the access happened, and then remove the behavior in a future version.

I think this makes sense.  Enthought has obviously built a lot of code on the current traits API.  It makes sense to be pretty conservative on the API side of traits.

Cheers,


I wouldn't really consider obj.__class__.__dict__['__class_traits__'] to be an api I could rely on ;)

I will certainly maintain 100% sensible api compatibility on this first cut (that includes functional behavior), but I wouldn't necessarily expect code that relies on the above behavior and accessing the __class_traits__ dict directly to continue working properly. I could be convinced otherwise, of course, if it breaks some critical code. But even then I would be inclined to fix the offending code.


 

Brian

 



Cheers,

Chris

On Wed, Dec 8, 2010 at 9:27 AM, Brian Granger <[hidden email]> wrote:
Chris,

I was talking to Eric about this a couple nights ago, since I was recently neck deep in ctraits.c (which I believe is the only C-code in traits) for an unrelated thing. I think I may have a go at porting ctraits to pure Python this weekend. But don't quote me on that  :).


This would make us very happy!  Keep us posted.

Cheers,

Brian
 

Chris

On Tue, Nov 16, 2010 at 2:27 PM, Brian Granger <[hidden email]> wrote:
A few comments about pure python traits:

* We (IPython devs) plan on maintaining the pure Python traits (traitlets) until a pure Python version of traits exists.
* We have talked to Eric and other Enthought folks about a pure Python version of traits.  They were open to the idea, but I 
think it is mostly a manpower/priority issue.
* Our motivation is that we want the core of IPython to be pure Python and to be portable easily to Jython and IronPython.
* It is possible to do multiple inheritance with PyQt and traitlets.  Here are some helper classes from IPython:


* If there are bugs in traitlets, please file an IPython issue on github:


Cheers,

Brian


On Tue, Nov 16, 2010 at 1:57 AM, Giraudon Cyril <[hidden email]> wrote:
Hello,

I've experienced the same issue but with the persistent layer.

I looked for modeling a huge object graph (often greater than the RAM
space of a classical PC).

Some tasks deal with a particular instance of the graph (edition) and
for some tasks the graph has to be analysed entirely.

I decided to use Traits for the business model (because I like Traits)
and ZODB for the persistent layer. Traits brings obverver pattern,  easy
View definition thanks to typed properties, it uses Qt  as backend, PyQt
Editor can be added...
ZODB brings a complete object database, stores objects in a file and use
the RAM as a cache.

To track object changes, ZODB persistent objects must subclass a C/C++
Persistent class. A no Persistent subclass can be persisted, but the
commit action can't know if objects change.

My conclusion was Traits idiom is not compatible with an object
persistent layer but rather a View layer.

This thread shows it is not so easy to determinate the place of Traits
in a ntiers layer data model application, persistence, model,
presentation...

Best Regards and thanks a lot for this great work,

Cyril.

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



--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
[hidden email]
[hidden email]

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





--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
[hidden email]
[hidden email]

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




--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
[hidden email]
[hidden email]

_______________________________________________
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
12