Good/Proper WxPython Architecture, Style, Operations & Practices

wxPython Users
1

Hello

I am looking for pointers on good WxPython Application architecture,
style, operations & practices. Would anyone be able to provide any
advice?

When I mean pointers & advice I mean:

- If I have an application that is just one window/frame with a series
of buttons & text controls("components"), what is considered better
practice, to group & place all these components on a main Panel, or on
a main Canvas, a main container(is there such a thing in WxPython), or
Nothing(if that is possible)?

- Is it bad practice to do this "from wx import *", is it better or
good coding style to do this instead "import wx"?

- Because functions in wxPython have the format ThisIsFunction() as
opposed to this_is_function(), should all my variable names &
functions be in that same format? Or do I follow normal python
standards & declare a variable "a_variable".

- Any advice for when coding large applications? For eg, split up the
application by components then have then interact w each other, so
make a MenuPanel (extension of a wx.Panel), TextDisplayCtrl(extension
of a wx.RichTextCtrl), etc.

2

- If I have an application that is just one window/frame with a series
of buttons& text controls("components"), what is considered better
practice, to group& place all these components on a main Panel, or on
a main Canvas, a main container(is there such a thing in WxPython), or
Nothing(if that is possible)?

To some extent this is platform dependent. Generally do this

Frame -> Panel -> Sizer -> Controls

- Is it bad practice to do this "from wx import *", is it better or
good coding style to do this instead "import wx"?

Do 'import wx'. The * import should only be done in extraordinary circumstances, IMHO. In wx it would result in a bazillion things getting added to the module namespace. You don't want that.

- Because functions in wxPython have the format ThisIsFunction() as
opposed to this_is_function(), should all my variable names&
functions be in that same format? Or do I follow normal python
standards& declare a variable "a_variable".

Use PEP8 standards for your own code. This actually has a nice side-effect of making wx calls visually distinct from calls to your own code.

- Any advice for when coding large applications? For eg, split up the
application by components then have then interact w each other, so
make a MenuPanel (extension of a wx.Panel), TextDisplayCtrl(extension
of a wx.RichTextCtrl), etc.

Separation of concerns. Decoupling of layers. Look at the MVC and MVO patterns.

But get busy coding. Too much time spent architecting is as bad as too little. It's a given that your first cut won't be optimal, don't sweat it.

Michael

···

On 8/31/2010 5:39 AM, Sascha wrote:

3

Hello

I am looking for pointers on good WxPython Application architecture,
style, operations & practices. Would anyone be able to provide any
advice?

When I mean pointers & advice I mean:

- If I have an application that is just one window/frame with a series
of buttons & text controls("components"), what is considered better
practice, to group & place all these components on a main Panel, or on
a main Canvas, a main container(is there such a thing in WxPython), or
Nothing(if that is possible)?

The panel widget is our canvas in most cases. For drawing, you'll be
using Device Contexts, cairo or FloatCanvas (probably)...we also
support OpenGL integration

- Is it bad practice to do this "from wx import *", is it better or
good coding style to do this instead "import wx"?

It's bad.

- Because functions in wxPython have the format ThisIsFunction() as
opposed to this_is_function(), should all my variable names &
functions be in that same format? Or do I follow normal python
standards & declare a variable "a_variable".

We have a style guide here: wxPython Style Guide - wxPyWiki

Note: I don't follow everything in there...remember, it's a guide, not
a law.

- Any advice for when coding large applications? For eg, split up the
application by components then have then interact w each other, so
make a MenuPanel (extension of a wx.Panel), TextDisplayCtrl(extension
of a wx.RichTextCtrl), etc.

I agree with Mr. Hipp. MVC or something similar will give you a guide.
If I have lots of dialogs, I put the dialogs into their file and
import them. If I have a notebook, I create the panels and the
necessary widgets in one or more files, depending on the complexity of
the panel.

There are many different ways to separate out the code. You'll have to
experiment to find the way you like best. I wrote something about
refactoring on my blog last year, but I don't think it impressed very
many...oh well.

···

On Aug 31, 5:39 am, Sascha <nill...@yahoo.com> wrote:

-------------------
Mike Driscoll

Blog: http://blog.pythonlibrary.org

4

Mike may have been a marketing issue and not a content issue.

Sascha, you might want to look at Peter Damoc's Python example of the
Model-View-Presentation OOP Pattern. Google it. I love this pattern.
However being a newbie, I've never been able to wrap my mind around a
multi-frame example of this pattern. The wx.Mainloop is in an
interesting place in the code. I like the pattern because it seems if
the programmer wanted to change and app's GUI without changing app
logic or structure it seems easier to do it with MVP. The MVP Python
example seems it would work well that if you needed to switch from
wxPython to wxGTK or Tinker that is could do this by changing the
"View" part of the pattern.

However I imagine the code structure or file breakdown depends mostly
on what the app does. For example, while learning Python and wxPython
I tried refactoring the wxPython demo into the MVP pattern (a task
still way over my head). In the wxPython demo's case this was a bad
pattern as the wx demo is a GUI demo (demo's the wx GUI) and not a
data centric or program-logic centric demo.

Another code structure that I love is the wx.demo itself. Its has a
pluggable architecture, meaning you can add modules to it easy enough.
Trimming the wxdemo down to it's basic runnable modules took me some
time but showed me some programming tricks (which I forget almost as
fast as I figure them out - brain damage issues - figuratively not
literally) in the process.

That's my 42 cents worth.

···

On Aug 31, 11:22 am, Mike Driscoll <kyoso...@gmail.com> wrote:

On Aug 31, 5:39 am, Sascha <nill...@yahoo.com> wrote:
I wrote something about refactoring on my blog last year,
but I don't think it impressed very many...oh well.
-------------------
Mike Driscoll