How come wxPython isn't in the standard library?

**Steve Menard** · Jul 18 '05, 05:23 PM

Re: How come wxPython isn't in the standard library?

BJörn Lindqvist wrote:[color=blue]
> See: http://www.wxpython.org/quotes.php. especially:
>
> "wxPython is the best and most mature cross-platform GUI toolkit,
> given a number of constraints. The only reason wxPython isn't the
> standard Python GUI toolkit is that Tkinter was there first." - Guido
> van Rossum
>
> Guess, that answers my question, but isn't "Tkinter was there first" a
> very bad answer? :) It is kinda ugly too, so I wonder why it can't be
> replaced? Or maybe another GUI library could complement it. IMHO,
> having a good GUI library in the stdlib would make distributing GUI
> apps much easier. Windows users (and many Linux users) doesn't like
> searching the net to find and download lots of dependancies.
>[/color]

I haven't used WxPython for a little while, but not long ago (less than
a year) it was dreadfully easy to crash a program if even a little
mistake happened. Add to that that WxPython prigram will silently eat
any unexpected exceptions, and you get a very hard to debug situation.

For me, this would sisqualify wxPython as a standard Library component.

Steve

**Roger Binns** · Jul 18 '05, 05:23 PM

Re: How come wxPython isn't in the standard library?

BJörn Lindqvist wrote:[color=blue]
> IMHO,
> having a good GUI library in the stdlib would make distributing GUI
> apps much easier.[/color]

Anything that is in stdlib is somewhat constrained to the same release
schedule as the core Python. For example it would have been bad to do
the wxPython 2.4 to 2.5 transition during the 2.3 Python series.

If your issue is distributing applications, there are other solutions.
For example, look at http://dotamatic.sf.net which is written in
Python using wxPython and has Windows, Linux and Mac binaries. An
end user never needs to know or care what the application is written
in or libraries used, and there are no other depenedencies.

A more extreme example is http://www.bitpim.org where we have even more
fun stuff like XML, SSL, SSH, USB and many other libraries. Again the
end users don't ever need to know or care.

Roger

**StvB** · Jul 18 '05, 05:24 PM

Re: How come wxPython isn't in the standard library?

I had that 'problem' a couple of times, but it was just a matter of writing
my code more cohesively and organizing my exception hierarchy so that
certain exception clauses cover a more narrow range of code, and catch a
more wide range of exceptions.
[color=blue]
>
> I haven't used WxPython for a little while, but not long ago (less than a
> year) it was dreadfully easy to crash a program if even a little mistake
> happened. Add to that that WxPython prigram will silently eat any
> unexpected exceptions, and you get a very hard to debug situation.
>
> For me, this would sisqualify wxPython as a standard Library component.
>
>
> Steve[/color]

**Roger Binns** · Jul 18 '05, 05:24 PM

Re: How come wxPython isn't in the standard library?

Roger Binns wrote:[color=blue]
> Anything that is in stdlib is somewhat constrained to the same release
> schedule as the core Python. For example it would have been bad to do
> the wxPython 2.4 to 2.5 transition during the 2.3 Python series.[/color]

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 is an expectation that modules in the standard library are good
examples of Pythonic APIs, programming, documentation, self tests etc.

Roger

**BJörn Lindqvist** · Jul 18 '05, 05:25 PM

Re: How come wxPython isn't in the standard library?

Thanks for the replies. There seems to be some good reasons that
wxPython isn't in the stdlib yet.

It's too big:
[color=blue]
> 1) wxpython src tarball is about 18M,
> python's is about 8M. Adding wx to the standard would more than
> triple the size of the standard distro.[/color]

IMHO, this is a no issue. It doesn't matter that much if the source is
8 or 26 mb. In fact, 8 mb is extremely small download for a
programming language.

Incompatible release schedules:
[color=blue]
> Anything that is in stdlib is somewhat constrained to the same release
> schedule as the core Python. For example it would have been bad to do
> the wxPython 2.4 to 2.5 transition during the 2.3 Python series.[/color]

I don't understand this argument really and would be happy if someone
would explain further. Why can't those people who compile the stdlib
just take whatever the lastest version of wxPython is, and include
that?

wxPython is not mature enough:
[color=blue]
> The other thing I failed to mention is that the wxPython API isn't very
> Pythonic. [/color]
[color=blue]
> I haven't used WxPython for a little while, but not long ago (less than
> a year) it was dreadfully easy to crash a program if even a little
> mistake happened.[/color]

Ok. Those are big problems. So wxPython is not good enough to earn a
spot in the stdlib yet. However, getting your Python module into the
standard library must be like winning the Nobel Prize for Python
module programmers. Atleast, if *I* had a chance to get a module I've
written into the stdlib, I would definitely sync my release schedule
and make my module as pythonic as possible. :) Maybe in the future it
can be included?

