Mac: a certain range of ints doesn't get transferred

[fzumstein]

from appscript import app

# Works
app('Microsoft Excel').workbooks['Sheet1'].active_sheet.cells['$A$1:$A$1'].value.set(1)

# Doesn't work
app('Microsoft Excel').workbooks['Sheet1'].active_sheet.cells['$A$2:$A$2'].value.set(2999999999)

# Works
app('Microsoft Excel').workbooks['Sheet1'].active_sheet.cells['$A$3:$A$3'].value.set(float(2999999999))

# Works
app('Microsoft Excel').workbooks['Sheet1'].active_sheet.cells['$A$4:$A$4'].value.set(1.22e19)

[fzumstein]

Answer by Hamish Sanderson, developer of the appscript package:

AppleScript packs integers larger than SInt32 as typeIEEE64BitFloatingPoint (aka Double).

Py-appscript packs integers larger than SInt32 but smaller than SInt64 as typeSInt64, and integers larger than SInt64 as typeIEEE64BitFloatingPoint.

This gives better precision (since Doubles can't encode the full range of 64-bit ints without loss), but can cause compatibility issues with applications that only expect typeSInt32 or typeIEEE64BitFloatingPoint. Applications are supposed to coerce descriptors to the types they require when unpacking them (e.g. coerce to typeSInt32, and if that fails coerce to typeIEEE64BitFloatingPoint), but some of the naughtier Carbon ones just check the descriptor types directly and throw an error if it's not exactly what they expect.

You can either hack the aem.aemcodecs.Codecs.packInt() method to mimic the AppleScript way of doing things more closely, or just cast integers larger than SInt32 to doubles before passing them to Excel, as your examples do. With the rest of the world moving to 64-bit, py-appscript's current behavior is not unreasonable, though it's the sort of thing for which I'd have traditionally put in a 'mimic AppleScript exactly' compatibility switch (the Codecs class already contains several of these). Py-appscript maintenance is very low priority for me these days, but I'll make a note of it for the SwiftAE bridge I'm now working on (https://bitbucket.org/hhas/swiftae).

HTH

has