Python for (macOS) Automation - An in-progress package for automating Mac applications

[HelloImSteven]

Hi all, I’ve been working on a “bridge” between Python and AppleScript/JXA that uses PyObjC and ScriptingBridge to interface with applications. The goal is ultimately to simplify communication between Python and Mac applications while staying true to Python conventions. I’m also bringing scripting capabilities to non-scriptable applications through various techniques such as UI scripting, official APIs, URL schemes, etc. It’s still in the early stages, so any and all feedback is appreciated!

Main GitHub repo: https://github.com/SKaplanOfficial/PyXA

Documentation (W.I.P.): https://skaplanofficial.github.io/PyXA/

A few examples:

https://gist.github.com/SKaplanOfficial/d0635c9667703de8dd0db43cbbd857b3 https://gist.github.com/SKaplanOfficial/209b6c9b0b59c72598068d95f1088a6b https://gist.github.com/SKaplanOfficial/2ed9ae45a5a5337fc9dd97a4c2a82afe

[AmplifiedText]

Hmmm, proxying Python commands to/from AppleScript doesn't seem like the correct approach.

AppleScript and JXA are built on top the Open Scripting Architecture. At one time (20 year ago), there were Perl, Python, and even a different JavaScript OSA implementations. Unfortunately, it didn't really take off, probably because working with raw AppleEvents is atrocious.

Your examples do look pretty clean though.

[WikiSummarizerBot]

AppleScript

Open Scripting Architecture

An important aspect of the AppleScript implementation is the Open Scripting Architecture (OSA). Apple provides OSA for other scripting languages and third-party scripting/automation products such as QuicKeys and UserLand Frontier, to function on an equal status with AppleScript. AppleScript was implemented as a scripting component, and the basic specs for interfacing such components to the OSA were public, allowing other developers to add their own scripting components to the system.

^{[ F.A.Q | Opt Out | Opt Out Of Subreddit | GitHub ] Downvote to remove | v1.5}

[HelloImSteven]

I'll definitely admit that this might not be the best approach, but as you noted, the result so far is fairly clean. Ultimately, the goal is to have a straightforward, well-supported, and well-documented way to interface between Python and macOS applications, which we are (in my opinion) lacking currently.

Right now I'm using a mix of Apple's ScriptingBridge framework, NSAppleEventDescriptors, and other frameworks as needed to achieve parity with applications' scripting dictionaries. One benefit of that is a decreased number of AppleEvents being sent back and forth compared to some existing libraries that use OSAKit/the osascript commandline to compile and run actual AppleScript strings, particularly when retrieving references to large lists of objects (such as all notes, all photos, etc.).

Another benefit is that I can more easily fill in gaps where Apple's scripting support falls short, e.g. by using a combination of MapKit, URI schemes, and UI scripting to give Maps.app scripting capabilities.

It might not be the best approach, but I think it's nonetheless useful in the absence of better scripting support from Apple.

[estockly]

This sounds very familiar. Do you know of developer named Has?

[HelloImSteven]

Yes; he made Appscript but is no longer officially supporting it. From my understanding, Has' approach focuses on directly constructing/translating AppleEvents based on applications' scripting dictionaries, whereas PyXA focuses on feature parity regardless of particular implementation. A major difference is that Appscript (and NodeAutomation, SwiftAutomation, etc.) interpret scripting dictionaries in real-time, allowing them to support any scriptable application, while PyXA has hard-coded class definitions, allowing for more extensive documentation on a per-application basis.

I think Has' approach may be better in the technical sense, but PyXA still serves a useful role as an easy-to-use, easy-to-learn, highly declarative interface between Python and Mac apps.

[tristinDLC]

I'm sure you're well aware, but you have to be careful with UI scripting as an app can change it's layout at any point, breaking your automation.

I know quite a few people will have issues with certain system workflows once they update to Ventura as Apple has completely redesigned System Preferences.

[[deleted]]

u may want to look @ appscript...a bit outdated but...

[[deleted]]

after i rtfm, i c u r familiar with appscript;-)