Removal of tkinter from python 3.0? [was: Fate of the repr module inPy3.0]

[Daniel Fetchinson]

Was looking at PEP 3108, http://www.python.org/dev/peps/pep-3108/ ,

and saw that the repr module was slated for vaporization. I've only
used the module a few times ever. I'm curious if the community wants
it kept around or whether it is considered clutter.

The PEP is going to be finalized soon, so if you have issues with it,
they should be sent to the PEP author or brought up on the list,
http://mail.python.org/mailman/listinfo/stdlib-sig .

Is it just me or others also think that it would be a major loss to
remove tkinter from the python core? PEP 3108 starts off with:

Each module to be removed needs to have a justification as to why it
should no longer be distributed with Python.

then goes on with,

With so many other GUI options out there that are considered better
than Tkinter, it might be best to remove Tkinter from the stdlib and
make it an externally maintained package.

I don't get it. There are many [insert your favorite software
component] options outside of the python core that are considered
better than the one coming with python, yet they don't get removed.
All network servers for example could be thrown out because twisted is
considered better. This just doesn't make sense to me. Tkinter is
great for its purpose, typical use cases are creating a simple GUI
composed of a couple of components only. You can nicely do this with
tkinter and the large user base shows that it's a real need real
people have. Sure, for fancy GUI stuff there are better options but
for quick and simple things tkinter is just great. And last time I
checked python comes with batteries included so why sould I need to
search and download a third party package for such a common use case?

Thoughts anyone?

Cheers,
Daniel

 

[Paul Rubin]

Is it just me or others also think that it would be a major loss to
remove tkinter from the python core?

That would be terrible. Every time I've tried to use one of the other
packages it has led to installation hell. Tkinter isn't great, but
it's extremely useful to have a gui module that's present
automatically in every compete Python installation and that is
reasonably cross platform. I can write a Python/Tkinter app under
Linux and send it to Windows users and they can run it after a single,
very simple Python installation from the Windows .msi. I have no
Windows development tools whatsoever and very limited access to
Windows boxes, so any Python code I deploy on Windows can't rely on
any non-Python code outside of the stdlib.

Also, because of tkinter's inherent limitations, I have the impression
that upgrading it to the latest and greatest tcl/tk release wouldn't
improve it much over the useful but low-rent module that it already is.
Therefore, that supposed "benefit" of splitting it out to an external
package is not much of a benefit.

One of Python's traditionally best attractions has been the depth of
its standard libraries, and backing away from that would be plain
self-destructive. Python needs more stuff in its stdlib, not less.
If Tkinter doesn't satisfy, then add Gtk (or whatever) to the standard
distro. If that happens (i.e. some new toolkit is brought in and
declared to be the standard) then it might be ok to drop Tkinter but
it certainly shouldn't be dropped without a replacement.

 

[Kay Schluehr]

Is it just me or others also think that it would be a major loss to

remove tkinter from the python core? PEP 3108 starts off with:

Each module to be removed needs to have a justification as to why it
should no longer be distributed with Python.

From time to time someone makes a serious claim about ineptness of
using significant whitespace on Windows servers because "My customer
doesn't let me install a reasonable editor. So I'm forced me to use MS
Notepad!". These poor guys can still use IDLE once they have a running
Python installation.

I'm definitely with you and batteries included.

Note also that Tk which seemed to be comatose for a long time seems to
recover and doesn't look that bad anyome:

http://www.tcl.tk/software/tcltk/8.5.html
http://wiki.tcl.tk/13636

 

[bearophileHUGS]

Paul Rubin:

Python needs more stuff in its stdlib, not less.
If Tkinter doesn't satisfy, then add Gtk (or whatever) to the standard
distro. If that happens (i.e. some new toolkit is brought in and
declared to be the standard) then it might be ok to drop Tkinter but
it certainly shouldn't be dropped without a replacement.

