Interfaces in wxPython

[Nitro]

Hello,

I'm coding on FloatCanvas, especially the model/view parts. For this I'd like to use interfaces. Each model has to declare an interface which it supports or the user has to provide an adapter for it. I don't want to reinvent the wheel, so I thought about using one of the already existing interface packages.
Personally I know zope.interface and like it. There's also the PEAK interface stuff, but it seems like PEAK is not very active.

Now I wonder whether something like zope.interface can be made part of wxPython/FloatCanvas. If yes, where should I place this package? Does anybody else see the need for an interface package within wxPython? Maybe the MVC soc project?

-Matthias

[Chris_Barker1]

Nitro wrote:

I'm coding on FloatCanvas, especially the model/view parts. For this I'd like to use interfaces.

Can you tell us why? My first thought is that interfaces are not very "pythonic" -- it's the nature of python that everything is dynamic.

I did just find this:

Python Interfaces are not Java Interfaces - dirtSimple.org

but haven't had a chance to read it closely yet.

That being said, I think enthought traits could be useful.

And we do want to be very careful about including any additional dependencies.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

[Nitro]

Nitro wrote:

I'm coding on FloatCanvas, especially the model/view parts. For this I'd like to use interfaces.

Can you tell us why? My first thought is that interfaces are not very "pythonic" -- it's the nature of python that everything is dynamic.

I think there are times when dynamic is great and when dynamic is not so great. In fc2 there are currently some basic models like Rectangle which holds a size. Now say a user has a House object. The House object has a my_size member. You want to have a view for this house so that the view draws the house as a rectangle as seen from the sky. Now you can do three things:

1) Create an fc Rectangle object from the House object
2) Write your own HouseView which is basically the same as a RectangleView
3) You write an adaptor which takes a House object and adapts it to an IRectangle interface which can be used with the default RectangleView

I think approach 3) has some advantages. You can edit your model directly, no need to convert to fc objects and back (shortcoming of method 1). You don't have to write custom views. For this you need an interface telling what IRectangle should provide (i.e. only a size property).
This could all be accomplished with duck typing, but imo Interfaces provide the better way to do the same thing. They document what we are expecting from the user.

That being said, I think enthought traits could be useful.

Ahh right. You mentioned it once before, but I couldn't recall/find this anymore. I'll take a look at this one, too.

And we do want to be very careful about including any additional dependencies.

Yes. Things like zope.interface can probably be compied directly into the FloatCanvas source tree, so there is no user-visible dependency.

-Matthias

···

Am 09.07.2008, 18:10 Uhr, schrieb Christopher Barker <Chris.Barker@noaa.gov>:

[Kevin_Ollivier3]

Hi Matthias,

Nitro wrote:

I'm coding on FloatCanvas, especially the model/view parts. For this I'd like to use interfaces.

Can you tell us why? My first thought is that interfaces are not very "pythonic" -- it's the nature of python that everything is dynamic.

I think there are times when dynamic is great and when dynamic is not so great. In fc2 there are currently some basic models like Rectangle which holds a size. Now say a user has a House object. The House object has a my_size member. You want to have a view for this house so that the view draws the house as a rectangle as seen from the sky. Now you can do three things:

1) Create an fc Rectangle object from the House object
2) Write your own HouseView which is basically the same as a RectangleView
3) You write an adaptor which takes a House object and adapts it to an IRectangle interface which can be used with the default RectangleView

I think approach 3) has some advantages. You can edit your model directly, no need to convert to fc objects and back (shortcoming of method 1). You don't have to write custom views. For this you need an interface telling what IRectangle should provide (i.e. only a size property).
This could all be accomplished with duck typing, but imo Interfaces provide the better way to do the same thing. They document what we are expecting from the user.

Of course, writing documentation also documents what we are expecting from the user. In the article Chris linked to, that's basically what the author says - every time he tried adding interfaces to a PEP, he found it just complicated things, because he ended up just using them for documentation. That meant building the interface, then converting the interface into documentation. He found it was an added step, and it was easier to just write the documentation directly.

That being said, I think enthought traits could be useful.

Ahh right. You mentioned it once before, but I couldn't recall/find this anymore. I'll take a look at this one, too.

