Making wxPython a standard module?

[Grant Edwards]

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

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

Yes it does.  "Common in Python" is what defines "Pythonic".

> Legibility and practicality matter.

Yes, but there are legible and practical ways to do things that
are not commonly (and not easily) used in Python programming
and are therefore un-Pythonic despite being legible and
practical.  With a little practice and care, functional
programming in prefix-notation (a-la Scheme) can both practical
and legible, but it still isn't Pythonic.

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

I agree that the "r" "w" "a" values passed to the open()
function are also un-Pythonic.  Like the unpythonic features in
wxPython, they're inherited directly from the underlying C/C++
library.  In the case of "a+" that comes from the standard
fopen() function.

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

"Pythonic" doesn't always mean shorter.  It means (IMO) things
like using optional parameters and object attributes to control
the optional behaviors of functions and objects.

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

Because certain flags are only to be used in certain contexts,
but there's no way to force (or even to indicate) that usage to
the user.  If you specify a flag that isn't applicable, it's
either ignored or misinterpreted without a warning.  If you try
to use a named parameter that doesn't exist, or an object
attribute that doesn't exist, you get an exception.  Whenever
possible, programming errors should cause exceptions or syntax
errors, not odd program behavior (that's another one of the
attributes I consider to be "Pythonic").

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

It does use them in some places, but I think it's too
inconsistent to be considered very "Pythonic".

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

The whole "flags" thing with a truckload of globally defined
integer constants competing for a single namespace is pure
C/C++.  Were wxWidgets written in Python, I guarantee that
wouldn't be the way it was done.

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

I'd say that the majority of the libraries I've used are
quite "Pythonic".

-- 
Grant Edwards                   grante             Yow!  I wonder if there's
                                  at               anything GOOD on tonight?
                               visi.com