If Tkinter is removed from the std lib, then I think another simple
GUI toolkit has to be added to replace it. I have appreciated Wax in
the past, it works with Wx and is rather easy. It's a dead software
now, but it can be improved. It can be almost as easy as Tk, and it
shows that Wx can be used with a much better API. Something like
gazpacho (http://gazpacho.sicem.biz/ ) can be created for Wax too, and
it can be added to the std lib.

Bye,
bearophile

 

[sturlamolden]

Thoughts anyone?

I don't use tk myself, but scheduling tkinter for vaporization would
be a bad idea. A lot of programs depend on it, and it doesn't look
ugly anymore (the one that ship with Python still does).

Would inclusion of wxPython and PyGTK in the standard library be an
option? Or does LGPL prevent it?

 

[Simon Forman]

Was looking at PEP 3108,http://www.python.org/dev/peps/pep-3108/,
and saw that the repr module was slated for vaporization. I've only
used the module a few times ever. I'm curious if the community wants
it kept around or whether it is considered clutter.

The PEP is going to be finalized soon, so if you have issues with it,
they should be sent to the PEP author or brought up on the list,
http://mail.python.org/mailman/listinfo/stdlib-sig.

Is it just me or others also think that it would be a major loss to
remove tkinter from the python core? PEP 3108 starts off with:

Each module to be removed needs to have a justification as to why it
should no longer be distributed with Python.

then goes on with,

With so many other GUI options out there that are considered better
than Tkinter, it might be best to remove Tkinter from the stdlib and
make it an externally maintained package.

I don't get it. There are many [insert your favorite software
component] options outside of the python core that are considered
better than the one coming with python, yet they don't get removed.
All network servers for example could be thrown out because twisted is
considered better. This just doesn't make sense to me. Tkinter is
great for its purpose, typical use cases are creating a simple GUI
composed of a couple of components only. You can nicely do this with
tkinter and the large user base shows that it's a real need real
people have. Sure, for fancy GUI stuff there are better options but
for quick and simple things tkinter is just great. And last time I
checked python comes with batteries included so why sould I need to
search and download a third party package for such a common use case?

Thoughts anyone?

Cheers,
Daniel

I've been thinking of volunteering to "port" Tkinter to Python 3.0, I
hadn't noticed that there was any discussion of removing it. It would
be a shame IMHO. Sure it has warts, but it /works/ and good for quick
and dirty GUIs as well as elaborate (even totally visually customized)
fancy applications.

~Simon

 

[dave_mikesell]

Is it just me or others also think that it would be a major loss to
remove tkinter from the python core? PEP 3108 starts off with:

I really like Python since I started using it a couple years ago, but
this is a huge turnoff and the kind of thing that keeps me using C++.
Stability is important. And I don't have any real code base. Can't
imagine those that have made a big investment in Python being all too
happy about the rug being pulled out from under them.

 

[Paul Boddie]

I've been thinking of volunteering to "port" Tkinter to Python 3.0, I
hadn't noticed that there was any discussion of removing it.

That's because the forum for discussing these things wasn't mentioned
on comp.lang.python until two days ago. Perhaps we're also about to
find out that the Vogons are showing up shortly.

Paul

 

[Terry Reedy]

| > Is it just me or others also think that it would be a major loss to
| > remove tkinter from the python core?
|
| That would be terrible. Every time I've tried to use one of the other
| packages it has led to installation hell. Tkinter isn't great, but
| it's extremely useful to have a gui module that's present
| automatically in every compete Python installation and that is
| reasonably cross platform. I can write a Python/Tkinter app under
| Linux and send it to Windows users and they can run it after a single,
| very simple Python installation from the Windows .msi. I have no
| Windows development tools whatsoever and very limited access to
| Windows boxes, so any Python code I deploy on Windows can't rely on
| any non-Python code outside of the stdlib.
|
| Also, because of tkinter's inherent limitations, I have the impression
| that upgrading it to the latest and greatest tcl/tk release wouldn't
| improve it much over the useful but low-rent module that it already is.
| Therefore, that supposed "benefit" of splitting it out to an external
| package is not much of a benefit.
|
| One of Python's traditionally best attractions has been the depth of
| its standard libraries, and backing away from that would be plain
| self-destructive. Python needs more stuff in its stdlib, not less.
| If Tkinter doesn't satisfy, then add Gtk (or whatever) to the standard
| distro. If that happens (i.e. some new toolkit is brought in and
| declared to be the standard) then it might be ok to drop Tkinter but
| it certainly shouldn't be dropped without a replacement.

