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 _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