--
mvh Björn

**Stefan Behnel** · Jul 18 '05, 05:26 PM

Re: How come wxPython isn't in the standard library?

BJörn Lindqvist schrieb:[color=blue][color=green]
>>1) wxpython src tarball is about 18M,[/color]
>
> IMHO, this is a no issue. It doesn't matter that much if the source is
> 8 or 26 mb.[/color]

I highly object. Size /does/ matter in many cases. Imagine what would
happen if wxPython was integrated. People would say: Ok, tkinter is in,
wxPython is in, why not PyQT, PyGTK and toolkit XYZ ?? I don't see any
reason why wxPython should be better than any of the other toolkits. And
if I was to vote for or against a redundant module that would totally
bloat the standard distribution, I wouldn't think twice about it...

[color=blue]
> In fact, 8 mb is extremely small download for a
> programming language.[/color]

8MB is actually quite large and I'm happy that many Linux-Distros
(especially Handheld distros like Familiar) split the stdlib into various
packets that can be installed independantly. I actually hope that Python
3000 will make this easier by reducing inter-module dependencies when
restructuring stdlib.

Stefan

**Greg Steffensen** · Jul 18 '05, 05:26 PM

Re: How come wxPython isn't in the standard library?

wxPython and Tkinter are more portable than PyQT and PyGTK. Moreover,
wxPython is not just another toolkit... its a set of bindings to a very
active toolkit that also has bindings for C++, Java, Javascript, Perl,
Ruby, Basic, Haskell, .NET and Eiffel, among others. wxWidgets is
already something of an open-source standard, independent of Python's
relationship. If wxPython were included in the standard library, it
would become easier for developers to port code from those languages to
Python. And because wxWidgets is such a large project, Python would be
able to benefit from its progress, providing regular language
improvements with little effort from the Python devs.

As for the size issue, the fact that including wxPython would triple
the size of the size of the standard disto says more about the current
state of the standard distro than it does about wxPython. If the
Python devs intend to keep the standard distribution at less than 10 mb
forever, then I think world-domination is impossible. The universal
availability of a modern, portable gui toolkit is a major feature that
languages can provide, and if Python decides to reject this, then it
will lose popularity to other languages that don't. Assuming that
language penetration is a major motivator for the devs, I think that
wxPython inclusion really is something that we need to start
considering.

**Greg Steffensen** · Jul 18 '05, 05:26 PM

Re: How come wxPython isn't in the standard library?

Errr... QT and GTK obviously have many language bindings too... I'm
saying that wxPython is superior because it has lots of bindings and is
portable.

**James Stroud** · Jul 18 '05, 05:26 PM

Re: How come wxPython isn't in the standard library?

On Sunday 07 November 2004 06:43 am, BJörn Lindqvist wrote:[color=blue]
> IMHO, this is a no issue. It doesn't matter that much if the source is
> 8 or 26 mb. In fact, 8 mb is extremely small download for a
> programming language.[/color]

What am I missing here? Lets look at it from an END USER's perspective. I come
from a situation where I was sys-admin to where I am the 0 privelige user. I
wanted to install a python module. So I called in the sys-admin. He tried to
add it with RPM. This rpm depended on that rpm and that rpm depended on a
chicken which depended on an egg which, expectedly, depended on a
chicken--you can guess where this is going.

So I decided I would make my own little universe in my user folder building
everything from scratch.

To get Tkinter to work, I had to install Tcl/Tk and python, and probably some
other stuff I already forgot about (blt or something?). That was easy-ish,
but painful from an END USER's perspective.

I then tried wxPython to take advantage or something or the other module that
I guess I won't be able to use because I had to install (to make sure every
library was compatible) a bunch of other libraries (zlib, jpeg, pango, etc.).
Pango needed gtk+ and didn't like the one my machine already had. (I work at
an INSTITUTION, not my home office with my customized linux box.) That would
make two gtk distributions on my machine, causing too many problems for my
short term attention span to figure out. So I did the only reasonable thing
an END USER might do in this situation--I said screw it on wxPython and
whatever module that was that I wanted to use.

Lets try to see things with naieve eyes: how do we think an END USER with few
administrative priveleges but operating system choices might respond to a
situation like this? Right! He'll use M$ windows--guaranteed.

Now I think we understand why graphics libraries might have a tough time
making it into a standard distro. Personally, as an end user who only wants
to use a program and not re-compile his kernel and such, I vote for tweaking
out tkinter and making Tcl/Tk/blt/etc. part of the standard distro with that
18 mb otherwise required for wxPython (as cool as wx might be). One
installer, wham-bam-program.

James
--
James Stroud, Ph.D.
UCLA-DOE Institute for Genomics and Proteomics
611 Charles E. Young Dr. S.
MBI 205, UCLA 951570
Los Angeles CA 90095-1570

