Making wxPython a standard module?

Torsten Bronger bronger at
Sun Jun 15 00:59:48 CEST 2008


Grant Edwards writes:

> On 2008-06-14, Torsten Bronger <bronger at> 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.

We are talking about aesthetics.  There, colour matters.  ;-)

>>> [...]
>>>  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?

"Common" doesn't matter.  Legibility and practicality matter.  I
even use flags in an own module, although I "grew up" with Python
2.4.  I didn't see a better alternative.  The "a+" etc things in the
built-in open() function certainly are not.

> [...]
>>> [...]
>> 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. 

You can always do it shorter.  But I don't think that this is the
right approach for a good design.  After all, a wxPython with the
behaviour you described would not shrink source code by a
significant amount.

However, I find the resulting source code very much legible.  YMMV,
but again, this is then not a question of pythonicness.

> They are sources of bugs.

I don't think so.  What do you mean?  At least, I can only think of
bugs that would become obvious during the very first run.  (In other
words, mere spelling errors.)

> [...]
>> 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.

But wxPython does use keyword arguments and default values, just not
in all places you want it to be.

> [...]
>> 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.

I used to use C++ before I switched to Python, but I don't see any
C++ in wxPython.  If you don't like certain things, that's okay, but
please don't put the label "un-pythonic" on it because then only
very few modules out there are pythonic.  (And which ones even
depends on the beholder.)


Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: torsten.bronger at

More information about the Python-list mailing list