Correct me if I'm wrong, but I thought this would be an even larger dependency. Plus I really dislike the fact that in the tutorial, it shows examples that make the view a property of the model. It surprises me how many people promote MVC, then go on to recommend breaking its fundamental tenet of separation between model and view, or point out that it's not really that important, because promoting that separation is its sole purpose for existing. Once you bind model to view, you are not using MVC any longer.

And we do want to be very careful about including any additional dependencies.

Yes. Things like zope.interface can probably be compied directly into the FloatCanvas source tree, so there is no user-visible dependency.

Actually, if we do bundle it, I think we ought to expose it to users. The reason not to bundle it is added maintenance. When zope.interface gets updated, do we update ours? Who will keep track of bug fixes, etc.? Also, if we end up modifying it for some reason, how do we handle merging? So it's not really just a drop it in and forget it sort of thing.

For example, I recently realized that in wxWidgets itself, our "bundled" zlib is 3 years old and contains security vulnerabilities. Of course, these issues aren't as common with Python code, but they can still happen.

BTW, I'm sorry to say the MVC SOC project has been dropped, so at least for now we don't need anything in that area.

Thanks,

Kevin

···

On Jul 9, 2008, at 10:45 AM, Nitro wrote:

Am 09.07.2008, 18:10 Uhr, schrieb Christopher Barker <Chris.Barker@noaa.gov > >:

-Matthias
_______________________________________________
wxpython-dev mailing list
wxpython-dev@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-dev

[Chris_Barker1]

I think there are times when dynamic is great and when dynamic is not so great. In fc2 there are currently some basic models like Rectangle which holds a size. Now say a user has a House object. The House object has a my_size member. You want to have a view for this house so that the view draws the house as a rectangle as seen from the sky. Now you can do three things:

1) Create an fc Rectangle object from the House object
2) Write your own HouseView which is basically the same as a RectangleView

why not subclass House from Rectangle, or use a Rectangle view for the House class's view, or use mixins?

Maybe I need to see a code example to see what you are getting at.

3) You write an adaptor which takes a House object and adapts it to an IRectangle interface which can be used with the default RectangleView

This sounds awkward to me, but even so, couldn't you write an adapter without format interfaces?

Of course, writing documentation also documents what we are expecting from the user. In the article Chris linked to, that's basically what the author says -

though he does say:
"""
if you're creating a framework, the situation is different. A framework is a library that calls the framework user's code. Now, somebody will be writing code that -- in effect -- is part of your library, and they need to know things about how their code will be called.
"""

I think FC may fall into the framework category, so there is something to be said for a formal specification.

One of the shortcomings of the current FC is that folks didn't seem to know that that could create their own drawobjects, and how easy it was. I've chalked that up to a lack of docs, and maybe interfaces would help, but as many Python programmers have never seen interfaces, we'd still need to document how to use the (PJE's point about the PEPs)

That being said, I think enthought traits could be useful.

Correct me if I'm wrong, but I thought this would be an even larger dependency.

Well, yes. though Enthought is working hard to re-factor their stuff so that pieces can be used independently more, like traits. it still may be big, though.

Plus I really dislike the fact that in the tutorial, it shows examples that make the view a property of the model.

Well, does that tell us anything about how traits can be used? or just that the tutorial writer didn't get MVC?

I'm attracted to traits because is seems to fit this use case well, and I like that we could use traits.ui to build a GUI to edit DrawObjects. I'm not looking forward to writing a bunch of dialogs, and why write a dialog generator, when that's what traits.ui already is? (the answer may be dependencies-- sigh)

Yes. Things like zope.interface can probably be compied directly into the FloatCanvas source tree, so there is no user-visible dependency.

Actually, if we do bundle it, I think we ought to expose it to users. The reason not to bundle it is added maintenance. When zope.interface gets updated, do we update ours? Who will keep track of bug fixes, etc.? Also, if we end up modifying it for some reason, how do we handle merging? So it's not really just a drop it in and forget it sort of thing.

I agree, bundling may be better than an external dependency, but it's still taking on substantial overhead.

BTW, I'm sorry to say the MVC SOC project has been dropped,

Darn, but maybe that means you'll have a bit more time to chime in on the other SoC projects!

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

