Making wxPython a standard module?
John Salerno
what happened with sqlite)? I read somewhere that Guido said the only reason
Tkinter is still the standard GUI module instead of wxPython is because "it
was there first." Perhaps a joke, but it got me thinking that there could be
a chance of this happening.
I'm sure most Python work doesn't involve GUIs, so it's not a priority, but
to have wxPython be a standard module would be great, and it might even
encourage people to play around with GUI work more than normal (I don't
think that's a bad thing!). :)
Diez B. Roggisch
> like what happened with sqlite)? I read somewhere that Guido said the only
> reason Tkinter is still the standard GUI module instead of wxPython is
> because "it was there first." Perhaps a joke, but it got me thinking that
> there could be a chance of this happening.
This has been discussed before. While tkInter might not be the greatest
toolkit out there it has two extreme advantages:
- it is comparably small regarding the footprint. Few external
dependencies, small libraries, small python-wrapping.
- it is available on a wide range of platforms.
- it is very stable, not only wrt bugs but also regarding features. There
is no external pressure to update it frequently.
- it is easily maintainable.
None of these apply to wx. It is huge, needs for example the whole GTK-libs
under linux. It is under active development, with rather frequent releases,
which means it is better to not tie it to a certain version because that
happens to be the version available when the current interpreter was
released.
For example, think of python2.4 - it has been released 4(!) years ago. It is
in wide usage. Around that time wx was at version 2.5. Now it is 2.8. So
either you upgrade wx in the subsequent released pyhton 2.4 versions - or
you are stuck with 3 minor revisions in the past, which I can only assume
are a major drawback.
And on a personal note: I find it *buttugly*. But that has nothing to do
with the reasons given above - nor do I have any weight in the decision to
include it or not... :)
Diez
Paul Boddie
> Just out of curiosity, what are the chances of this happening (sort of like
> what happened with sqlite)?
Plenty of prior discussion here:
I doubt that the situation has changed in any significant way.
Paul
Andrea Gavana
> And on a personal note: I find it *buttugly*.
Do you mind explaining "why" you find it *buttugly*? I am asking just
out of curiosity, obviously. I am so biased towards wxPython that I
won't make any comment on this thread in particular, but I am curious
to know why some people find it "ugly" or "bad" or whatever. It has
its own bugs and missing features, of course, but it is one of the
major GUI player in the arena, together with PyQt and PyGTK.
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
Mike Driscoll
I'm curious too. I like wxPython because the widgets actually "look"
the way they should in a cross-platform way (for the most part)
because they use the actual widgets sets of the OS. Tkinter draws
everything and can look kind of weird on Windows, although I have seen
some very nice looking programs that use it.
Of course, wx doesn't really do "skinning", so in that respect it may
be hampered more than some of the other toolkits that Andrea
mentioned. I really don't know.
-------------------
Mike Driscoll
Blog: http://blog.pythonlibrary.org
Python Extension Building Network: http://www.pythonlibrary.org
John Salerno
news:6bcqtpF...@mid.uni-berlin.de...
> This has been discussed before. While tkInter might not be the greatest
> toolkit out there it has two extreme advantages:
>
> - it is comparably small regarding the footprint. Few external
> dependencies, small libraries, small python-wrapping.
>
> - it is available on a wide range of platforms.
>
> - it is very stable, not only wrt bugs but also regarding features.
> There
> is no external pressure to update it frequently.
>
> - it is easily maintainable.
Ok, that was more than two advantages! :) But those are good points. I was
wondering about the size of wx too. Probably huge compared to Tkinter.
> And on a personal note: I find it *buttugly*. But that has nothing to do
> with the reasons given above - nor do I have any weight in the decision to
> include it or not... :)
You find what ugly? The look of wxPython apps, or the code itself? To me it
seems very nice, but what do I know! I also have started using XRC (putting
the GUI in an xml file instead of in the program), so I see less of the code
clutter my program.
Ed Leafe
>> And on a personal note: I find it *buttugly*.
>
> Do you mind explaining "why" you find it *buttugly*? I am asking just
> out of curiosity, obviously. I am so biased towards wxPython that I
> won't make any comment on this thread in particular, but I am curious
> to know why some people find it "ugly" or "bad" or whatever. It has
> its own bugs and missing features, of course, but it is one of the
> major GUI player in the arena, together with PyQt and PyGTK.
Perhaps he meant the code, and not the results?
-- Ed Leafe
Andrea Gavana
Maybe. But I remember a nice quote made in the past by Roger Binns (4
years ago):
"""
The other thing I failed to mention is that the wxPython API isn't very
Pythonic. (This doesn't matter to people like me who are used to GUI
programming - the wxPython API is very much in the normal style for GUI
APIs.)
"""
Whether the wxPython style is "Pythonic" or not (whatever "Pythonic"
means), this is a one-degree-above-insignificant issue for me. What I
care is the eye pleasing look of my apps and how easy it is to code
with a GUI framework. wxPython gives me both, the rest is just
academic discussion.
But I don't want to start another GUI war, let's save the bandwidth...
there are plenty of GUI frameworks around, every newbie in the GUI
world should try them and stick with the one he/she feels more
confortable with.
bearoph...@lycos.com
> Maybe. But I remember a nice quote made in the past by Roger Binns (4
> years ago):
> """
> The other thing I failed to mention is that the wxPython API isn't very
> Pythonic. (This doesn't matter to people like me who are used to GUI
> programming - the wxPython API is very much in the normal style for GUI
> APIs.)
> """
There was a WX wrapper project named WAX (http://zephyrfalcon.org/
waxapi/wx._core.Image.html ) that was trying to create a more pythonic
API for WX that I have appreciated. But most people was not
interested, so once the original developer has lost interest, no one
else has improved the code, so the project has died...
Bye,
bearophile
David C. Ullrich
"Andrea Gavana" <andrea...@gmail.com> wrote:
> Hi Diez & All,
>
> > And on a personal note: I find it *buttugly*.
>
> Do you mind explaining "why" you find it *buttugly*?
My guess would be that "buttugly" is a colloquialism
meaning "exquisitely lovely".
>I am asking just
> out of curiosity, obviously. I am so biased towards wxPython that I
> won't make any comment on this thread in particular, but I am curious
> to know why some people find it "ugly" or "bad" or whatever. It has
> its own bugs and missing features, of course, but it is one of the
> major GUI player in the arena, together with PyQt and PyGTK.
>
> Andrea.
>
> "Imagination Is The Only Weapon In The War Against Reality."
> http://xoomer.alice.it/infinity77/
--
David C. Ullrich
John Salerno
news:mailman.374.1213285...@python.org...
> Whether the wxPython style is "Pythonic" or not (whatever "Pythonic"
> means), this is a one-degree-above-insignificant issue for me. What I
> care is the eye pleasing look of my apps and how easy it is to code
> with a GUI framework. wxPython gives me both, the rest is just
> academic discussion.
Don't worry, I love wxPython with an almost disturbing intensity! ;)
"Martin v. Löwis"
> what happened with sqlite)?
As a starting point, the author(s) of wxPython would need to contribute
it to Python (and then also give the PSF the permission to relicense
it). If no such contribution is made, chances are zero. Somebody else
contributing it in place of the authors is not acceptable - that
somebody likely doesn't have the right to grant the proper license to
the PSF, and it would also meant that the in-core version of wxPython
forked from the official version, which would be unacceptable.
In addition, a group of people (not necessarily the authors) would have
to offer maintaining the in-core copy of wxPython, in the sense of
keeping it synchronized with the stand-alone release, resolving bug
reports related to the library (in particular wrt. portability), and
so on. Again, with nobody offering maintenance, chances are again zero.
For sqlite, both conditions were met, so it could be integrated.
HTH,
Martin
Diez B. Roggisch
> Hi Diez & All,
>
>> And on a personal note: I find it *buttugly*.
>
> Do you mind explaining "why" you find it *buttugly*? I am asking just
> out of curiosity, obviously. I am so biased towards wxPython that I
> won't make any comment on this thread in particular, but I am curious
> to know why some people find it "ugly" or "bad" or whatever. It has
> its own bugs and missing features, of course, but it is one of the
> major GUI player in the arena, together with PyQt and PyGTK.
For the curious: Not the look & feel (albeit I prefer KDE on linux over
Gnome, which is a Qt/GTK thing and thus affects wx look & feel as well),
but the code & the designers. I've been spoiled by Qt and Apple
Interface Builder I guess.
But as I said: that's a personal opinion, and I'm well aware of the
limitations of Qt (licensing and costs) and of course IB (OSX only)
Diez
Grant Edwards
>>> And on a personal note: I find it *buttugly*.
>>
>> Do you mind explaining "why" you find it *buttugly*?
[...]
> For the curious: Not the look & feel (albeit I prefer KDE on
> linux over Gnome, which is a Qt/GTK thing and thus affects wx
> look & feel as well), but the code & the designers.
I've never used any of the designers, but I agree 100% that
wxPython code is nasty ugly. wxPython has a very un-Pythonic
API that's is, IMO, difficult to use. The API isn't really
Robin Dunn's fault: wxPython is a very thin wrapper around
wxWidgets, so it largely retains the same nasty low-level C++
API that wxWidgets has. I presume much of wxPython is
generated in some automated fasion (a la swing). There have
been a couple attempts to wrap wxPython in a cleaner, more
Pythonic API, but they've have limited success (wax is the one
I can think of off the top of my head).
--
Grant Edwards grante Yow! If I had a Q-TIP, I
at could prevent th' collapse
visi.com of NEGOTIATIONS!!
Torsten Bronger
Grant Edwards writes:
> On 2008-06-14, Diez B. Roggisch <de...@nospam.web.de> wrote:
>
>>>> And on a personal note: I find it *buttugly*.
>>>
>>> Do you mind explaining "why" you find it *buttugly*?
>
> [...]
>
>> For the curious: Not the look & feel (albeit I prefer KDE on
>> linux over Gnome, which is a Qt/GTK thing and thus affects wx
>> look & feel as well), but the code & the designers.
>
> I've never used any of the designers, but I agree 100% that
> wxPython code is nasty ugly. wxPython has a very un-Pythonic API
> that's is, IMO, difficult to use.
I know that such requests may start a never-ending thread but I'd
really like to know what you mean with this. I had almost no GUI
experience when I started to use wxPython, yet it was a pleasure for
me.
Really, aesthetics of the source is important to me being a hobby
programmer, and I don't like wxPython's camel case and getters and
setters. However, even many (if not most) core Python modules don't
respect PEP8 or don't use current language features.
Besides, passing function names as strings is also a wart, and *I*
have simply never understood signal and slots. Maybe we should
accept that there is no silver bullet in GUI toolkits, and any
personal preferences amongst the Big Four are just a matter of
taste. This "un-Pythonic" thing is arbitrary and unfair wording in
my opinion.
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: torsten...@jabber.rwth-aachen.de
Grant Edwards
>> I've never used any of the designers, but I agree 100% that
>> wxPython code is nasty ugly. wxPython has a very un-Pythonic
>> API that's is, IMO, difficult to use.
>
> I know that such requests may start a never-ending thread but
> I'd really like to know what you mean with this.
[...]
Well, if we want this thread to be never ending, I'd better put
a little dramatic hyperbole into my answer, so here goes... ;)
IMO, a few of the "un-Pythonic" things about wxPython are:
1) Window ID numbers.
"You don't need to know what it's for, just pass a -1."
Their very existence at the user level feels wrong.
I'm told that for approximately 3 uber-sophisticated
wxWidgets programmers window IDs can be useful in some rare
situations. Meanwhile everybody else working under
"normal" conditions has to pass a useless positional
parameter every time they instantiate a widget. Things that
are useful only in exceptional situations should only be
visible in exception situations.
2) the "flags" parameter.
"1975 called, and they want their bit-masks back."
The mashing together of a several dozen different,
completely unrelated attributes into the "flags" parameter
is a trick left over from C/assembly language programming
on machines who's memory size was measure in KB. Rather
than OR-ing together a bunch of bit-patterns to make the
window act the way you want, you should be setting
individually named object attributes or passing optional,
named parameters to the class method.
3) the parent/child tree
"the only thing less well understood than Window IDs"
I've been writing wxPython apps for about 9 years now, and
I still have only a very vague idea what the parent/child
tree is for. Everybody I know just makes everything the
child of the first panel they put in the application frame.
The same people who specify Window IDs other than -1
probably use complex parent/child trees for something.
4) sizers
"they're like aspirin -- they work, but nobody knows exactly how"
OK, that's a bit out-of-date since I seem to recall that
somebody did finally figure out how aspirin works a couple
years back. The way sizers work seems pretty complex
compared to other GUI toolkits I've used, and the extra
complexity doesn't seem to provide any extra capability.
The one thing that seems to me to be particular complicated
is controlling which objects "stretch" in what axis when a
window is resized. I've been using them for many years,
but I've never gotten them more than about 90% figured out.
Every time I write a wxPython apps, I'm initially surprised
at its behavior when the window is resized and have to
spend some trial-and-error time fiddling with the sizer
parameters. I don't remember having to do that in tkInter
or in Trestle: things "just worked".
5) binding
"What? you wanted a button that _did_ something when you clicked it?"
Binding has actually improved a bit in the past few years.
It's not as obscure as it used to be, but it's still an
extra explicit step that shouldn't be required. It should
only take one line of code to create a button widget that
calls a specified callable when it's clicked. Something
like this:
b = wx.Button(label="Click Me", action=myCallable)
Instead you used to have to create a button and then call
some utility function in some other object to bind that
button to a callable (IIRC this was one place where Window
IDs could be used). Now, the button actually has a method
you can use. It's still an extra step...
6) Thousands of wx.UPPER_CASE_INTEGER_HEX_CONSTANTS
"After all, everything is really just a base-2 integer."
Since we don't have objects or attributes or named
parameters or strings, all information must be passed into
and out of the library as arbitrary integers constants. The
really great thing about that sort of API is it's
versatility: you can pass any value any where! Pass a
width in pixels where a bitmask of window attributes is
expected? No problem!
Well, the build I was running has finished, so that's probably
enough...
--
Grant Edwards grante Yow! Those people look
at exactly like Donnie and
visi.com Marie Osmond!!
Torsten Bronger
Grant Edwards writes:
> [...]
>
> 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".
> [...]
>
> 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.
> [...]
>
> 3) the parent/child tree
See wx.ID_ANY.
> [...]
>
> 4) sizers
Maybe because I come from TeX/LaTeX, i liked sizers immediately.
They worked well for me.
> [...]
>
> 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.
> [...]
>
> 6) Thousands of wx.UPPER_CASE_INTEGER_HEX_CONSTANTS
Thank you for the thorough explanations but in my opinion your
points are minor. 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.
I rather have the impression that you like terseness, which is
totally okay but a different thing.
I agree that changing the naming conventions and making use of
properties would increase pythonicness, but on an already high
level.
Paul McNett
> On 2008-06-14, Torsten Bronger <bro...@physik.rwth-aachen.de> wrote:
>
>>> I've never used any of the designers, but I agree 100% that
>>> wxPython code is nasty ugly. wxPython has a very un-Pythonic
>>> API that's is, IMO, difficult to use.
>> I know that such requests may start a never-ending thread but
>> I'd really like to know what you mean with this.
>
> [...]
>
> Well, if we want this thread to be never ending, I'd better put
> a little dramatic hyperbole into my answer, so here goes... ;)
(blatant self-promotion warning: I'm one of the founders of Dabo, and it
sounds like you may like to take a look at it, given your comments below)
> IMO, a few of the "un-Pythonic" things about wxPython are:
>
> 1) Window ID numbers.
>
> "You don't need to know what it's for, just pass a -1."
>
> Their very existence at the user level feels wrong.
>
> I'm told that for approximately 3 uber-sophisticated
> wxWidgets programmers window IDs can be useful in some rare
> situations. Meanwhile everybody else working under
> "normal" conditions has to pass a useless positional
> parameter every time they instantiate a widget. Things that
> are useful only in exceptional situations should only be
> visible in exception situations.
Dabo is a nice wrapper around wxPython, which among other things does
away with id numbers. There are a few places (wxMenu events, for one)
where you need to deal with window id's, but Dabo doesn't expose the
user to that, it handles it the way it should work.
> 2) the "flags" parameter.
>
> "1975 called, and they want their bit-masks back."
>
> The mashing together of a several dozen different,
> completely unrelated attributes into the "flags" parameter
> is a trick left over from C/assembly language programming
> on machines who's memory size was measure in KB. Rather
> than OR-ing together a bunch of bit-patterns to make the
> window act the way you want, you should be setting
> individually named object attributes or passing optional,
> named parameters to the class method.
Dabo uses properties for everything, including the individual style
bits. And it handles making the setting in the right place so it "just
works" without the user needing to know, for instance, that flag x only
works after the class is fully instantiated, or vice-versa.
Properties can be set on the object once instantiated, sent to the
constructor, or set in a subclass:
# create a textbox by instantiating the baseclass
# and sending property values to the constructor:
txt = dabo.ui.dTextBox(self, Value="Hello", FontBold=True)
# tweak some other properties:
txt.FontItalic = True
txt.BackColor = "yellow"
> 3) the parent/child tree
>
> "the only thing less well understood than Window IDs"
>
> I've been writing wxPython apps for about 9 years now, and
> I still have only a very vague idea what the parent/child
> tree is for. Everybody I know just makes everything the
> child of the first panel they put in the application frame.
> The same people who specify Window IDs other than -1
> probably use complex parent/child trees for something.
Every container object needs to know about its children, and every
object needs to know about its parent. So, in Dabo we have 2 properties:
Children and Parent.
> 4) sizers
>
> "they're like aspirin -- they work, but nobody knows exactly how"
>
> OK, that's a bit out-of-date since I seem to recall that
> somebody did finally figure out how aspirin works a couple
> years back. The way sizers work seems pretty complex
> compared to other GUI toolkits I've used, and the extra
> complexity doesn't seem to provide any extra capability.
>
> The one thing that seems to me to be particular complicated
> is controlling which objects "stretch" in what axis when a
> window is resized. I've been using them for many years,
> but I've never gotten them more than about 90% figured out.
>
> Every time I write a wxPython apps, I'm initially surprised
> at its behavior when the window is resized and have to
> spend some trial-and-error time fiddling with the sizer
> parameters. I don't remember having to do that in tkInter
> or in Trestle: things "just worked".
Sizers are admittedly a bit complex in Dabo, too. Or, sizers aren't
complex, but the code that creates them gets pretty wordy pretty fast.
vs = dabo.ui.dSizer("v")
hs = dabo.ui.dSizer("h")
hs.append(dabo.ui.dLabel(self, Caption="Name:"))
hs.append(dabo.ui.dTextBox(self))
vs.append(hs)
> 5) binding
>
> "What? you wanted a button that _did_ something when you clicked it?"
>
> Binding has actually improved a bit in the past few years.
> It's not as obscure as it used to be, but it's still an
> extra explicit step that shouldn't be required. It should
> only take one line of code to create a button widget that
> calls a specified callable when it's clicked. Something
> like this:
>
> b = wx.Button(label="Click Me", action=myCallable)
>
> Instead you used to have to create a button and then call
> some utility function in some other object to bind that
> button to a callable (IIRC this was one place where Window
> IDs could be used). Now, the button actually has a method
> you can use. It's still an extra step...
Dabo takes event bindings as arguments to the constructor, such as:
def onButtonHit(self, evt):
print "button hit"
but = dabo.ui.dButton(self, OnHit=self.onButtonHit)
Hit is the default event, where you use "action". For buttons, it occurs
when the user pushes it. There are a whole host of other events, such as
MouseHover, Idle, etc., and you can bind to any of them in the
constructor by using the syntax above.
We also do auto event binding:
class MyTextBox(dabo.ui.dTextBox):
onValueChanged(self, evt):
print "on value changed"
When instantiated, this textbox automatically runs the onValueChanged
handler when the value changes, even though we never made an explicit
binding.
(auto event binding can also be turned off easily).
> 6) Thousands of wx.UPPER_CASE_INTEGER_HEX_CONSTANTS
>
> "After all, everything is really just a base-2 integer."
>
> Since we don't have objects or attributes or named
> parameters or strings, all information must be passed into
> and out of the library as arbitrary integers constants. The
> really great thing about that sort of API is it's
> versatility: you can pass any value any where! Pass a
> width in pixels where a bitmask of window attributes is
> expected? No problem!
All these flags in the global wx namespace is IMO one of its biggest warts.
But in the end, wxPython is the best GUI toolkit for Python, by far,
which is why we picked it when embarking on Dabo. We definitely made the
right choice.
> Well, the build I was running has finished, so that's probably
> enough...
I guess I'll end the shameless self-promotion now, too.
Paul
Grant Edwards
> Grant Edwards wrote:
>> On 2008-06-14, Torsten Bronger <bro...@physik.rwth-aachen.de> wrote:
>>
>>>> I've never used any of the designers, but I agree 100% that
>>>> wxPython code is nasty ugly. wxPython has a very un-Pythonic
>>>> API that's is, IMO, difficult to use.
>>> I know that such requests may start a never-ending thread but
>>> I'd really like to know what you mean with this.
>>
>> [...]
>>
>> Well, if we want this thread to be never ending, I'd better put
>> a little dramatic hyperbole into my answer, so here goes... ;)
>
> (blatant self-promotion warning: I'm one of the founders of Dabo, and it
> sounds like you may like to take a look at it, given your comments below)
Yes! Dabo was the other one I was trying to remember. The last
time I looked Dabo appeared to be catching on better than wax
was.
> But in the end, wxPython is the best GUI toolkit for Python,
> by far,
I've been using it for 9 years. :) I can pretty much always
make it work, and the result looks native to Windows users and
"native enough" to Linux users...
--
Grant Edwards grante Yow! I'm rated PG-34!!
at
visi.com
Grant Edwards
>> [...]
>>
>> 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!!
Colin J. Williams
> On 2008-06-14, Diez B. Roggisch <de...@nospam.web.de> wrote:
>
>>>> And on a personal note: I find it *buttugly*.
>>> Do you mind explaining "why" you find it *buttugly*?
>
> [...]
>
>> For the curious: Not the look & feel (albeit I prefer KDE on
>> linux over Gnome, which is a Qt/GTK thing and thus affects wx
>> look & feel as well), but the code & the designers.
>
> I've never used any of the designers, but I agree 100% that
> wxPython code is nasty ugly. wxPython has a very un-Pythonic
> API that's is, IMO, difficult to use. The API isn't really
> Robin Dunn's fault: wxPython is a very thin wrapper around
> wxWidgets, so it largely retains the same nasty low-level C++
> API that wxWidgets has. I presume much of wxPython is
> generated in some automated fasion (a la swing). There have
> been a couple attempts to wrap wxPython in a cleaner, more
> Pythonic API, but they've have limited success (wax is the one
> I can think of off the top of my head).
WAX doesn't seem to have been maintained
since 2004.
Colin W.
>
Torsten Bronger
Grant Edwards writes:
> On 2008-06-14, Torsten Bronger <bro...@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.)
Grant Edwards
>> 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
s0s...@gmail.com
just to hear it from the Pythonistas: Why can't there be several GUI
toolkits on the standard library?
Ben Finney
Because the Zen of Python advises against it:
>>> import this
The Zen of Python, by Tim Peters
…
There should be one-- and preferably only one --obvious way to do it.
--
\ "Tis more blessed to give than to receive; for example, wedding |
`\ presents." -- Henry L. Mencken |
_o__) |
Ben Finney
Torsten Bronger
Grant Edwards writes:
> On 2008-06-14, Torsten Bronger <bro...@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".
Then I have your definition of it. I don't think that it leads to
good design, though. In case of doubt, choose what's common in
Python, but other characteristics must have higher priority.
>> Legibility and practicality matter.
>
> [...] With a little practice and care, functional programming in
> prefix-notation (a-la Scheme) can both practical and legible,
Not legible for a Python-only programmer like me, and I am the
target audience.
> but it still isn't Pythonic.
>
> [...]
>
>>> 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.
Related flags are orthogonal so that the library can well detect an
error. Okay, you can pass a *very* wrong parameter, like telling
wxPython that this event should have an OK button, but I find this
problem case artificial.
> [...]
>
>> 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.
Well, of course it would look heavily different with a different
history but this applies to every piece of software. As I said, I
used flags in my own package, designed with Python 2.4. And I
consider myself a purist. So, there are things that are bad or
sub-optimal, but flags are a matter of personal preference.
s0s...@gmail.com
wrote:
> s0s...@gmail.com writes:
> > I know there must be at least a few very solid answers to this, but,
> > just to hear it from the Pythonistas: Why can't there be several GUI
> > toolkits on the standard library?
>
> Because the Zen of Python advises against it:
>
> >>> import this
>
> The Zen of Python, by Tim Peters
> …
> There should be one-- and preferably only one --obvious way to do it.
>
I agree with that concept. But there already is more than one way to
do it, only that the other ways are being made less accessible (by not
being on the standard library), don't you think?
Anyway, as I said earlier, I'm sure there must be very solid reasons
for this, so I don't intend to argue on this. Just a thought :).
"Martin v. Löwis"
> just to hear it from the Pythonistas: Why can't there be several GUI
> toolkits on the standard library?
Why do you think there can't be several GUI toolkits in the standard
library? There is nothing that prohibits such a thing per se.
See my other message on why wxPython isn't part of the standard library:
it hasn't been contributed, yet.
Regards,
Martin
Sebastian "lunar" Wiesner
>> Just out of curiosity, what are the chances of this happening (sort of
>> like what happened with sqlite)?
>
> As a starting point, the author(s) of wxPython would need to contribute
> it to Python (and then also give the PSF the permission to relicense
> it). If no such contribution is made, chances are zero. Somebody else
> contributing it in place of the authors is not acceptable - that
> somebody likely doesn't have the right to grant the proper license to
> the PSF,
If any single person can even have this right ... wxPython and wxWidgets
probably received a lot of foreign contributions along the years, and each
single contributors, whose code is still part of wx, would have to agree to
a change of license, should the PSF license be incompatible to the wx
license.
--
Freedom is always the freedom of dissenters.
(Rosa Luxemburg)
Diez B. Roggisch
> I know there must be at least a few very solid answers to this, but,
> just to hear it from the Pythonistas: Why can't there be several GUI
> toolkits on the standard library?
Take my first post, add martin's maintenance + licensing-issues, and
multiply the arguments by the number of toolkits you intend to include.
Then you have the reason(s).
Diez
Ben Finney
> On Jun 15, 9:37 am, Ben Finney <bignose+hates-s...@benfinney.id.au>
> wrote:
> > The Zen of Python, by Tim Peters
> > …
> > There should be one-- and preferably only one --obvious way to do it.
>
> I agree with that concept. But there already is more than one way to
> do it, only that the other ways are being made less accessible (by
> not being on the standard library), don't you think?
With the result that there is only one *obvious* way to do it. That's
a property worth some effort to preserve.
For some reason, people always overlook that qualification when
reading that part of the Zen.
--
\ “A hundred times every day I remind myself that [...] I must |
`\ exert myself in order to give in the same measure as I have |
_o__) received and am still receiving” —Albert Einstein |
Ben Finney
Mike Driscoll
On Jun 14, 3:43 pm, Grant Edwards <gra...@visi.com> wrote:
> On 2008-06-14, Torsten Bronger <bron...@physik.rwth-aachen.de> wrote:
>
> >> I've never used any of the designers, but I agree 100% that
> >> wxPython code is nasty ugly. wxPython has a very un-Pythonic
> >> API that's is, IMO, difficult to use.
>
> > I know that such requests may start a never-ending thread but
> > I'd really like to know what you mean with this.
>
> [...]
>
> Well, if we want this thread to be never ending, I'd better put
> a little dramatic hyperbole into my answer, so here goes... ;)
>
> IMO, a few of the "un-Pythonic" things about wxPython are:
>
<snip>
> 4) sizers
>
> "they're like aspirin -- they work, but nobody knows exactly how"
>
> OK, that's a bit out-of-date since I seem to recall that
> somebody did finally figure out how aspirin works a couple
> years back. The way sizers work seems pretty complex
> compared to other GUI toolkits I've used, and the extra
> complexity doesn't seem to provide any extra capability.
>
> The one thing that seems to me to be particular complicated
> is controlling which objects "stretch" in what axis when a
> window is resized. I've been using them for many years,
> but I've never gotten them more than about 90% figured out.
>
> Every time I write a wxPython apps, I'm initially surprised
> at its behavior when the window is resized and have to
> spend some trial-and-error time fiddling with the sizer
> parameters. I don't remember having to do that in tkInter
> or in Trestle: things "just worked".
You have many valid points. But I enjoy wxPython more than the other
Python GUI toolkits I've tried, Currently, I'm working on a series of
articles on Sizers and other bits and pieces in wx on my blog. Some of
them are already in the wxPython wiki and if people think my other
ones are good enough, I'll add them too.
If you have some common GUI layouts (or widgets or something else)
you'd like me to try, I'll be happy to attempt to create a tutorial
around them. I admit that I'm no expert, especially compared to you.
You've been using wx far longer than I have, but if I can help, I
would like to. You can see my stuff here: http://www.blog.pythonlibrary.org/
Also, you might take a look at IronPython. I've been playing with it
of late and doing a GUI using WinForms has been surprisingly easy. And
with Mono, you get a mostly cross-platform kit to boot.
<snip>
> --
> Grant Edwards grante Yow! Those people look
> at exactly like Donnie and
> visi.com Marie Osmond!!
Mike
TYR
> Instead you used to have to create a button and then call
> some utility function in some other object to bind that
> button to a callable (IIRC this was one place where Window
> IDs could be used). Now, the button actually has a method
> you can use. It's still an extra step...
That looks quite a lot like the behaviour of PythonForS60's appuifw
class. Frex, a menu:
appuifw.app.menu = [(u'Octopus', getfish(octopus)), (u'Cuttlefish',
getfish(cuttlefish)), (u'Squid', ((u'Humboldt', getfish(humboldt)),
(u'Giant', getfish(giantsquid)), (u'Colossal', getfish(colossal)))]
gives you a menu with three options, the last of which has three sub-
options, all of which call your getfish() function with their value.