http://www.jamesstroud.com/

**Roger Binns** · Jul 18 '05, 05:26 PM

Re: How come wxPython isn't in the standard library?

James Stroud wrote:
[Tale of RPM hell, Linux library version hell elided][color=blue]
>
> Lets try to see things with naieve eyes: how do we think an END USER
> with few administrative priveleges but operating system choices might
> respond to a situation like this? Right! He'll use M$
> windows--guaranteed.[/color]

A lot of what you experienced is due to the design and implementation
of Windows. Microsoft puts a lot of effort into binary backwards
compatibility. It is why only one Python installer needs to be made
and can support every version of Windows since Win 95.

In the Linux world, very little effort is put into binary backwards
compatibility for libraries, because things can just be recompiled.
You were a victim of that.

But it isn't Python's place to try to fix that. Recognising it as
a problem, the number one feature of almost every new Linux distro
is rescuing users from packaging and versioning issues. I'll
leave it up to your judgement as to whether any succeeded.
[color=blue]
> Now I think we understand why graphics libraries might have a tough
> time making it into a standard distro. Personally, as an end user who
> only wants to use a program and not re-compile his kernel and such, I
> vote for tweaking out tkinter and making Tcl/Tk/blt/etc. part of the
> standard distro with that 18 mb otherwise required for wxPython (as
> cool as wx might be). One installer, wham-bam-program.[/color]

The reason why tkinter/Tk doesn't have such library issues is because
it doesn't use many libraries under the hood. It draws the widgets
itself, has less interoperabilit y with printing, drag and drop,
internationaliz ation, online help, inter-process communication, clipboard,
themes, preferences etc. As such it is perfect for simpler apps
and a good reason for being in the standard lib.

But if you want to "tweak out" tkinter so it did all that stuff, you'd
be re-implementing all those libraries (a considerable amount of work)
or using them, bringing everything back to square one!

Roger

**Roger Binns** · Jul 18 '05, 05:26 PM

Re: How come wxPython isn't in the standard library?

BJörn Lindqvist wrote:[color=blue][color=green]
>> Anything that is in stdlib is somewhat constrained to the same
>> release schedule as the core Python. For example it would have been
>> bad to do the wxPython 2.4 to 2.5 transition during the 2.3 Python
>> series.[/color]
>
> I don't understand this argument really and would be happy if someone
> would explain further. Why can't those people who compile the stdlib
> just take whatever the lastest version of wxPython is, and include
> that?[/color]

wxPython has chances and enhancements in the API over time. For example
moving from wxPython 2.4 to 2.5 changed the preferred package naming
scheme, added several new methods for when you want to use point/size
objects, provided a new mechanism for binding to events, several other
enhancements, a whole bunch of deprecations etc.

It is actually quite rare for code using wxPython to support both
version 2.4 and 2.5.

Now if Python 2.3.1 shipped with wxPython 2.4 and Python 2.3.4 shipped
with wxPython 2.5, many people would get upset since their code would
brea/be deprecated in various ways. The right thing to do would be
for Python 2.3.x to stick with the same version of wxPython. However
we would come full circle since many projects now only work with wxPython
2.5 (the improvements were well worth it).

[color=blue][color=green]
>> The other thing I failed to mention is that the wxPython API isn't
>> very Pythonic.[/color]
>[color=green]
>> I haven't used WxPython for a little while, but not long ago (less
>> than a year) it was dreadfully easy to crash a program if even a
>> little mistake happened.[/color]
>
> Ok. Those are big problems.[/color]

The latter point is extremely rare these days.
[color=blue]
> spot in the stdlib yet. However, getting your Python module into the
> standard library must be like winning the Nobel Prize for Python
> module programmers.[/color]

Not quite. It is an indication that your module is of value to many and
that you have a reasonably good implementation. You also need to
have your rate of change approximately the same as Python.
[color=blue]
> written into the stdlib, I would definitely sync my release schedule
> and make my module as pythonic as possible. :) Maybe in the future it
> can be included?[/color]

The API being Pythonic has been one of the big debates in the wxPython
community. wxPython is a wrapper around the C++ wxWidgets library. The
C++ API is "normal" for the library and is what is documented. wxPython
is a Python version of that API. Some people (like me :-) are happy with
that. It is a normal GUI API and I have no issue reading and using the
docs. Other people want something that is like all the other Python APIs
they are used to, and Python specific documentation. The latter is also a
*lot* more work, and although some people have attempted it, there doesn't
seem to be any that have followed through for a long period of time.

Roger

**Maciej Katafiasz** · Jul 18 '05, 05:26 PM

Re: How come wxPython isn't in the standard library?