[Nitro]

I think there are times when dynamic is great and when dynamic is not so great. In fc2 there are currently some basic models like Rectangle which holds a size. Now say a user has a House object. The House object has a my_size member. You want to have a view for this house so that the view draws the house as a rectangle as seen from the sky. Now you can do three things:

1) Create an fc Rectangle object from the House object
2) Write your own HouseView which is basically the same as a RectangleView

why not subclass House from Rectangle, or use a Rectangle view for the House class's view, or use mixins?

Because the user wrote the House class without thinking about the view. We can't expect him to change his model. You cannot use the rectangle view, because the rectangle view expects the House instance to have a size property, but it only has a my_size property. Hence the needed adapter.

3) You write an adaptor which takes a House object and adapts it to an IRectangle interface which can be used with the default RectangleView

This sounds awkward to me, but even so, couldn't you write an adapter without format interfaces?

Sure you can, but then you need to know that to adapt the House to a Rectangle you have to wrap my_size to size. You cannot know you need to adapt only "size" unless this is tediously documented in the Rectangle class' doc string. Imo the interfaces make all the required properties/apis of an object very obivous.
Additionally even if you don't need interfaces, you'd need a replacement for adapt().

Of course, writing documentation also documents what we are expecting from the user. In the article Chris linked to, that's basically what the author says -

though he does say:
"""
if you're creating a framework, the situation is different. A framework is a library that calls the framework user's code. Now, somebody will be writing code that -- in effect -- is part of your library, and they need to know things about how their code will be called.
"""

I think FC may fall into the framework category, so there is something to be said for a formal specification.

That was exactly my interpretation when I read this text. FloatCanvas can take any of the user's data. But fc needs this in a certain kind of way, each object it is fed has to obey an api. Fc and the user need to know how to interact with each other. Right now the size property of Rectangle is the only api, but I might add more, for example something like needsUpdating.

One of the shortcomings of the current FC is that folks didn't seem to know that that could create their own drawobjects, and how easy it was. I've chalked that up to a lack of docs, and maybe interfaces would help, but as many Python programmers have never seen interfaces, we'd still need to document how to use the (PJE's point about the PEPs)

Yes. I don't think you can compare fc to a PEP though. The PEPs I've read only deal with the description of the problem and its solution, but usually don't provide a detailed implementation. If you want to explain something, code is commonly not the best choice. Our users need to go beyond explanation and write an implementation though. And that's where interfaces come in handy imo.

Plus I really dislike the fact that in the tutorial, it shows examples that make the view a property of the model.

Well, does that tell us anything about how traits can be used? or just that the tutorial writer didn't get MVC?

I'm attracted to traits because is seems to fit this use case well, and I like that we could use traits.ui to build a GUI to edit DrawObjects. I'm not looking forward to writing a bunch of dialogs, and why write a dialog generator, when that's what traits.ui already is? (the answer may be dependencies-- sigh)

I am using lots of 3rd party libraries in the 3d engine/toolchain I wrote. I've been bitten several times by libraries which became unmaintained or suffered other things. On the other hand I use some libraries which really make my life easier. So I am torn about dependencies and would like to leave this choice to the main maintainers/developers of wxPython since they'll be the ones bitten when in doubt.

Yes. Things like zope.interface can probably be compied directly into the FloatCanvas source tree, so there is no user-visible dependency.

Actually, if we do bundle it, I think we ought to expose it to users. The reason not to bundle it is added maintenance. When zope.interface gets updated, do we update ours? Who will keep track of bug fixes, etc.? Also, if we end up modifying it for some reason, how do we handle merging? So it's not really just a drop it in and forget it sort of thing.

I agree, bundling may be better than an external dependency, but it's still taking on substantial overhead.

Yes.

BTW, I'm sorry to say the MVC SOC project has been dropped,

Ahh, what a pity. I thought this was actually one of the things which could put wxPython a very huge step forward.

-Matthias

···

Am 09.07.2008, 22:52 Uhr, schrieb Christopher Barker <Chris.Barker@noaa.gov>:

[Nitro]

