beginners choice: wx or tk?

[Grant Edwards]

On 2015-07-14, Chris Angelico <rosuav at gmail.com> wrote:
> On Wed, Jul 15, 2015 at 3:28 AM, Grant Edwards <invalid at invalid.invalid> wrote:

>> Comparing the size of Tcl+Tk and wx/Gtk doesn't really make sense
>> either since we're talking about MS Windows targets.  Gtk isn't
>> involved.  wxWindows on MS Windows runs on top of native widgets, not
>> on top of Gtk.
>
> Well, let's look at three straight-forward options:
>
> 1) Python program uses tkinter
> 2) Python program uses wxPython
> 3) Python program uses PyGTK
> 4) (optionally) Python program uses PyGObject
>
> Then you package your script up with all of its dependencies - Python
> interpreter, GUI toolkit, and everything that they depend on - and see
> how big it is. That's the comparison that matters; everything else is
> implementation detail.
>
> I had been under the impression that tkinter + Tcl + Tk + etc etc etc
> was smaller than wxPython + wxWidgets + etc etc etc, but it's entirely
> possible I'm flat wrong on that.

The last time I did exactly that comparison, the tk option was larger.
That was 2-3 years ago, and it's quite possible the py2exe
configuration I was using for the tk option could have been optimized
more to get rid of libraries that py2exe thought were needed but were
in fact not needed.  Once the download gets below about 25MB, nobody
seems to care about the size.

> It doesn't matter how Python is normally shipped, it matters how big
> it's going to be when you make that single-executable package.

Right.  And in practice, I find that doesn't actually matter either.
Python+<any-GUI-of-choice> is small compared to a lot of the things
people are used to downloading.

> But I still think it's better to *not* do that, because you bind your
> deps to your code release cycle. If you make this kind of package,
> most people won't know how to unwrap it and get the Python scripts out
> of it, so the only thing they can do is upgrade to the latest release
> that you've made. So when Python 2.7.11 comes out, maybe with some
> crucial security patch that an end user needs, s/he has to wait for
> you to make a new package that incorporates the latest Python. If you
> ship just the .py files, you're responsible for your own code and
> nothing else.

Maybe your Windows audience is different than mine.  Mine absolutely
will not tolerate anything other than a single myapp-setup.exe or
myapp.msi file.  They will not can not install Python, update Python,
or update the Python scripts independently of the exe/msi single-blob.

If you depend on an external Python installation or make a bundled one
visible to the user, you're just digging yourself a hole.  They'll
screw up the external Python installation somehow or they'll uninstall
a bundled but exposed Python installation and then call in complaining
the app doesn't work.

-- 
Grant Edwards               grant.b.edwards        Yow! Jesuit priests are
                                  at               DATING CAREER DIPLOMATS!!
                              gmail.com