[Code Challenge] WxPython versus Tkinter.

[alex23]

A vision that
is representative of ALL the people -- and not a few fat cats at the
top.
[...]

This is the only way we can truly
understand what our community members are thinking about Tkinter.
Anything else is purely speculation.
[...]

Many folks out there share our views that Tkinter is a weight around
Python's neck, however they are too fearful to speak out for fear of
excommunication (the kill file!).

So even though the majority of opinions are counter to yours, those
people are the arrogant 'fat cats' who aren't listening to 'the
people'? You criticise others for making generalised statements about
the desires of other coders, but you believe that you speak for a
silent majority, whose presence is somehow known and sensed by you
through some magical force?

Can we all just accept that rr/rantingrick is a troll and let these
thread die? This is, what, the 3rd? 4th? year of his endless tirade
against TKinter. Most people with an actual problem WOULD HAVE
RELEASED CODE BY NOW.

 

[alex23]

Not if we used the underlying MS library! Windows has such a rich
library why not use it? Why must we constantly re-invent the wheel?

Isn't restricting a GUI toolkit to just one of the major OSes the
absolute opposite of 'accessible'?

 

[alex23]

It is very unfortunate that this topic "wxPython vs. Tkinter" has
drifted to another flame war, as there is really no point in this kind
of discussion.

I don't think it's wxPython that's causing the flames in this
thread

 

[rantingrick]

This is, what, the 3rd? 4th? year of his endless tirade
against TKinter.

Alex, i have not been against Tkinter for 4 years. I just recently
realized (about a year ago) the limitations of Tkinter and started
thinking of alternatives.

Tip of the day: Before misrepresenting someone's position and
overshooting an estimate by three years, first make sure you've
actually read most of what they have written.

HTH

 

[rantingrick]

Isn't restricting a GUI toolkit to just one of the major OSes the
absolute opposite of 'accessible'?

You'll need to read that snippet in context to understand what i was
talking about. Again, see my "tip of the day" in my last post to you.

 

[Octavian Rasnita]

in? Robin Dunn is the wxPython project lead.

Ok, in this case I understand why WxPython can't be included in stdlib.
I think there was a communication problem because the oldest list members
start with the idea that all the list members know who is who and they may
be thinking that I don't want to accept the reality or that I have bad
feelings about some list members or something like that.

There is a large difference between the being "promoted by Python" and
being "included in Python's standard library. The latter is the issue at
hand, not the former. wxPython is already "promoted" by Python's
documentation:

If there is a bigger chance that a beginner start using Tkinter without
knowing its issues, this means that Python promotes the wrong tool.
As I said, the main issue is not that Python doesn't promote WxPython. I
have even suggested that Python might not include any GUI if this would be
prefered, but what's wrong is that Python promotes a GUI which is not
accessible by including it as a default GUI.

As we all know, Python doesn't care too much about maintaining a backward
compatibility and there are much many other things which are not compatible
between different Python versions, but some Python programmers consider this
a virtue because they say that what was wrong was eliminated. If they are
right, then why wouldn't be a good idea to also remove a wrong GUI lib? Just
because the majority prefers it?


Octavian

 

[Emile van Sebille]

On 1/26/2011 11:02 PM Octavian Rasnita said...

As we all know, Python doesn't care too much about maintaining a
backward compatibility

Where'd you get this idea? Between v2 and v3 yes, that was the intent.
But otherwise, I think there's another miscommunication behind this...

See http://www.python.org/dev/peps/pep-0291/

Emile

 

[Stephen Hansen]

As we all know, Python doesn't care too much about maintaining a
backward compatibility

What? Nonsense.

There are strict compatibility requirements.

There was a one-time break with these; 2.x->3.x -- but that's it. It may
never happen again. If another happens, its years down the road. If ever.


--

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJNQaRzAAoJEKcbwptVWx/lSTAIAKoIG77aeUSKkP5sYOkZB+8t
mmkiqW5ssZOik61ZQBnaBid2mRbGuWsLR4U6xa4uPxdZ3CJG1nKyPfYKb3Odgqm9
EHp3drieZYH+/9zgqT7TMfLe21Z2RKKSBacpSPviYkr7yRQQU1fwwohqLRHutzi+
ylrfnMiW72X0ouxZZi79RpgmKIVHmHkplhOAQPhCXJpocgXPTKc8778bdCJYanoD
d8ccwP+Omosdb2aLMKNiNLIZ+2XYu31x2Mm1WimxEllYvKj6uAxsrUUeF5auH6It
EkoHuM8abHRQe/qxwoPJAd3Qy/iGW8jjm1DajIU15hCENjYLa+YC45pzflrARSE=
=d+Yf
-----END PGP SIGNATURE-----

 

[Mark Roseman]