Of course, writing documentation also documents what we are expecting from the user. In the article Chris linked to, that's basically what the author says - every time he tried adding interfaces to a PEP, he found it just complicated things, because he ended up just using them for documentation. That meant building the interface, then converting the interface into documentation. He found it was an added step, and it was easier to just write the documentation directly.

Yes. PEPs and fc are different cases though imo. Also see my other post for my reasoning, especially adaption.

Correct me if I'm wrong, but I thought this would be an even larger dependency. Plus I really dislike the fact that in the tutorial, it shows examples that make the view a property of the model. It surprises me how many people promote MVC, then go on to recommend breaking its fundamental tenet of separation between model and view, or point out that it's not really that important, because promoting that separation is its sole purpose for existing. Once you bind model to view, you are not using MVC any longer.

I'll look at the traits package tomorrow and tell if I can spot any obvious problems with its MVC approach. Maybe it's just a bad tutorial as Chris pointed out.

And we do want to be very careful about including any additional dependencies.

Yes. Things like zope.interface can probably be compied directly into the FloatCanvas source tree, so there is no user-visible dependency.

Actually, if we do bundle it, I think we ought to expose it to users. The reason not to bundle it is added maintenance. When zope.interface gets updated, do we update ours? Who will keep track of bug fixes, etc.? Also, if we end up modifying it for some reason, how do we handle merging? So it's not really just a drop it in and forget it sort of thing.

Agreed. It would probably need to updated from time to time (for example when python changes to 3.0). Custom code would suffer the same problem though. Plus custom code is likely less tested and maintained than zope.interface which is used in Twisted for instance. Just take pubsub as an example where I spotted a bug when I was using it for the first time.
On the other hand if they decided to abandon zope.interface we might be stuck and unable to maintain it.

Maybe there should be some separate layer for this kinds of things. It's impossible to build applications full of features in reasonable time without resorting to external libraries. This doesn't fall into wxPython's core gui-related capabilities, so my proposal of a layer around it.

Maybe wxPython should advance a step and become a "framework". Things like MVC wrappers around its widgets fall into this category. If you want things like myListBox.model = myListOfHouseObjects to work, you'll face similar problems. Somebody also proposed a huge sample application as a soc project a while back. This could probably be part of the framework layer where there's a basic skeleton (or multiple types of them) of an application that users can plug into.

So "Dependencies or no dependencies, that is the question". I'll leave this to you

-Matthias

···

Am 09.07.2008, 20:49 Uhr, schrieb Kevin Ollivier <kevino@theolliviers.com>:

[Nitro]

Hi Kevin,

That being said, I think enthought traits could be useful.

Ahh right. You mentioned it once before, but I couldn't recall/find this anymore. I'll take a look at this one, too.

Correct me if I'm wrong, but I thought this would be an even larger dependency. Plus I really dislike the fact that in the tutorial, it shows examples that make the view a property of the model. It surprises me how many people promote MVC, then go on to recommend breaking its fundamental tenet of separation between model and view, or point out that it's not really that important, because promoting that separation is its sole purpose for existing. Once you bind model to view, you are not using MVC any longer.

I've reviewed Enthought Traits now and I can't find the place where the view is bound to the model. Here's one example they provide: https://svn.enthought.com/enthought/wiki/Traits_2_1_model_view .
All in all I think traits makes life a lot easier, at the cost of maybe a bit too much "black magic". All those _get_* methods don't look too intuitive at first. On the other hand I really like things like the depends_on facility. This allows to setup a typical data model in a more natural and complete way. It's not just an accumulation of properties, but more like a database scheme where you can specify the relations between data as well.
I also think the interface/adaption part is ok. So I don't mind which package to use (if any).

A little addendum to yesterday: I think bundling is probably better than making the user download the dependency himself. This avoids any versioning issues. Our code is written against a specific version of the external package and if the user downloads the package he might get a different version depending what his distro offers for example. Version clashes probably create even bigger problems than maintaining a bundled package.

-Matthias

···

Am 09.07.2008, 20:49 Uhr, schrieb Kevin Ollivier <kevino@theolliviers.com>:

[Nitro]

Hello again

