WxPython versus Tkinter.

[Stephen Hansen]

On 1/24/11 2:16 PM, rantingrick wrote:
> On Jan 24, 3:58 pm, Infinity77 <andrea.gav... at gmail.com> wrote:
> 
>> I have been involved in the wxPython development for many years
>> (mostly on implementation of custom widgets, in the AGW library), and
>> I share Robin's concerns about this kind of "publicity" given to
>> wxPython.
> 
> Who cares what you think about wxPython's publicity. A module was
> created and put on public display and can be ridiculed or supported by
> anyone who so desires.
> 
>> Python comes with TK as a "battery included" UI toolkit. I'm perfectly
>> fine with this, as I am not going to use it anyway. Whether in the
>> future TK will be replaced by PyGTK, PyQT, PySide, etc... in the
>> standard library, it won't make any difference to those aficionados
>> developers who use wxPython. We'll still download the wxPython
>> binaries/sources/whatever and use it to develop our own GUIs.
> 
> Good, and again i cannot stress how little we care about your opinion.
> Why do we not care. Well because you are looking at this from a
> wxPython perspective. You are being selfish. We are considering this
> from a global Python perspective. What is good for Python may not be
> good for you, in any event, it is for us to decide. You can join our
> discussion when your perspective changes from "me" to "us". And the
> "us" is the Python langauge NOT wxPython.
> 
> 
>> It is very unfortunate that this topic "wxPython vs. Tkinter" has
>> drifted to another flame war,
> 
> There is no flame war here
> 
>> as there is really no point in this kind
>> of discussion.
> 
> Says you. but who are you to say what is important to us. Go back to
> wxPython.
> 
>> As a general rule, a GUI-newbie should try all the GUI
>> toolkits out there and settle with the one which looks easier/nicer/
>> more convenient/more feature rich. As usual, it is a matter of
>> personal taste.
> 
> And i agree. I think any sane person could agree also. However you
> miss the point of this conversation. We are looking at Python from a
> global perspective. You are limited in your views, and obviously very
> biased. And i know the real reason you and Robin do not want wxPython
> in the stdlib. Because you do not want to lose your selfish status
> within the wxPython community. When wxPython becomes a stdlib module
> then you will answer directly to Guido and Python-dev. You are not
> fooling anyone with this grandstanding.

I can't believe I'm actually getting into this, but--

wxPython is open source, and technically anyone has the legal right to
include it in whatever they want -- but no module goes into stdlib,
period, without it being donated by its authors for that purpose.
Period. Python-dev is not so discourteous as to absorb someone elses
code without their go-ahead (and more then that: they don't generally
absorb anyone elses code without that person making a _commitment_ to
supporting it, in the stdlib, for multiple years).

So: no author answers to Guido unless they decide they want to.

Not that I'm suggesting Robin wouldn't go for it if someone with actual
standing asked: but I'm not suggesting he would, either. I have no idea
if the stdlib development cycle fits the wxPython one, since wxPython
tracks wxWidgets releases. (Totally notwithstanding the elephant in the
room that nothing new is going to go into 2.x at all, and wxPython
doesn't presently support 3.x.)

Robin actually has an unappealable veto over the whole idea, if he so
chose to exercise it.

Just thought I'd interject some reality into your delusion that there is
some Python Kingdom and that King Guido can "decide" all manner of
things and it'll cause them to happen.

But we've had this conversation before, you and I.

Also, rick != the_community. You don't get to speak for "we".

But we've had that conversation too, you and I.


-- 

   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/20110124/95398dac/attachment-0001.sig>