Tk itself is purely a gui package -- abstract widgits, geometry placers
to make them visible, and an event system to make them active. But it
does have the baggage of needing tcl included. About a decade ago, some
people had the idea of removing the tcl dependency, but nothing seems to
have come of that. For some people, the tcl baggage is reason enough to
be rid of tk.

Thanks for raising this point. While I don't want to exhaustively
respond to this, I would like to raise a few important points.

1. The performance issues of having Tk use Tcl are negligible; the bulk
of Tk (code-wise and time-wise) are spent in C. Tcl itself is also very
fast nowadays, using all the usual techniques that modern dynamic
languages use.

2. Some people do have moral/purity objections to including Tcl, and
while I understand where the sentiment comes from, I think there are few
solid engineering reasons for this.

3. Removing Tcl from Tk makes keeping up with changes in Tk very
difficult. The Perl people found this out; Perl/Tk extracted Tcl, and
as a result remained using a 10 year old version of Tk because upgrading
would have been too painful. The newer Perl binding (Tkx) is in fact a
ridiculously thin binding over the Tcl API, and makes keeping up to date
with the newest Tk changes trivial, often requiring no code changes in
the Perl binding.

If anyone does have questions, comments or concerns about Python
including a Tcl interpreter to use Tk, I'd be happy to try to explain or
address them.

Mark

 

[Octavian Rasnita]

On 1/26/2011 11:02 PM Octavian Rasnita said...


Where'd you get this idea? Between v2 and v3 yes, that was the intent.

To be sincere I was thinking to the differences between Python 2 and 3.

But otherwise, I think there's another miscommunication behind this...

It might be true, however I have seen some modules that say that are ment for Python 2.5, for 2.6 or for 2.7, so there seem to be differences between these versions also.

py2exe offers the following installation kits, depending on the Python version. If you know, please tell me why there are different packages for different versions of Python?

py2exe-0.6.9.win32-py2.5.exe
py2exe-0.6.9.win32-py2.4.exe
py2exe-0.6.9.win32-py2.3.exe
py2exe-0.6.9.win32-py2.6.exe
py2exe-0.6.9.win32-py2.7.exe

Thanks.

Octavian

 

[Emile van Sebille]

On 1/27/2011 10:09 AM Octavian Rasnita said...

To be sincere I was thinking to the differences between Python 2 and 3.


It might be true, however I have seen some modules that say that are ment for Python 2.5, for 2.6 or for 2.7, so there seem to be differences between these versions also.

Yes - but don't confuse forward compatibility (which means programs you
write today in the current version will work on the prior versions) with
backward compatibility (which means programs written for earlier
versions will run under newer versions)

I suspect that a lot of python 1.x code will work just fine under 2.x
just as most 2.n will work under 2.m (where m>n). There are few
exceptions, and those mostly in the standard library. I recall only
getting stung once (something to do with passing in a tuple instead of
two parameters in one or another imported module).

Emile

 

[Giampaolo Rodolà]

It might be true, however I have seen some modules that say that are ment for Python 2.5, for 2.6 or for 2.7, so there seem to be differences between these versions also.

Python cares *a lot* about maintaining backward compatibiilty between
all major versions.
This is so true that I managed to use a unique code base for pyftpdlib
which supports python from 2.3 to 2.7.
Same for psutil which covers versions from 2.4 to 3.2 by using a
unique code base!

It might be true, however I have seen some modules that say that are ment for Python 2.5, for 2.6 or for 2.7, so there seem to be differences between these versions also.

Usually the differences between one version and another rely on *new
features* only.
One might decide to target a module only for a certain version of the
2.x serie because that certain version introduced a new functionnality
which was not available before (silly example
http://docs.python.org/library/os.html#os.initgroups ).
All the other functionnalities are likely to remain the same and fully
backward compatible.

py2exe offers the following installation kits, depending on the Python version. If you know, please tell me why there are different packages for different versions of Python?

py2exe-0.6.9.win32-py2.5.exe
py2exe-0.6.9.win32-py2.4.exe
py2exe-0.6.9.win32-py2.3.exe
py2exe-0.6.9.win32-py2.6.exe
py2exe-0.6.9.win32-py2.7.exe

That's a different story: those are pre-compiled binaries which are
generated from a *unique* source code which support all those
versions.
If you have a compiler you can install pywin32 extension by using any
Python version.


--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/

 

[Terry Reedy]

Thanks for raising this point. While I don't want to exhaustively
respond to this, I would like to raise a few important points.

1. The performance issues of having Tk use Tcl are negligible; the bulk
of Tk (code-wise and time-wise) are spent in C. Tcl itself is also very
fast nowadays, using all the usual techniques that modern dynamic
languages use.

I have the impression that tcl is mostly used in initial setup and
configuration, as opposed to repetitive drawing to the screen. But I do
not really know.

2. Some people do have moral/purity objections to including Tcl, and
while I understand where the sentiment comes from, I think there are few
solid engineering reasons for this.

There are two types of objections which have much less force now than a
decade ago. One is the size issue. A tcl-less tk would presumably be
smaller and thus add less to the Window distribution. The other is that
tcl and Python were once seen as competing scripting languages, so why
promote the competitor? Well, if there really was a contest, Python won.

3. Removing Tcl from Tk makes keeping up with changes in Tk very
difficult. The Perl people found this out; Perl/Tk extracted Tcl, and
as a result remained using a 10 year old version of Tk because upgrading
would have been too painful. The newer Perl binding (Tkx) is in fact a
ridiculously thin binding over the Tcl API, and makes keeping up to date
with the newest Tk changes trivial, often requiring no code changes in
the Perl binding.

Good point. Python should (continue to) just use the latest tk from its
maintainers. If *they* were to decouple it from tcl (unlikely, it
seems), fine. If not, so be it ;-).

