
Python with a Cocoa GUI on MacOS - sacheendra
https://dawes.wordpress.com/2017/08/17/python-with-a-cocoa-gui-on-macos/
======
pornel
I've used it for [https://pngmini.com](https://pngmini.com), and I regret it.

• Startup time is noticeably slower than native apps. Importing Cocoa makes
Python parse a ton of code.

• Cocoa just doesn't fit Python's naming conventions. You get long method
names with underscores where arguments should be, followed by many unlabelled
arguments. The worst thing is that 1-arg methods, which otherwise look like
normal Python methods, have to have an underscore suffix (`foo_`).

• All errors are runtime errors. It's a step back from ObjC, and the
aforementioned writing of `[obj foo:arg]` as `obj.foo_(arg)` gets me every
time. Python is also more sensitive about None than ObjC is about nil, so you
need more checks and forgotten checks blow up more often.

• I wanted to do more advanced stuff with CoreAnimation and PyObjC couldn't
figure out how long to retain stuff (or it was a bug somewhere). I know how to
debug such problems in ObjC (and they're rare since ARC), but having Python's
GC and a large framework sandwiched in between made it hard.

• The app breaks when users replace macOS's old Python with their own, which
lacks PyObjC support. I don't know how common that is, but I've been getting
bug reports about it.

In the end I ended up rewriting large parts in ObjC, and the remaining Python
code is slow and brittle.

These days there's Swift which isn't more laborious to write than Python
thanks to type inference and ARC, but has compile-time checks, non-nullable
types and first-class Cocoa interface.

------
Apocryphon
Interestingly enough Kivy and Beeware are attempts to create Python mobile
development frameworks:

[https://dbader.org/blog/python-mobile-development-kivy-vs-
be...](https://dbader.org/blog/python-mobile-development-kivy-vs-beeware)

[https://www.youtube.com/watch?v=qaPzlIJ57dk](https://www.youtube.com/watch?v=qaPzlIJ57dk)

~~~
rcarmo
They are OK but I had trouble with Kivy’s Python 3 support and pyenv and the
apps don’t look native (which is a secondary concern for most people these
days, sadly, but an issue for most Mac users)

------
toyg
PyObjC, which is what is being used here, is nice, but pretty fragile. It
relies pretty much on one guy, Ronald Oussoren, who is also one of the py2app
maintainers. It often lags behind the pace of macOS development.

I think PyQt is a more robust solution for GUIs, and it gives you cross-
platform compatibility basically for free - although packaging is probably a
bit harder.

~~~
mherrmann
PyQt packaging is no longer hard with [https://build-
system.fman.io](https://build-system.fman.io). (I'm the author.)

~~~
ngcc_hk
Any mobile option? I sort of see pythonista on ipad can do it ... just wonder
any other option of packaging gui that really cross all platforms not just
desktop.

~~~
mherrmann
It's only for desktop for now, sorry.

------
rcarmo
I’ve been doing this for a while now for small utilities, and got started on
it in earnest with
[https://github.com/rcarmo/shelf](https://github.com/rcarmo/shelf) (which I
used for a long time until LinkedIn broke their APIs).

There are mainly two challenges here:

\- packaging (it’s a bit tricky to sort out, and bundling a full virtualenv is
the best long-term option across OS releases)

\- longevity (Ronald has been maintaining PyObjC on his own dime, and Apple
seems to mostly ignore everything else in favor of Swift these days)

The JavaScript bridge also works OK (I briefly considered using that instead,
but the way collections are handled is hideous due to language constraints and
PyObjC is so much better).

Edit: bullets

------
sigjuice
I have always been curious, what is Apple's motivation for shipping Python
with macOS?

~~~
grzm
I don’t believe there’s any special motivation for including Python than what
motivates the inclusion of any other of the common Unix tools such as Ruby,
Git, grep, or awk.

~~~
feelix
not to mention ls, gcc, perl, httpd, and the rest of the BSD subsystem on
which it is based

------
mistrial9
It was great to see a one-window BitTorrent client 14 years ago on MacOS,
native GUI but lots of python underneath..

------
laingc
Off-topic Python question: is the use of “CapWords” / CamelCase for method
names correct here? I assume this is the “prevailing style” of pyobjc or
Objective C itself, and it therefore comes under the exception in PEP8.

I ask because I find the use of CamelCase like this for method names really
off-putting.

~~~
bobwaycott
It’s a byproduct of Objective C. It’s pretty common to see just about anything
that provides bindings/bridges into ObjC to match the casing of the ObjC
code—this is typically to help with matching and looking up relevant ObjC
documentation to understand the original code better. It is off-putting, for
sure.

~~~
laingc
That makes sense. It's good that PEP8 makes exceptions for such cases, I
suppose, but it just looks wrong to my eye.

------
matchbok
Every time I see Interface Builder I cringe. How Apple thinks it is a suitable
way to construct GUIs is crazy to me.

------
netheril96
How do people deal with GIL when writing GUI code in Python? Without
multithreading computation will block UI.

~~~
lozenge
GIL is released when a thread is waiting on a queue. One thread reads UI event
queue from the OS and puts user actions into a queue, another runs your code.