In addition to interfaces and adaption, I am probably going to use other patterns such as the Factory or the Null ones. Do you think wxPython should get some folder like wx.lib.patterns where we can store all those commonly used ones? Or do you think this should be kept per-application (in this case private to fc)?
One the one hand most users probably roll their own versions of them and thus don't need the wx ones. On the other hand if most people using wxPython shared the same ones we could all interchange and understand each others code more easily.

-Matthias

[Kevin_Ollivier3]

Hi Matthias,

Hi Kevin,

That being said, I think enthought traits could be useful.

Ahh right. You mentioned it once before, but I couldn't recall/find this anymore. I'll take a look at this one, too.

Correct me if I'm wrong, but I thought this would be an even larger dependency. Plus I really dislike the fact that in the tutorial, it shows examples that make the view a property of the model. It surprises me how many people promote MVC, then go on to recommend breaking its fundamental tenet of separation between model and view, or point out that it's not really that important, because promoting that separation is its sole purpose for existing. Once you bind model to view, you are not using MVC any longer.

I've reviewed Enthought Traits now and I can't find the place where the view is bound to the model. Here's one example they provide: https://svn.enthought.com/enthought/wiki/Traits_2_1_model_view .

To be honest, I think I'm getting confused by these docs. I think what it is is that I don't understand exactly how ModelView works - the docs suggest that it effectively works as a model, with a view as a property of that model, which breaks MVC. (They also say using Controller is what you want to build proper MVC but I don't see an example of it to compare them.) However, I think there's some black magic to the whole family = Property( List ) stuff that I don't get, in terms of what it does to the model. Also, other examples seem to clearly go on to merge model and view together, such as:

https://svn.enthought.com/enthought/wiki/Traits_2_1_ie_html

This example really looks like the model and view are hopelessly mixed together. The WebPage class contains a url, buttons, and a web browser. Every time you create a new URL, you create a new WebPage, but I suspect that doesn't create a new View, as it would be a total mess if it did that. To me, how all this works is not at all clear.

So yes, you probably can actually produce proper MVC apps with traits, it's just that most of their examples don't do so (or, their docs say they don't, I can't really say for sure ;-), and that their code is filled with a bunch of abstract terminology that's hard to understand without taking a solid look at their docs. If Sizers taught me anything, it's that abstraction layers that require you to wrap your head around how they work first basically become a hard sell to users. They'll try to avoid them until it's no longer possible because the learning curve makes it unappealing. If your framework is too dense, you could just further discourage people from creating their own extensions.

For me personally, it'd probably take less time to write my own lightweight MVC wrappers than it would be to grok this framework. (MVC is basically about setting up listeners and sending state changes, which I don't think is going to require thousands of lines of code or heavy abstraction layers to accomplish.) Even if this is included as a core part of wxPython, I'll probably do the same thing, just to have something more straightforward and intuitive to work with.

All in all I think traits makes life a lot easier, at the cost of maybe a bit too much "black magic". All those _get_* methods don't look too intuitive at first. On the other hand I really like things like the depends_on facility. This allows to setup a typical data model in a more natural and complete way. It's not just an accumulation of properties, but more like a database scheme where you can specify the relations between data as well.
I also think the interface/adaption part is ok. So I don't mind which package to use (if any).

A little addendum to yesterday: I think bundling is probably better than making the user download the dependency himself. This avoids any versioning issues. Our code is written against a specific version of the external package and if the user downloads the package he might get a different version depending what his distro offers for example. Version clashes probably create even bigger problems than maintaining a bundled package.

We'd pretty much have to bundle, unless this is somehow an optional part of FloatCanvas. Does anyone yet know how much traits would add to wxPython?

Thanks,

Kevin

···

On Jul 10, 2008, at 10:11 AM, Nitro wrote:

Am 09.07.2008, 20:49 Uhr, schrieb Kevin Ollivier <kevino@theolliviers.com > >:

-Matthias
_______________________________________________
wxpython-dev mailing list
wxpython-dev@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-dev

[Nitro]

Hi Kevin,

