Making wxPython a standard module?
bronger at physik.rwth-aachen.de
Sun Jun 15 00:59:48 CEST 2008
Grant Edwards writes:
> 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
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.
>>> 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.
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
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
> 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 jabber.rwth-aachen.de
More information about the Python-list