Making wxPython a standard module?

[Torsten Bronger]

Hallöchen!

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

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

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: torsten.bronger at jabber.rwth-aachen.de