To be honest, I think I'm getting confused by these docs. I think what it is is that I don't understand exactly how ModelView works - the docs suggest that it effectively works as a model, with a view as a property of that model, which breaks MVC. (They also say using Controller is what you want to build proper MVC but I don't see an example of it to compare them.) However, I think there's some black magic to the whole family = Property( List ) stuff that I don't get, in terms of what it does to the model. Also, other examples seem to clearly go on to merge model and view together, such as:

https://svn.enthought.com/enthought/wiki/Traits_2_1_ie_html

This example really looks like the model and view are hopelessly mixed together. The WebPage class contains a url, buttons, and a web browser. Every time you create a new URL, you create a new WebPage, but I suspect that doesn't create a new View, as it would be a total mess if it did that. To me, how all this works is not at all clear.

Ok, I agree with you that in both of the examples (mine and yours) they mix view with model. In the children/parents/family example they add the view to the class which holds the family model. That's not good. Maybe it's possible to create another Family class and then make the view work on that with the methods shown here ( https://svn.enthought.com/enthought/wiki/Traits_2_1_items ).
I don't like their way of creating the view a lot, imo it's ugly. Creating models seems to be elegant though.

So yes, you probably can actually produce proper MVC apps with traits, it's just that most of their examples don't do so (or, their docs say they don't, I can't really say for sure ;-), and that their code is filled with a bunch of abstract terminology that's hard to understand without taking a solid look at their docs. If Sizers taught me anything, it's that abstraction layers that require you to wrap your head around how they work first basically become a hard sell to users. They'll try to avoid them until it's no longer possible because the learning curve makes it unappealing. If your framework is too dense, you could just further discourage people from creating their own extensions.

I guess you are right in saying this will scare people away.

For me personally, it'd probably take less time to write my own lightweight MVC wrappers than it would be to grok this framework. (MVC is basically about setting up listeners and sending state changes, which I don't think is going to require thousands of lines of code or heavy abstraction layers to accomplish.) Even if this is included as a core part of wxPython, I'll probably do the same thing, just to have something more straightforward and intuitive to work with.

Yes, MVC in its bare essentials is what you say. On the other hand traits aims to be more, it has rules that take the interdependencies between data into account ( depends_on , https://svn.enthought.com/enthought/wiki/Traits_2_1_properties ), validation ( https://svn.enthought.com/enthought/wiki/Traits_2_1_new_types ) and ultimately wants to provide some basic scheme language for data types ( same link as the one before ) with a runtime to ensure the specifiations are held at all times.
The MVC part actually seems more like side-product of their data management approach. It seems to be a bit easier to catch certain events, because you don't have to connect to/unconnect them. The according methods are called directly. Of course this can also be a disadvantage sometimes.

Right now I don't need the whole traits package as the basic data models for fc are very simple. Creating more complex models is up to the user and I don't mind how he does this, because he'll has to write his own views/adapters for those models in any case. I'd only need Interface and Adaption for now. MVC event sending is handled via a wrapper around pubsub at this time.

-Matthias

···

Am 10.07.2008, 20:11 Uhr, schrieb Kevin Ollivier <kevino@theolliviers.com>:

[Kevin_Ollivier3]

Hi Matthias,

Hi Kevin,

To be honest, I think I'm getting confused by these docs. I think what it is is that I don't understand exactly how ModelView works - the docs suggest that it effectively works as a model, with a view as a property of that model, which breaks MVC. (They also say using Controller is what you want to build proper MVC but I don't see an example of it to compare them.) However, I think there's some black magic to the whole family = Property( List ) stuff that I don't get, in terms of what it does to the model. Also, other examples seem to clearly go on to merge model and view together, such as:

https://svn.enthought.com/enthought/wiki/Traits_2_1_ie_html

This example really looks like the model and view are hopelessly mixed together. The WebPage class contains a url, buttons, and a web browser. Every time you create a new URL, you create a new WebPage, but I suspect that doesn't create a new View, as it would be a total mess if it did that. To me, how all this works is not at all clear.

Ok, I agree with you that in both of the examples (mine and yours) they mix view with model. In the children/parents/family example they add the view to the class which holds the family model. That's not good. Maybe it's possible to create another Family class and then make the view work on that with the methods shown here ( https://svn.enthought.com/enthought/wiki/Traits_2_1_items ).
I don't like their way of creating the view a lot, imo it's ugly. Creating models seems to be elegant though.

I don't find it that elegant, personally. Then again, I think elegant is hard to objectively define, so maybe it's better to say I don't find it very intuitive and easy to read, having HasTraits and Instance() and Delegate() stuff sprinkled all over it. I can see cases where it might be necessary to work with a framework like this (e.g. complex data relationships), but it's the kind of framework I'd only consider once I knew it'd save me from writing a whole lot of code. (e.g. far more than a few hundred lines)

So yes, you probably can actually produce proper MVC apps with traits, it's just that most of their examples don't do so (or, their docs say they don't, I can't really say for sure ;-), and that their code is filled with a bunch of abstract terminology that's hard to understand without taking a solid look at their docs. If Sizers taught me anything, it's that abstraction layers that require you to wrap your head around how they work first basically become a hard sell to users. They'll try to avoid them until it's no longer possible because the learning curve makes it unappealing. If your framework is too dense, you could just further discourage people from creating their own extensions.

I guess you are right in saying this will scare people away.

For me personally, it'd probably take less time to write my own lightweight MVC wrappers than it would be to grok this framework. (MVC is basically about setting up listeners and sending state changes, which I don't think is going to require thousands of lines of code or heavy abstraction layers to accomplish.) Even if this is included as a core part of wxPython, I'll probably do the same thing, just to have something more straightforward and intuitive to work with.

Yes, MVC in its bare essentials is what you say. On the other hand traits aims to be more, it has rules that take the interdependencies between data into account ( depends_on , https://svn.enthought.com/enthought/wiki/Traits_2_1_properties ), validation ( https://svn.enthought.com/enthought/wiki/Traits_2_1_new_types ) and ultimately wants to provide some basic scheme language for data types ( same link as the one before ) with a runtime to ensure the specifiations are held at all times.

The MVC part actually seems more like side-product of their data management approach.

Yes, I'd agree with this. I think traits is really all about auto-generating code for you to handle complex data relationships and forms easily. It just seems to me we're basically using it not because we need those things in a majority of scenarios, but because it happens to have some classes for specifying interfaces (which is probably a tiny part of the actual traits code). I think Trac also has something for this, and if we look we can probably find about a half-dozen other Interface classes out there.

It seems to be a bit easier to catch certain events, because you don't have to connect to/unconnect them. The according methods are called directly. Of course this can also be a disadvantage sometimes.

Exactly. Personally, although maybe this is because I'm a fast typist ;-), I'm a big believer in the Python philosophy of "explicit is better than implicit". Reducing tedious coding has its advantages, but get too abstract and it becomes hard to even keep track of what the code is doing when you read it.

Right now I don't need the whole traits package as the basic data models for fc are very simple. Creating more complex models is up to the user and I don't mind how he does this, because he'll has to write his own views/adapters for those models in any case. I'd only need Interface and Adaption for now. MVC event sending is handled via a wrapper around pubsub at this time.

Well, I still feel Interface is mainly a documentation tool, and the functionality of Adapters can be easily gained by just having users derive from a base class with a stub implementation. Anyway, I'd recommend first trying to integrate traits into wxPython and seeing how simple or complex it is, and what the added dependencies are. If it's just dropping in a few .py files, we can always try it and switch later, but the bigger and heavier it is (e.g. will we need C++ extensions?), the more seriously we'll have to think about the added maintenance and added bulk to the build process.

FWIW, I think just writing unit tests is a much better way of making sure your code and interfaces are correct. That way, you're not just testing that the interface is correctly specified (which you are doing whether you create an Interface framework or a unit test), but you're also testing that the interface works as it should. To paraphrase a quote I read from somewhere (I wish I could remember where!): "other languages focus on making sure you don't do something wrong, but Python's focus is on making sure you do it right". In other words, Python code tends not to worry about formalized constructs and structure so much - it just encourages you to unit test your code so that, however your code is implemented under the hood, you know that it is doing what it is supposed to do. In my experience, things like interface errors are usually pretty easily caught and fixed because the function will either not exist, or will not take the right arguments, etc.

Thanks,

Kevin

···

On Jul 10, 2008, at 11:48 AM, Nitro wrote:

Am 10.07.2008, 20:11 Uhr, schrieb Kevin Ollivier <kevino@theolliviers.com > >:

-Matthias
_______________________________________________
wxpython-dev mailing list
wxpython-dev@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-dev