[Pythonmac-SIG] 64-bit support

[has]

On 4 Nov 2007, at 15:18, Ronald Oussoren wrote:

>> Currently working on the next appscript release and wondering if
>> anyone has any thoughts on whether or not I should prioritise 64-bit
>> support (which means reworking its various C extensions to eliminate
>> their dependence on Python's Carbon extensions)? How important is
>> providing 64-bit support at the moment?
>
> None of the GUI frameworks support 64-bit code at the moment, so I'd  
> say "not very".

You mean Python GUI frameworks (PyObjC, wxPython, etc.), yes?


> That said: how much work would it be to make appscript 64-bit clean?


Depends. If I don't bother waiting for Python's Carbon extensions to  
go 64-bit first (which I'm guessing is no time soon), then under a  
week if I'm not concerned about backwards compatibility in the low- 
level and more obscure APIs:

- remove CarbonX.OSA and osascript to a new package separate to  
appscript which can be worked on in its own time

- drop support for Carbon.File-related convenience methods in the  
mactypes module's Alias and File classes

- eliminate dependency on pymactoolbox in CarbonX.AE and friends (by  
cutting and pasting the bits it actually uses - PyErr_Mac,  
PyMac_BuildOSType, etc.).


I'm not sure how much disruption these changes would cause for  
existing users, though hopefully not much:

- I doubt anyone uses the OSA stuff except me; as far as I can tell,  
most users don't venture beyond the appscript and osax APIs

- anyone who really needs to work with Carbon.File objects can always  
write their own code to convert between mactypes' Alias and File  
objects and Carbon.File equivalents

- appscript/aem users are rarely exposed to CarbonX.AE.AEDescs since  
commonly used standard types are already bridged. Where they are  
exposed, users who need to manipulate them (beyond just treating them  
as obaque types) could adapt their code as necessary (which might be  
as simple as changing any references to the CarbonX namespace to the  
aem one).



To be honest, I think the simplest solution from my POV would just be  
to copy the current rb-appscript setup, which is already 64-bit savvy  
except for the osax module [1]. Rb-appscript contains only aem,  
appscript, mactypes and osax modules plus a single AE extension that  
provides all the C bridging required by all of them. This level of  
reworking would make it a PITA if I ever wanted to reintegrate  
appscript with Python's built-in Carbon extensions - that's something  
I'd certainly like to do, but who knows if/when that could/will ever  
happen in practice [2]? Meantime,  being able to do away with all the  
accumulated and legacy gunk does have a certain appeal: compared to  
the Ruby and ObjC ports, the original version's internals are looking  
rather scruffy these days.

Any thoughts? In particular, if you or anyone else can see current or  
future problems or disadvantages to this approach, or would be  
negatively affected by them, please do let me know.

has

[1] The deprecation of OSAGetAppTerminology means that I'll have to  
write an sdef parser in order to fetch osax terminology dynamically  
under 64-bit. This'll happen eventually; in the meantime, any user who  
wants to use osaxen in 64-bit will have to create and use a static  
glue. A bit annoying for them, but it's not a high-priority module for  
me so folks'll just have to wait till I can get around to it - unless  
someone else would like to volunteer for the job?

[2] Out of interest, does BridgeSupport provide any assistance with  
bridging Carbon APIs, or does it cover Cocoa/CoreFoundation only? If  
it did cover Carbon as well, my own instinct would be for starting  
over using that rather than trying to update the existing Carbon  
extensions.

-- 
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org