If anyone does have questions, comments or concerns about Python
including a Tcl interpreter to use Tk, I'd be happy to try to explain or
address them.

Thanks for the additional info. We need more of that.

 

[Mark Roseman]

I have the impression that tcl is mostly used in initial setup and
configuration, as opposed to repetitive drawing to the screen. But I do
not really know.

Tcl as a scripting language is used during some initialization things,
used to invoke callbacks, and a few other non-performance critical areas.

It sometimes helps to think of Tcl as a very powerful C library that
happens to have a scripting language on top. For example, there are
C functions in the Tcl library that do things like string management,
cross platform I/O, very efficient hash tables, dynamic lists, etc. that
are used everywhere inside Tk. But none of those calls mean a trip
through the Tcl interpreter per se.

Every dynamic language would have similar internals of course, though
with slight differences and different API's.

Mark

 

[alex23]

You'll need to read that snippet in context to understand what i was
talking about. Again, see my "tip of the day" in my last post to you.

Pass. I'd have to see value in what you say inside of the endless
masturbatory self-aggrandizement that you pass off as "visionary"
posts. Instead it's all blah blah blah RUBY ASSHOLES blah blah
INCOHERENT IDEA blah LAZY BASTARDS WHO DON'T APPRECIATE ME etc etc

 

[Corey Richardson]

Pass. I'd have to see value in what you say inside of the endless
masturbatory self-aggrandizement that you pass off as "visionary"
posts. Instead it's all blah blah blah RUBY ASSHOLES blah blah
INCOHERENT IDEA blah LAZY BASTARDS WHO DON'T APPRECIATE ME etc etc

Because insults and flaming totally get anyone anywhere.
If you don't have anything civil to say, don't say it at all (Because
sometimes un-nice things need to be said).

 

[alex23]

Ok, in this case I understand why WxPython can't be included in stdlib.
I think there was a communication problem because the oldest list members
start with the idea that all the list members know who is who and they may
be thinking that I don't want to accept the reality or that I have bad
feelings about some list members or something like that.

The only expectation I as a list member have of you is that you maybe
hit the web and do a bit of search & research before starting on an
endless tirade. Implying that it was the responsibility of everyone
here to explain every little aspect of an issue you're supposedly
passionate about makes you seem either lazy or ignorant.

 

[Octavian Rasnita]

py2exe offers the following installation kits, depending on the Python
version. If you know, please tell me why there are different packages for
different versions of Python?

py2exe-0.6.9.win32-py2.5.exe
py2exe-0.6.9.win32-py2.4.exe
py2exe-0.6.9.win32-py2.3.exe
py2exe-0.6.9.win32-py2.6.exe
py2exe-0.6.9.win32-py2.7.exe

That's a different story: those are pre-compiled binaries which are
generated from a *unique* source code which support all those
versions.
If you have a compiler you can install pywin32 extension by using any
Python version.


Thank you Giampaolo. Now I understand and it is a good thing.

Octavian

 

[Octavian Rasnita]

The only expectation I as a list member have of you is that you maybe
hit the web and do a bit of search & research before starting on an
endless tirade. Implying that it was the responsibility of everyone
here to explain every little aspect of an issue you're supposedly
passionate about makes you seem either lazy or ignorant.

Hi Alex,

You are right, I was lazy and didn't searched on the net to find who are all
the list members that answered to my posts for understanding better their
position, so it's my fault.

Octavian

 

[sturlamolden]

It is time to prove once and for all how dated and worthless Tkinter
is compared to wxPython. Yes, WxPython is not as advanced as i would
like it to be for a 21st century GUI library.

So use PyQt instead.

However compared to
Tkinter, Wx is light years ahead! Wx is our best hope to move Python
into the 21st century.

I vaguely someone saying that about Borland VCL and C++. Now people
harly remember there was a RAD product called Borland C++ Builder,
with a sane GUI API compared to Microsoft's MFC.

I for one do not like to handcode GUIs. That is why I use
wxFormBuilder, and the availability of a good GUI builder dictates my
choise of API (currently wxPython due to the previously mentioned
product).

Sturla