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