beginners choice: wx or tk?

[Chris Angelico]

On Sat, Jul 11, 2015 at 7:51 PM, Ulli Horlacher
<framstag at rus.uni-stuttgart.de> wrote:
> Chris Angelico <rosuav at gmail.com> wrote:
>
>> On Sat, Jul 11, 2015 at 7:28 PM, Ulli Horlacher
>> <framstag at rus.uni-stuttgart.de> wrote:
>> > I want to start a project with python.
>> > The program must have a (simple) GUI and must run on Linux and Windows.
>> > The last one as standalone executable, created with pyinstaller.
>>
>> Not sure what your advantage is with pyinstaller, it adds a level of
>> complication that doesn't usually justify itself IMO.
>
> I am not addicted to pyinstaller. It just works.
> Do you have a better alternative?
>
>
>> Using wxPython means you need another library, while tkinter comes
>> with Python.
>
> pyinstaller can make a standalone executable, there is no need for the
> users to install "another library". They just click on the program icon,
> that's it.

Yeah, I'd distribute the .py files and have done with it. Maybe do it
up as a package and distribute it via pip, which allows you to fetch
dependencies automatically. The supposed ease of "just click on the
program icon" is all very well, but it means you have to have a
whopping new download any time there's an update to your code (they
have to redownload the entire binary even if you're using the same
Python and the same libraries), and you have to distribute a whole
bunch of different versions (32-bit vs 64-bit, possibly different
builds for different Windowses, etc), and deal with the support issues
from people who grabbed the wrong one. Once Python itself has been
installed, users can still normally "just click on the program icon"
even though it's a .py file - that's the whole point of file
associations. And then their installed Python can be updated by the
normal mechanisms, and your code will happily run on the new version.
Suppose, for instance, that your program does something over HTTPS,
and people are using it in a critical environment... and then someone
discovers a flaw in OpenSSL, which has happened now and then. A bugfix
release of CPython will fix that instantly for everyone who's using
the standard python.org downloads; but if you've packaged up your own
Python, it'll be frozen at whatever version you had when you built
that - which might not even be the latest available at the time. How
quickly will you get around to building new installers?

Much better to distribute Python code without an interpreter, and let
people get their own interpreters.

ChrisA