Making wxPython a standard module?

[Grant Edwards]

On 2008-06-14, Torsten Bronger <bronger at physik.rwth-aachen.de> wrote:

>> [...]
>>
>> IMO, a few of the "un-Pythonic" things about wxPython are:
>>
>>  1) Window ID numbers.
>
> When I started to use wxPython, there was a newly-introduced
> wx.ID_ANY that you could give instead of -1.  My eyes filtered
> it out after a couple of hours, just as they do with "self".

Defining a new name for -1 is just painting the wart a
different color.

>> [...]
>>
>>  2) the "flags" parameter.
>
> Well, I like flags, and I don't see that they are unpythonic.  I
> find the code they produce very legible.

You're saying that having the user or-together a bunch of
bitmasks and pass the result as an integer is a common way for
Python functions/object allow the user to turn optional
features on and off?

You must be using a different Python than I am.  What I see
used for that in the standard library modules are either named
parameters with useful default values or individual object
attributes.  The only exceptions I can think are low level
routines in the "os" and "socket" modules that allow direct
access to things like Unix libc calls like open(), creat(),
read(), write() and to the BSD sockets API.

>> [...]
>>     
>>  3) the parent/child tree
>
> See wx.ID_ANY.

I don't see what the two have to do with each other, but maybe
that's the root of all my problems.

>> [...]
>>
>>  4) sizers
>
> Maybe because I come from TeX/LaTeX, i liked sizers
> immediately. They worked well for me.

I came from TeX/LaTeX also, and before wx, I spent a little
time using Trestle GUI widgets which follow the TeX
box-and-glue paradigm almost exactly.  I guess I don't find wx
sizers work much like TeX/LaTeX boxes.

>> [...]
>>
>>  5) binding
>>
>>       "What? you wanted a button that _did_ something when you
>>       clicked it?"
>
> You're right, this can be better.  There's too much explicitness.
> However, if you really hate the construct, you can define a
> shortcut.

I do.  I sub-class wx.Button.  Users should have to do that to
get basic functionality that's required in 99.999% of the
widget's use cases.  Explicit is fine if it serves a purpose. I
don't see the purpose of requiring a second line of code to
bind a button to a callable.

>> [...]
>>
>>  6) Thousands of wx.UPPER_CASE_INTEGER_HEX_CONSTANTS
>
> Thank you for the thorough explanations but in my opinion your
> points are minor.

They're minor in that they don't prevent you from writing
programs that work, but they're not minor in that they
unnecessarily increase the workload of the user without
providing any benefit.  They are sources of bugs.

> Additionally, most of them are a matter of taste. I don't
> think that because you didn't find sizers convenient, or some
> parts too explicit, you can say that wxWidgets is un-Pythonic.

Maybe a couple are just bad design decisions that weren't well
thought out rather than being "un-Pythonic".  OTOH, I consider
that being well thoght out and well designed is one of the
characteristics of Python, so things that aren't are un-Pythonic.

> I rather have the impression that you like terseness, which is
> totally okay but a different thing.

I think that the most common use cases should be handled with a
minimum of "extra" stuff having to be done by the user. It's
just not Pythonic to require a user to specify default values
for x,y,z when non-default valus for x,y,z are only used in 1
case out of 10000.  In Python you use named parameters with
default values.  You don't use positional parameters and then
tell the user "yes, I know this is useless almost all the time,
so just pass a -1 if you want the default behavior.  You
shouldn't have to specifically ask for default behavior.  You
should only have to ask for non-default behavior.

> I agree that changing the naming conventions and making use of
> properties would increase pythonicness, but on an already high
> level.

I guess my views on what is "pythonic" are a lot different.  I
also don't think it's at all surprising that a C++ library like
wxWidgets has an API that isn't very Pythonic.

-- 
Grant Edwards                   grante             Yow! I'm gliding over a
                                  at               NUCLEAR WASTE DUMP near
                               visi.com            ATLANTA, Georgia!!