On 2008-06-14, Torsten Bronger <[EMAIL PROTECTED]> 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!! -- http://mail.python.org/mailman/listinfo/python-list