WxPython versus Tkinter.

Wed Jan 26 15:07:35 EST 2011

On 1/26/11 9:19 AM, Octavian Rasnita wrote:
> From: "Emile van Sebille" <emile at fenx.com>
> ...
>>> Well, I didn't know this, and it is a valid reason.
>>> This means that it is true that there is no enough maintainance force to
>>> keep WxPython updated.
>>> Did I understand correctly?
>>
>> Not at all -- wxPython is an active funded ongoing project. Review the 
>> roadmap at http://wiki.wxpython.org/TentativeRoadmap and particularly 
>> the final paragraph on Python3.x support.
> 
> But somebody said that the core Python developers, or Guido said that WxPython won't be included in the core distribution because it doesn't have a strong team of maintainers... with other words but this was the idea.

That isn't, at all, what people said.

What they said was that for a new library to be included in the stdlib,
it must have maintainers willing to *commit* for years to *maintain* it
IN the stdlib.

Maintaining something in the stdlib is very different then maintaining
something out of the stdlib.

The stdlib has quite a few rules: and it evolves at a certain set speed.

wxPython is a wrapper around a third-party library which evolves at a
totally different rate: if wxPython were included in the stdlib, these
two completely separate development cycles could result in significant
hardship for the maintainers and more importantly, for the USERS.

Does Python now hold up a release waiting for the wxWidgets team to put
out a new version with great new features?

Or, does Python release as normal, and just by happenstance does
wxWidgets release a great new release a month later-- and now Python
users can't get it for a year or two when the next feature release of
Python is available?

Either way, the maintainers job is more difficult, and users are harmed.

There's a reason that libs that go into the stdlib tend to be very
static and extremely slow paced in their evolution.

Now, Robin could decide to maintain wxPython in two places: as a
third-party library, and every release cycle sync in the latest to the
core stdlib. That's been done: but its actually extremely problematic
itself, and is asking for a lot of extra work.

wxPython as a third-party library is maintained: certainly. But that
doesn't mean wxPython in the stdlib would be maintained.

Then again, it may be that they would be fine with moving into the
stdlib-- but since its not a viable option for numerous other reasons,
they never bothered to give it any real consideration.

> So I still don't understand why WxPython can't be a good solution.
> If WxPython is well maintained, let's pretend that the maintainers solved that bug that make the apps give a segfault, and let's pretend that it works under Python 3.
> Can it be a good choice for replacing Tkinter?

That's hand-waving a LOT of stuff with "let's pretend", but okay. Let's
pretend that the lib is modified and fixed up so that segfaults don't
happen (and, IIUC, the next version may be); and let's pretend it works
under Python 3 (does that leave me in the dust, as someone who would
love to get some wxPython updates but who is only using Python 2.5?).

There's a bunch of hurdles that would need solving before its a
candidate for inclusion: (off the top of my head)

1. Tkinter can not be removed without a 100% compatible replacement for
the forseeable future. 100%. No exception on that 100%. This includes
people downloading TK extensions and using them in their Python apps:
because if thats not possible, real applications will fail.

  Please understand before you move on. This is one of the hurdles of
the stdlib that make maintaining something in it harder then maintaining
something out of it: there are strict compatibility requirements and
rules. It might be a great thing for humanity to have Python include an
accessible GUI toolkit in the standard library: but that doesn't mean
the rules can be broken in doing it.
  Since its basically impossible to be compatible as such, what you'd
have to do is add wx while leaving tk, not replacing it. So:

2. New additions must be PEP-8 compliant; wx is not.
3. New additions must include unit tests; I actually don't know if wx
does. I've always found it a pain in the butt to test GUI stuff-- but TK
is tested (to some degree, I'm not sure how good the coverage is: I just
remember tweaking my buildslave to make it run the tests :)).
4. The documentation would have to all be totally rewritten to fit the
stdlib documentation format
5. The license thing needs solving from a legal standpoint (new code is
traditionally donated to the PSF under the Apache license, which then in
turn re-licenses the code under the Python license). You may think its
stupid to let something like that get in the way, but sorry: we live in
a lawyer's world.
6. Someone would have to commit to maintaining it _in_ the stdlib.
7. Someone would have to work on integrating the wx build requirements
with the stdlib's build requirements for all the platforms -- and this
can be quite a bit. If this makes the release maintainers jobs a lot
harder ... well, they may need some more hands on deck.

... and more.

There's a lot of work there. A lot. A lot a lot. And that's just
hand-waving away some really significant obstacles with Let's Pretend.

Besides: did you know a not insignificant number of people would like to
do away with the stdlib in its entirety? And, more then a few actually
are pushing for the stdlib to be forked off of CPython, and instead end
up shared by all the major Python implementations (CPython, Jython,
PyPy, IronPython, what else?) as a common resource?

Not saying either group would win (though the latter sounds like a very
cool thing to me), but what does either say about the implication of
including wxPython?

> I can see that the people try to find some false arguments like the one that WxPython is bigger than Tkinter, but really, who cares today about a few aditional megabytes?

I'm sorry, but you're confusing what you care about with what other
people care about. You do it a lot. But you seem actually honest in your
efforts, so I give you the benefit of the doubt.

Size does matter to some people, and legitimately so. Still others care
deeply about what is bundled with Python because they're in environments
where installing third-party libraries isn't allowed: these two
interests can stand in opposition to one-another, but that does not make
either /false/, and it does not mean that either is /right/.

There are many interests involved in a language like Python which has
broad usage in extremely varied fields and endeavors: most of which
never come near this list.

And some people have absolutely no need-- no need at all-- for any sort
of GUI programming at all. This group is actually really, really big.

The argument is not false: for YOU it is not compelling, and hell, for
me I don't find it compelling either. But it is a valid issue which has
to be weighed and taken into consideration. Maybe after that is done, on
balance, its deemed to be not that big of a deal. But maybe when added
up with other concerns, it is.

> What do you think it is more important, to offer accessibility for most of the users, or to create small applications?

I think its important to do both.

And wxPython living on in a third-party library fits that perfectly well.

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-list/attachments/20110126/5bbc9a48/attachment.sig>