GUIs - A Modest Proposal

[Stephen Hansen]

On 6/10/10 12:36 PM, rantingrick wrote:
> On Jun 10, 1:56 pm, Stephen Hansen <me+list/pyt... at ixokai.io> wrote:
> 
>> So... uh, why again are we including it? Those people who need it, have
>> ready access.
> 
> But what if Mark decided one day he no longer wants to support Python
> or Win32? How many years will it be before someone writes another?

Very few, I suspect.

There's very little you can do with pywin32 that you can't do with
ctypes. PyWin32 served a pretty important role once upon a time when you
might need to do certain low level win32 api's. These days, I just use
ctypes.

The primary purpose I use pywin32 for is documentation or to see how
someone solved a problem *using* pywin32: I then rewrite it in ctypes.

But, should some mythical occasion come and Mark decides not to support
either anymore-- we'll be in the exact same position now as to then.
Someone'll need to step up and maintain it.

Something being in the stdlib doesn't mean its maintained: in fact,
that's a very dangerous part about inclusion. There's a number of
modules already in the stdlib which don't have anyone responsible for
them, and its really, really hard to get bugfixes into them unless
someone is very interested or its a serious bug.

>> Why not include wxPython <snip>
>> Why not include PyQT? <snip>
> 
> Both are not-starters for many reasons already discussed in this
> thread. Maybe wax would have a chance if we made it more Pythonic as
> Greg pointed out. All others are a non-starter due to the zen (import
> this).

I like how you left out all my talk of dependencies. That's very
important when you're talking about stdlib inclusion: wax depends on
wxPython. Thus, non-includable, as wxPython is non-includable and so
something dependent upon it is as well.

> 
>> Again: it has nothing at all to do with people not liking GUI's or
>> thinking GUI's are going the way of the dodo. It has to do with people's
>> ideas of what should or should not go in the standard library. Generally
>> speaking? Stuff that everyone or most people can make ready use of...
>> and while yes, doing GUI development is very, very common -- "GUI
>> development" is not a single monolithic thing. Different people have
>> some *very* different needs for what they get out of their GUI development.
> 
> And again the opponents miss the whole point. It's not about including
> a GUI that would make everyone happy. Its about including a GUI that
> is complimentary to Python's stated goals. Not for you, Not for me,
> Not for the x&lee... remember? ;-)

You make a statement about GUI's not going away, and how all of us GUI
haters need to get on board-- then leave that statement out-- and say I
miss the whole point when I say its got nothing to do with that. Okay, well.

You want to include a GUI that's not for, well, anyone. But
ideologically sound. Okay, well.

Tkinter is complimentary to Python's stated goals. The method by which
that compliment happens (with TCL in the middle) is a bit strange, and
the syntax leaves something to be desired-- but its really not that bad,
and there's other modules in the stdlib more unpythonic.

Its easy to use, reasonably powerful, and if you use the new themed
widgets (which isn't terribly hard to do), not even too ugly.

>> The reason we do not embed any 'better' GUI then Tkinter into the
>> stdlib? There's several tools available for the job: and there is no
>> clear indication or agreement that one is better or more qualified for
>> inclusion over the others. At least, IMHO. I do not speak for python-dev.
> 
> So i guess then the question becomes... Why keep supporting it? It's
> time to say Bye-Bye to Tkinter.

Because there is no clearly superior alternative available. Didn't I
just say that? I swear I did.

Until there is, Tkinter is "good enough".

>> Things don't go into the stdlib to mature.
> 
> Agreed! And likewise "things" should not be left to clutter the stdlib
> needlessly only to wither and die a slow death just because no one has
> the vision (or the motivation) to fix them or remove them for the sake
> of Python's evolution.

Tkinter is maintained, works, and is updated continually to make
available the latest things that become available in Tk.

And actually: things do go to the stdlib to die. Its actually a very apt
description of exactly how things work. Once a module gets added to the
stdlib, its sort of dead. Static. It might change, in this
excruciatingly slow pace, with strict rules for compatibility over
consistency. It takes years and years before you can fix a design error
-- you have to wait until the next major release to put a new option in,
do some deprecation (be it pending or regular, it depends), and then a
whole new major release before you can finally be fixed.

-- 

   Stephen Hansen
   ... me+list/python (AT) ixokai (DOT) 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/20100610/d0d4a7f3/attachment-0001.sig>