5 ms·
Python with a Cocoa GUI on MacOS
- Apocryphon 8y agoInterestingly enough Kivy and Beeware are attempts to create Python mobile development frameworks: https://dbader.org/blog/python-mobile-development-kivy-vs-beeware https://dbader.org/blog/python-mobile-development-kivy-vs-be... https://www.youtube.com/watch?v=qaPzlIJ57dk https://www.youtube.com/watch?v=qaPzlIJ57dk
- lukewrites 8y agoI love Beeware not only for their puns ("The IDEs of March", etc), but also for the clarity of their documentation. Kivy is very interesting to me – I've been meaning to pick up Dusty Phillips's book about it.
- rcarmo 8y agoThey 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 8y agoPyObjC, 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 8y agoPyQt packaging is no longer hard with https://build-system.fman.io https://build-system.fman.io. (I'm the author.)
- ngcc_hk 8y agoAny 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 8y agoIt's only for desktop for now, sorry.
- tossaway44 8y agoThat looks awesome. I do have personal concerns about GPL, though (which is why I avoid Qt - everything I do these days is either MIT or Apache licensed).
- jchw 8y agoQt itself has been LGPL for many years now, pretty sure it has been since sometime when Nokia owned it.
- blattimwind 8y agoAnd it had a licensing exception for pretty much every OSI license for years before that. Anyone still talking about Qt licensing is spreading FUD from well over 15 years ago.
- lapnitnelav 8y agoThat looks cool, will probably give it a try. Cheers.
- aportnoy 8y agoI had a great experience with PySide2 (aka Qt for Python), although the docs still have examples in C++ (that are supposed to be in Python) sprinkled everywhere.
- sigjuice 8y agoI have always been curious, what is Apple's motivation for shipping Python with macOS?
- grzm 8y agoI 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 8y agonot to mention ls, gcc, perl, httpd, and the rest of the BSD subsystem on which it is based
- jhfdbkofdcho 8y agoA bunch of system utilities are implemented against the version of Python that ships with OS X. Grep and ask are there for POSIX compatibility, right?
- mrpippy 8y agoThe Calendar and Contacts Server that used to come with macOS Server is written in Python, I can’t think of any system utilities implemented with Python though. And once Python comes with the system (I think it has since at lest 10.4), they can’t remove it without breaking apps that depend on it.
- hyperjeff 8y agomacOS (in its NeXT-based lineage) has always come with many scripting languages (php, perl, python, ruby, applescript, awk, *sh, etc) as part of a standard unixy setup, even before Apple themselves made use of them per se in the system. While they make use of Python currently, it's there also just to enable whatever things a user or a 3rd party may build.
- rcarmo 8y agoIt’s been there forever. In fact, Apple used to have semi-official documentation on PyObjC at one point.
- deleted 8y ago[deleted]
- mistrial9 8y agoIt was great to see a one-window BitTorrent client 14 years ago on MacOS, native GUI but lots of python underneath..
- rcarmo 8y agoI’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
- laingc 8y agoOff-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.
- fiddlerwoaroof 8y agoMy general experience was that idiomatic Python generally uses snake_case for method and function names (at least, this was true of Python 2, before I stopped using python regularly)
- fiddlerwoaroof 8y agoI believe this is camelCase because of objc requirements (I’ve run into similar annoyances working on my Common Lisp bindings to cocoa.)
- bobwaycott 8y agoIt’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 8y agoThat makes sense. It's good that PEP8 makes exceptions for such cases, I suppose, but it just looks wrong to my eye.
- pornel 8y agoI'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.
- netheril96 8y agoHow do people deal with GIL when writing GUI code in Python? Without multithreading computation will block UI.
- lozenge 8y agoGIL 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.
- matchbok 8y agoEvery time I see Interface Builder I cringe. How Apple thinks it is a suitable way to construct GUIs is crazy to me.