I think this nicely summarizes the case against dropping tkinter (and
indeed, the case against shrinking the stdlib), like some devs (who mostly
une *nix) want to do. Perhaps someone can forward it to the lib-sig and/or
the Py3-devel lists.

tjr

 

[7stud]

| > Is it just me or others also think that it would be a major loss to
| > remove tkinter from the python core?
|
| That would be terrible.  Every time I've tried to use one of the other
| packages it has led to installation hell.  Tkinter isn't great, but
| it's extremely useful to have a gui module that's present
| automatically in every compete Python installation and that is
| reasonably cross platform.  I can write a Python/Tkinter app under
| Linux and send it to Windows users and they can run it after a single,
| very simple Python installation from the Windows .msi.  I have no
| Windows development tools whatsoever and very limited access to
| Windows boxes, so any Python code I deploy on Windows can't rely on
| any non-Python code outside of the stdlib.
|
| Also, because of tkinter's inherent limitations, I have the impression
| that upgrading it to the latest and greatest tcl/tk release wouldn't
| improve it much over the useful but low-rent module that it already is.
| Therefore, that supposed "benefit" of splitting it out to an external
| package is not much of a benefit.
|
| One of Python's traditionally best attractions has been the depth of
| its standard libraries, and backing away from that would be plain
| self-destructive.  Python needs more stuff in its stdlib, not less.
| If Tkinter doesn't satisfy, then add Gtk (or whatever) to the standard
| distro.  If that happens (i.e. some new toolkit is brought in and
| declared to be the standard) then it might be ok to drop Tkinter but
| it certainly shouldn't be dropped without a replacement.

I think this nicely summarizes the case against dropping tkinter (and
indeed, the case against shrinking the stdlib), like some devs (who mostly
une *nix) want to do.  Perhaps someone can forward it to the lib-sig and/or
the Py3-devel lists.

tjr

I think one of the advantages that python has over ruby is that python
comes with tkinter. For me, tkinter worked from the get go after I
installed python. I don't know if that's because my os already had
the necessary tcl/tk framework set up or not, but not having to go
through installation hell to get it working was nice.

On the other hand, Ruby doesn't come with a gui framework. And trying
to get Ruby tk working is a nightmare that I suspect many new
programmers will never accomplish, and therefore gui programming will
largely be inaccessible to them.

Since the adherents to the various languages like to list the reasons
why their language is better, removing tkinter from python will only
will make python's list shorter.

 

[Terry Reedy]

| I've been thinking of volunteering to "port" Tkinter to Python 3.0, I
| hadn't noticed that there was any discussion of removing it. It would
| be a shame IMHO. Sure it has warts, but it /works/ and good for quick
| and dirty GUIs as well as elaborate (even totally visually customized)
| fancy applications.

If you are serious, please communicate that willingness to the lib-sig.
A lack of such a volunteer would be a factor in dropping it.
The current developers are pretty well booked up with other stuff.

 

[Martin v. Löwis]

I've been thinking of volunteering to "port" Tkinter to Python 3.0, I

hadn't noticed that there was any discussion of removing it. It would
be a shame IMHO.

I don't think Tkinter will be removed. It works just fine in 3k.

Of course, if you would port IDLE to Tk 8.5: that would be a useful
contribution.

Regards,
Martin

 

[Guilherme Polo]

I don't think Tkinter will be removed. It works just fine in 3k.

Of course, if you would port IDLE to Tk 8.5: that would be a useful
contribution.

I'm interested in doing this, but are you aware of bugs yet ? I know
just one that is specific to Tk 8.5, this one being the background
color of the editor.

 

[Martin v. Löwis]

I'm interested in doing this, but are you aware of bugs yet ? I know
just one that is specific to Tk 8.5, this one being the background
color of the editor.

I just looked at it again, and it seems to work fine. Of course,
contributions to IDLE are always welcome, but this specific issues
seems to require no more intense attention.

Regards,
Martin