On day Sun, 07 Nov 2004 12:07:50 -0800 looked the Lord upon his prophet,
and the prophet was numbered among those called Greg Steffensen. And thus
spake the prophet:
[color=blue]
> wxPython and Tkinter are more portable than PyQT and PyGTK. Moreover,
> wxPython is not just another toolkit... its a set of bindings to a very
> active toolkit that also has bindings for C++, Java, Javascript, Perl,
> Ruby, Basic, Haskell, .NET and Eiffel, among others. wxWidgets is
> already something of an open-source standard, independent of Python's
> relationship. If wxPython were included in the standard library, it
> would become easier for developers to port code from those languages to
> Python. And because wxWidgets is such a large project, Python would be
> able to benefit from its progress, providing regular language
> improvements with little effort from the Python devs.[/color]

That's not really true. wxWidgets is (IMHO) clearly inferior to PyGTK. It
has not as nice API (reminds me of Win32 API, which is disastrous), isn't
in my experience really stable, uses outdated gtk+ 1.2 on my primary
platform, and even gtk+ 1.2 isn't fully used, instead we have some strange
things for any non-trivial (or rather, non-LCD) widget, like treeview or
fileselector. I feel no urge to have yet another "standard" GUI in python
I won't ever use.
[color=blue]
> As for the size issue, the fact that including wxPython would triple
> the size of the size of the standard disto says more about the current
> state of the standard distro than it does about wxPython. If the
> Python devs intend to keep the standard distribution at less than 10 mb
> forever, then I think world-domination is impossible.[/color]

That doesn't change the fact that tripling the size is not something you
do everyday. Especially not for (again, IMHO) rather useless component.
[color=blue]
> The universal availability of a modern, portable gui toolkit is a
> major feature that languages can provide, and if Python decides to
> reject this, then it will lose popularity to other languages that don't.[/color]

This is untrue. Entire notion of "portable toolkit" comes from wrong
assumption there exists anything near portability in GUI. There simply
isn't anything like portable UI, and conversely, creation of any
"portable" toolkit is doomed since day zero.
[color=blue]
> Assuming that language penetration is a major motivator for the devs, I
> think that wxPython inclusion really is something that we need to start
> considering.[/color]

GUI toolkit isn't something a language should provide. Things that make
sense to be in standard library have to be universally available and
useful. Regular expressions are universally useful, GUI toolkit which is
very platform-specific isn't. So it doesn't make sense to include it in
stdlib. Especially not-so-good toolkits shouldn't be there (and as I said,
I don't consider wxWidgets to be good toolkit)

--
"Tautologiz m to coÅ› tautologicznego "
Mathrick <mnews2@wp.pl >

**Roger Binns** · Jul 18 '05, 05:26 PM

Re: How come wxPython isn't in the standard library?

Maciej Katafiasz wrote:[color=blue]
> PyGTK. It has not as nice API (reminds me of Win32 API, which is
> disastrous),[/color]

The original wxWidgets API was somewhat reminiscent of Microsoft's
MFC. There isn't anything "disastrous " about it. You have a
class hierarchy, methods and properties. What exactly is the
issue you have?
[color=blue]
> isn't in my experience really stable,[/color]

Care to substantiate that? (I mean now, not several years ago).
[color=blue]
> uses outdated gtk+ 1.2 on my primary platform,[/color]

wxPython works with both GTK 1 and 2. Until wxPython 2.5, Robin
couldn't find a way to distribute GTK 2 based binaries that would
work on any machine. You could compile yourself against GTK2.
[color=blue]
> non-LCD) widget, like treeview or fileselector. I feel no urge to
> have yet another "standard" GUI in python I won't ever use.[/color]

Wherever possible, wxWidgets uses the native widgets. I ran the wxPython
demo and looked at both widgets you mention and they appear identical
to ones in other Gnome programs (I run Gnome for my Linux desktop).
[color=blue]
> GUI toolkit isn't something a language should provide.[/color]

It is *extremely* rare for a language environment not to provide a
gui and associated tools. About the only other major one I can think of
that doesn't is Perl. (You could argue that GNU C/C++ on Unix doesn't
either, but that is due to GUI deficiency on Unix. On other platforms
such as Windows and Mac, C/C++ does come with gui tools and libraries).
[color=blue]
> there (and as I said, I don't consider wxWidgets to be good toolkit)[/color]

I don't think that statement can be supported. wxPython/widgets has been
getting better constantly. However I don't think that wxPython should
be in the standard library because it is improving and has more frequent
release cycles, and I would like to take advantage of that.

Roger

**Greg Steffensen** · Jul 18 '05, 05:26 PM

Re: How come wxPython isn't in the standard library?

Now is better than never (and no one's advocating "right now").

How come wxPython isn't in the standard library?

How come wxPython isn't in the standard library?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment