[wxpython-dev] Interfaces in wxPython

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:

http://dirtsimple.org/2004/12/python-interfaces-are-not-java.html

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

[email protected]
_______________________________________________
wxpython-dev mailing list
[email protected]
http://lists.wxwidgets.org/mailman/listinfo/wxpython-dev

Am 09.07.2008, 18:10 Uhr, schrieb Christopher Barker
<[email protected]>:

> 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
_______________________________________________
wxpython-dev mailing list
[email protected]
http://lists.wxwidgets.org/mailman/listinfo/wxpython-dev

Hi Matthias,

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

> Am 09.07.2008, 18:10 Uhr, schrieb Christopher Barker <[email protected]
> >:
>
>> 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

>
> -Matthias
> _______________________________________________
> wxpython-dev mailing list
> [email protected]
> http://lists.wxwidgets.org/mailman/listinfo/wxpython-dev

_______________________________________________
wxpython-dev mailing list
[email protected]
http://lists.wxwidgets.org/mailman/listinfo/wxpython-dev

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

[email protected]
_______________________________________________
wxpython-dev mailing list
[email protected]
http://lists.wxwidgets.org/mailman/listinfo/wxpython-dev