[Pythonmac-SIG] py2app standalone options
Hi, One for Bob really, but I'm trying to figure out how to build a non-standalone app using py2app. This was easy (albeit clumsy) with bundlebuilder - just set both 'standalone' and 'semi-standalone' options to False. I see a 'semi-standalone' option in py2app, but that still includes a big wadge of stuff I don't want/need, and I don't see any obvious, simple way to tell it not to include ANY external dependencies. Have I've missed something? (The current documentation is minimal, and the main docstring in particular appears out of date.) Or is it an oversight in the API/UI design, in which case I'd suggest replacing the boolean 'semi-standalone' option with a new 'dependencies' option that takes one of three values: 'all', 'semi', or 'none'. Ta, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app standalone options
Bob wrote: [py2app] still does the dependency scan for third party python code and dependent libraries/frameworks. If you want to depend on third party stuff in site-packages, too bad, you'll have to exclude them all individually and use --site-packages. Why? Because I don't care about your use case. It's rare and is very often not what people want. How rare? has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app standalone options
Bob wrote: Because I don't care about your use case. It's rare and is very often not what people want. How rare? Rare enough that I can't justify writing the code and adding yet another option. If you don't need a redistributable application, then use an alias bundle. If you want a redistributable application, then include the dependencies. If you were writing py2app simply to please yourself I wouldn't bother raising the issue, but since you intend it to replace BundleBuilder in the standard distribution I can't really see "I don't care about your use case" being sufficient justification for such a design decision. You've just spent weeks, if not months, designing and constructing py2app - a not insignificant piece of software engineering. I'd be rather surprised if it'd take you more than a few minutes to insert an option that bypasses the modulegraph component at the point where it connects to the rest of py2app, assuming a properly-factored, maintainable design. As to what I want: I would like a really quick, easy way to churn out lightweight distributable applets that don't lug around stuff they don't need to. BundleBuilder has no problem doing this; heck, even a crap language like AppleScript can do it. Is it really py2app's place to dictate to users how they should or shouldn't build THEIR apps? Personally, if I want py2app to resolve and include my applications' dependencies, I shall be only too happy to ask it to do so. But if I don't, I'd appreciate it minding its own business respecting that choice. (And no, forcing me to manually resolve and manually exclude all my applications' dependencies for it doesn't count.) ... On a separate issue, I've noticed the semi-standalone option appears to be buggy in 0.1.6. When I set it to true, py2app correctly omits standard modules and extensions from Resources/Python, but is still including the core Python.framework. I'm running MacPython 2.3.3 under OS 10.2.8. If you want the build logs and/or finished application bundles, let me know and I'll email them over. has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app standalone options
Bob wrote: Adding this option causes more problems than it solves. Such as? Feel free to do it yourself, either by subclassing py2app (then using the cmdclass argument to setup(...)), or by writing a patch against py2app that makes this option available. Aye well, I'm not really up to digesting the larger py2app codebase right now (it's dense and uncommented, and I struggle enough with my own code which I already know and love), though maybe if you gave us a few ballpark pointers I might manage something. On a separate issue, I've noticed the semi-standalone option appears to be buggy in 0.1.6. When I set it to true, py2app correctly omits standard modules and extensions from Resources/Python, but is still including the core Python.framework. I'm running MacPython 2.3.3 under OS 10.2.8. If you want the build logs and/or finished application bundles, let me know and I'll email them over. I'm pretty sure I know why this is, I'll fix it before next release. Cool, ta. has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app standalone options
Bob wrote: [py2app] still does the dependency scan for third party python code and dependent libraries/frameworks. If you want to depend on third party stuff in site-packages, too bad, you'll have to exclude them all individually and use --site-packages. Why? has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app standalone options
Chris Barker wrote: I originally came down on Has' side of this debate, but now think Bob has made the right choices, so I thought I'd add a couple comments. First, I'm a little unclear on what exactly Has wants. Could you clarify? Freedom, basically. It's easier to assemble a workflow by mixing and matching small, single-purpose components than to strip down a great big monolithic lump to get the pieces you want/need. If you're going to protect the end user from doing stupid things, that's great, but it should be done by the next layer up. Users who work at the top layer are protected; users who want/need to route around the 'dummy mode' restrictions can go in at the layer beneath. After all, it's the user's foot, and if they want to shoot holes in it in full knowledge of what they're doing then far be it for anyone or anything else to stand in their way. For example, appscript currently takes this approach. The lower-level aem package provides a comprehensive wrapper around the AEM; appscript builds on this to provide a nice, safe, friendly-looking user interface for application scripting. Most folks'll just use appscript for all their application scripting, but geeks who need access to the full AEM, e.g. to send asynchronous events, can use aem. Prior to 0.6.0 appscript was a monolithic system, which meant you were SOOL if you wanted to do async events, for example - an issue Bob also happened to raise at the time. To give a practical example, let's say I want to write a GUI interface to py2app. My main dialog has some text fields and checkboxes for basic setup info, plus a table view listing all dependencies, allowing users to check/uncheck the items they want/don't want included. The obvious way to implement this would be to call modulegraph to generate the table content, then take the list of checked items and feed it to py2app's package-building function via an 'includeitems' argument. I really don't want or need py2app to run modulegraph a second time just because it's been welded into the basemost layer. If nothing else, a more loosely-coupled architecture takes pressure off the developer to anticipate and support every single possible use to which a user might want/need to put their system and/or its components now or in the future. Hope that makes sense, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app standalone options
Ronald Oussoren wrote: First, I'm a little unclear on what exactly Has wants. Could you clarify? Freedom, basically. I You obviously don't want it badly enough. Adding an option that will make the application not include stuff from site-packages is not much work, the patch is less that 100 lines (context-diff) and it took me less than half an hour to write it. Oh, absolutely true. But then, given the choice of puddling around in py2app's guts for days on end - remember, I'm nothing like as technically capable as folks like Bob and yourself - or getting on with my own projects, I have to give the latter priority (since who else is gonna do it for me?). For now, I can just continue futzing with/occasionally swearing at BundleBuilder; it's not ideal, but it does the job and lets me get on with more pressing work (like punting AppleScript's scrawny old butt to the kerb;). To give a practical example, let's say I want to write a GUI interface to py2app. That's an application with different requirements than py2app, Not sure how: both are intended to build applications, and allow users to configure exactly how they're built. The only thing that differs is the workflow's order. and that should be easy enough to build using the building blocks of py2app. That would be my hope. Of course, one shouldn't have to disassemble py2app with a hammer in order to get at the bits you need; that's my concern. Look at all this another way: in an ideal world, developers and their applications wouldn't need to deal with any of this dependency crap _at all_. Each app would merely list its requirements and the system would magically conjour up suitable components upon request. That every single app has to lug around its own set of potentially obsolete/buggy/system-incompatible dependencies is no doubt partly due to this not being an ideal world, so compromises must sometimes be made. But then, it might also be partly due to a "well that's the way things have always been done" philosophy that's come from the traditional static-inflexible-early-bound-language-plus-compile-time-linking side of computer evolution; constraints Python isn't bound by. Dunno about you, but personally I'd want to hedge my bets before tying users down to any particular strategy. Here's another whacky idea: why not get rid of the one-way source-code->build->finished-application workflow, and treat [certain types of] applications as simply another editable format? This is what AppleScript does, for example: write a script and save it as an applet, run it, drop the applet onto Script Editor, edit it some more, run it, etc. If it errors, a dialog pops up with an error description and an 'Edit Script' button that, when clicked, opens the script in SE for you with the faulty line already highlighted. Emulate Smalltalk a bit more, C a bit less. The more open, flexible and neutral tools like py2app are, the easier this kind of lunacy is to indulge. After all an idea is only stupid until you've tried it and find you really quite like it. :) BTW. the GUI I'd like to see is a GUI that allows me to grafically construct setup.py files. I think the biggest problem with setup.py files is that they're unnecessarily complicated. The best way to simplify the setup process would be to simplify setup.py itself: push all the descriptive stuff - name, version, author, description, etc, etc. - into its own plaintext file so the only thing setup.py then has to deal with is any custom build code. Make the system simple enough that it doesn't require a wizard in the first place; a drag-n-drop GUI shell is then merely a pleasant (and newbie-friendly) convenience, rather than an awkward band-aid for deeper inadequacies. OK, enough blathering the now... back to getting the next version of appscript fit to ship - don't still want to be doing it in 2006. ;) Later, has (May not know much about programming, but I know what I like.;) -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] [ann] appscript 0.9.0
Hi all, New versions of appscript, aem, osax and osaterminology released: http://freespace.virgin.net/hamish.sanderson/appscript.html Questions, suggestions, brickbats, etc. to the usual address. has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app standalone options
Bob Ippolito wrote: Not sure how: both are intended to build applications, and allow users to configure exactly how they're built. The only thing that differs is the workflow's order. One of py2app's goals is to integrate seamlessly with distutils and to behave similarly to py2exe when it makes sense. That goal is counter to making it suitable for inclusion into a GUI workflow, unless that GUI's job is simply to piece together a setup.py script (which is completely orthogonal to what py2app does). Distutils isn't very good at pausing in the middle of a command, and py2app executes as a single distutils command, therefore what you specifically mentioned is not reasonable. Hmmm. I see your point. Perhaps somebody should tell the Disutils developers that MVC isn't just for Christmas? (Oh wait... I remember already sounding out the DU SIG - doing the canary-in-the-coalmine bit, as it were - but they seemed distinctly disinterested in rethinking its approach. Just grown too comfortable with their monolithic tower, I think.) The goal for 0.2.0, which I think has already been achieved (sans documentation), was to make it better than the alternatives for any platform. When do you think we'll start seeing some formal documentation for py2app? Look at all this another way: in an ideal world, developers and their applications wouldn't need to deal with any of this dependency crap _at all_. Each app would merely list its requirements and the system would magically conjour up suitable components upon request. In order for that to happen, either every user will have to have every version of every library already installed, or they would have to have the newest version of every library already installed (assuming that libraries would never be able to break backwards compatibility). Hardly. All you need is a CPAN-style central repository and a runtime extension that knows how to look it up and download components on-demand. You can already have that if you want it, but none of them are perfect and none of them are suitable for the common user on Mac OS X. Which is not to say that such a system could not be made suitable for the common user. All it needs is a will, and a really solid grasp of HCI (something OSS often isn't as strong on, but that's not insoluble either). Why should an application developer even have to bother listing its "requirements"? Developer shouldn't. That's what tools like modulegraph are for. BTW. the GUI I'd like to see is a GUI that allows me to grafically construct setup.py files. I think the biggest problem with setup.py files is that they're unnecessarily complicated. Honestly I can't see how you can really complain about setup.py being "complicated": I assume Ronald was referring to setup.py in general, rather than to py2app's setup scripts (which don't lug around the gobs of static data that module/extension setup scripts do). ... Anyway, I think it's probably time this thread was cut loose; with MacPython 2.4 looming I think folk've got more useful stuff to be talking about right now. Will leave the last word to anyone that wants it. :) Regards, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] The versioning question...
Chris Barker wrote: That doesn't fix the multiple versions problem. This is a big issue that the core Pythonistas don't seem to be interested in addressing. It's odd, because I think it's a no-brainer that python modules need to be versioned, and there needs to be a way to have multiple versions co-existing and user (that is code) selectable. Agree completely. I think the reason folk are reluctant to address it isn't that it's an inherently hard problem, but that to solve it now requires either 1. hard political decisions to achieve an easy technical solution (i.e. a solution that's not backwards-compatible with previous versions of Python and would require big changes to the way that module-related tools and community operate), or 2. difficult and costly technical solutions to obtain a politically expedient answer. Alas, that's weird and wobbly and completely paradoxical world of software for you. Most wonderfully pliable medium in the universe, yet constricted and bound by the inexorable weight of its own history. I suspect the only way to remain free is to be completely unsuccessful - at least without users there's nobody to upset but yourself. Oh well, maybe in Python 3000... ;) Cheers, has p.s. FWIW, I do remember proposing a versioning system in another such conversation - can't recall where, but could probably dig it up if you were really interested. I think it was quite a promising concept worth further investigation: simple and very flexible to use (most schemes are either simple and completely rigid, or supposedly flexible and undesireably complex and over-engineered) - sufficient to cover the majority of user needs out of the box, with the raw underlying APIs still available to anyone who might occasionally need to arrange something special. -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] [ann] appscript 0.10.0
Hi all, Quick update to appscript package posted that fixes a couple dumb bugs and further enhances built-in help: http://freespace.virgin.net/hamish.sanderson/appscript.html BTW, I'd like to start aiming for the 1.0 release, so if anyone has some time on their hands and would like to look over the todo list, source code and documentation and let me know what they think works/doesn't work/still needs to be done then it'd be much appreciated. (I've been staring at this crap so long I'm probably snow-blind by now.) If someone who's familiar with using Apple events at lower levels could review the aem package that'd also be a big help: there's still a little bit of coding work to do there, some decisions to make about how much more to develop aem.receive, and the API could do with a quick once-over to see if it could be improved any further. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] self-instantiating instances in pyhton
Rayme Jernigan wrote: I'm looking for a language to abuse for a project I'm working on. I know a little Python, but I do not know if it can do this: I'd like to define some class "N" that instantiates objects that can instantiate fresh new objects of that same class... without external controller code. This the sort of thing you mean? class _Base: def __call__(self, *args, **kargs): return self.__class__(*args, **kargs) class Foo(_Base): pass class Bar(_Base): pass f = Foo() b = Bar() print f, f() print b, b() HTH has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Re: Appscript Binary Installer Feedback
Nick wrote: These apps are faceless background apps that help speed appscript but are not required for it to run properly. AppscriptTerminologyServer is a scriptable FBA that enhances appscript's performance and remote scripting support. RenderTerminology is a convenient drag-n-drop end-user app for rendering application terminologies to HTML files. Both need to be launched by the user, though ASTS can optionally be added to Login Items to launch automatically at startup. Hope that clarifies, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Re: Appscript Binary Installer Feedback
Bob wrote: [AppscriptTerminologyServer & RenderTerminology] So then they shouldn't be in site-packages, because they should be accessible to the user. Either /Developer/Somewhere or /Applications/Somewhere. I use /Developer/Applications/Python Tools/packagename/ when I build packages (similar to Java Tools, but using a package namespace). /Applications/Somewhere might seem a bit more friendly and familiar to novices and newcomers. What would be the advantages of /Developer/Somewhere? Sticking them in with other MacPython-related apps in /Applications/MacPython-2.x may be option option, though may be better from a marketing PoV to use a more high-profile, visible location like /Applications/Appscript (could maybe stick the appscript docs in there too). HTH has p.s. Incidentally, if we could think of some way to make the appscript documentation show up in Help Center like MacPython's does, that'd be an additional plus. -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Folder Actions in Python?
Wolfgang Keller wrote: Is there a way to write "folder actions" for MacOS X in Python? Ideally, you'd use PythonOSA <http://homepage.mac.com/philip_aker/osa/osa.html>, but it doesn't yet support handling of arbitrary Apple events. For now, your options are: 1. Use an AppleScript to run your Python scripts via 'do shell script' when it receives Folder Action events. 2. Use an AppleScript to forward Folder Action events to a faceless background application (FBA). Scriptable FBAs are easy enough to write in Python using aem.receive (see <http://freespace.virgin.net/hamish.sanderson/appscript.html>). BTW, the second option could be extended to create a general-purpose system for forwarding Folder Actions to user-installed shell scripts of any kind. If anyone is interested in writing such a thing, email me and I'll be happy to discuss further. has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Anyone script ChemDraw w/ Python?
fbartlet wrote: I have a mess of VBA and AppleScript scripts I wrote to automate Word & ChemDraw tasks. Now that everyone who needs this stuff has access to OS X, I thought I might try Python to make some improvements I've been asked for and which VBA and AppleScript don't seem to be able to deliver. Depends on the reason _why_ they can't deliver. If the limitation is in the application APIs, there's not much you can do about that except file a feature request with the application developer. But if it's just the language that's being lame and obnoxious then you can probably do something about that by switching to Python. Here's a link to Python's new application scripting support package (c/o yours truly): http://freespace.virgin.net/hamish.sanderson/appscript.html While I've used Python to script Word under Windows, I'm not terribly knowledgeable about Macs; so any and all clues will be received gratefully. Word 2004 has a much expanded Apple event interface compared to previous versions. I think it's basically just a thin wrapper around the API used by VBA, so not very Mac-like but pretty comprehensive. The MacScrpt mailing list <http://listserv.dartmouth.edu/scripts/wa.exe?A0=macscrpt&D=1&H=0&O=D&T=1> has various crusty old application scripters who can advise on application-specific issues. Paul Berkowitz might be a particularly good person to answer Word scripting questions as he does a lot of scripting of Office apps (he sometimes posts on this list as well, so say his name three times and maybe he'll appear;). I've yet to write up a proper introduction to Mac application scripting and appscript, but if you dig around the PythonMac SIG archives there's been a few threads discussing application scripting theory and principles. And if you're familiar with AppleScript then you shouldn't have any problems with appscript - the syntactic sugar is slightly different, but it behaves just about the same - see the appscript documentation for caveats and instructions. HTH has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Re: Namespace conflict with WebWare and PyObjC / Import safety (Was: how do I use twisted cfreactor?)
Kevin Dangoor wrote: What I like about Cheetah is that it's concise (unlike TAL), is pleasant to work with (subjective to be sure, but I don't like ClearSilver's syntax), is reasonably performant, and strikes a nice balance between functionality and separation of concerns. Utterly shameless self-plug here, but HTMLTemplate <http://freespace.virgin.net/hamish.sanderson/htmltemplate.html> is a mature, powerful and flexible DOM-like HTML templating system that's also refreshingly simple and unintrusive in both implementation and use. I've also just posted an update to its plain text-oriented sibling, texttemplate <http://freespace.virgin.net/hamish.sanderson/texttemplate.html> (the documentation isn't quite done yet, but the module itself should be quite usable). Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] portability problem with py2app-built app
Hi, Having a problem with a semi-standalone app built using py2app 0.1.7. Building it OMM (OS10.2.8, MacPython 2.3.3) and the app works fine here, but on the user's machine (OS10.3, standard Apple-installed MacPython) it shows a dialog saying that it requires Python 2.3. What's wrong? Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Python+Automator?
Hey all, Just reading up on Automator development <http://developer.apple.com/macosx/tiger/automator.html> and wondering if the MacPython community (or anyone in it) has any plans to 0wnz0r it yet? Like providing a 'Python Automator Action' template for Xcode, flogging a nice introductory 'Developing Automator Actions with Python' article to online tech sites like O'Reilly, making themselves a presence on Automator mailing lists and forums when they arrive, etc. With Tiger arriving soon, seems like a grand opportunity for someone with a pre-release build and a hankering for MacPython evangelism to get in at the head of the rush and mop the floor with the competition. :) Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Python+Automator?
Bob wrote: Given the description, it would be trivial to write an Automator Action in PyObjC 1.2+ using the py2app plug-in bundle support. Cool. How hard would it be to provide casual users a more Pythonic, easy-to-use API over part or all of that, you think? Or would it be more sensible to wait for Python's OSA support to get to the level where it could use the Studio API? An Xcode template would be nice as well; even if only for marketing's sake. Would that be a big job? I doubt I'll be using Automator often enough to become a PyObjC Automator evangelist though. I'm sure if someone provides a nice, easy-to-use infrastructure then other folks will be able to evangelise it. (Python as the de-facto OS X Scripting Language... Mmmm) has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] portability problem with py2app-built app
Bob wrote: Having a problem with a semi-standalone app built using py2app 0.1.7. Building it OMM (OS10.2.8, MacPython 2.3.3) and the app works fine here, but on the user's machine (OS10.3, standard Apple-installed MacPython) it shows a dialog saying that it requires Python 2.3. What's wrong? Nothing. The semi-standalone option depends on an equivalent Python installation and it didn't find one. An equivalent Python installation means that there is either one in the bundle, or on the filesystem in an identical location. Ahh, right. This wasn't obvious. When using --semi-standalone, your Python extensions can't have their Mach-O headers rewritten. If they are linked on a version of Python or platform that doesn't use -undefined dynamic_lookup, You mean installations like (e.g.) Apple's MacPython on 10.3? Sorry my C/ObjC is extremely limited - probably best if it's explained in dummy talk. Is there a definitive document I can go read that describes the scope, scale and implications of this problem? You can override the contents of PyRuntimeLocations with the plist option, but the recommended solution to building a Python application that runs on multiple versions of OS X is to use a standalone bundle built on[1] the earliest supported version of Mac OS X. Only problem with that is it bumps each app's size by about 7MB, which is a bit of a hog for any user on dialup... especially if I'm shifting serveral 'small' apps at a time. In the future, py2app may audit your application to determine if it is safe to use "any" version of Python (no extensions, or extensions with only -undefined dynamic_lookup).. however, that still won't support your use case. My immediate problem is making ASTS portable, but I've got other apps in development that are going to have the same problem. And I can't afford a copy of 10.3 to do a parallel build on, so building cross-platform on 10.2 is currently my only option. What if I exclude appscript from the app (it can be provided as a separate one-off installation via a third-party binary installer) and munge its Info.plist to pick up Apple's MacPython? In theory, it could use macholib to rewrite the headers at runtime into a temp dir if it determines that this is necessary, but I'm not going to implement that. Would this solve the problem (and at what cost)? Any other options open to me? I can solve the ASTS problem by having a 10.3 build included in the 10.3 binary installer, but it does put a bit of a damper on me other ambitions until I can raise the cost of an upgrade or two. Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Python+Automator?
Bob wrote: Given the description, it would be trivial to write an Automator Action in PyObjC 1.2+ using the py2app plug-in bundle support. Cool. How hard would it be to provide casual users a more Pythonic, easy-to-use API over part or all of that, you think? The Objective-C API is going to be faster and richer anyway, I don't see a reason to care about the OSA interface for Automator in this context. PyObjC is a great piece of kit and definitely the way for professional developers to go, but not every Python user is a technical whizz and I can see the PyObjC route being somewhat overwhelming for newbies and casual scripters. Not every user wants, needs or can immediately handle a professional Word/Photoshop/Cumulus/Quark publishing workflow, for example. Some will be much better catered for by something like Pages, which offers less functionality and control but presents it in a way that makes it much easier for non-professionals to use. Less is More, in other words. Same sort of idea here: after all, Automator itself is just a GUI version of Unix pipes and commands, repackaged to suit a different audience. Apple's obviously planning to market AppleScript as the amateur's route into the underpinnings, and ObjC for the professionals. Python easily nails the latter group thanks to PyObjC; what I'm wondering here is how well it's going to cater to the former? Sure as guns, there's going to lots of be Automator users who sooner or later need a custom action, and often that'll mean they'll be going under the hood themselves. A simple, cut-down, newbie-friendly API might make all the difference in bringing these folks to Python, giving them an easy way to get their foot in the door. The alternative is losing that potential audience to AppleScript - a far inferior platform in technical terms, but one which knows a thing or two about presenting itself in a newbie-friendly form. It's a question of marketing really: what type(s) of audience do you wish to promote Python to, and what needs to be done to guarantee each's capture? Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Python+Automator?
Bob wrote: What's the advantage of PyObjC here? Just because it makes it easier to write the plugin, or does it help with writing the Python code too? The advantage of PyObjC here is that there are two interfaces for creating plugins: Objective-C plugins that implement a certain method, and applescripts that implement a certain handler. Since the latter isn't really possible to do with Python, Not yet, but Philip Aker is planning Apple event handling for PythonOSA. Whether Apple will make it easy or not to use OSA languages other than AS is another question, but at least the potential for writing Python Actions to Automator's OSA API will be there at some point. that leaves PyObjC as the ONLY option, and it happens to be trivial to do. Even for dummies like me, you think? Except that you can only write Objective-C Automator actions for Cocoa apps which expose their entire APIs publicly. You're totally wrong here. Automator actions *entirely separate* from applications! Paul might've meant you can't write ObjC-based Actions to control apps that provide Apple event interfaces, only apps that expose ObjC APIs. I dunno, what is the state of play re. using Cocoa/ObjC to send AEs to other applications? has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Python+Automator?
Bob wrote:
It's a question of marketing really: what type(s) of audience do
you wish to promote Python to, and what needs to be done to
guarantee each's capture?
From the public documentation, you would trivially construct an
Action in PyObjC with the following boilerplate:
# MyAction.py
from Foundation import *
class MyAction(NSObject):
def runWithInput_fromAction_error_(self, theInput, anAction):
if somethingBadHappens:
result = None
error = someNSError
else:
result = [some output]
error = None
return result, error
Is that so overwhelming?
For you, not in the slightest. For me, well I've been doing this
Python thing a year now so think I can probably cope. So that's the
professional and hack markets covered.
Now, what about the newbies, the new blood? The folks who are
complete newcomers to Python and/or to programming in general? Try to
see it from their point of view:
"What's 'Foundation'? What's a 'class'? Why do I return both a result
_and_ an error? How do I hook up my super l33t GUI that I built
myself by drag-and-drop? That language looks a bit geeky to me.
Ho-hum,
on run {input, parameters, ignoresInput}
set output to {}
-- process input items into output items
return output
end run
looks much simpler; think I'll use that instead."
And there went your sale. Ouch.
i.e. It's not that this particular group _couldn't_ use it if they
wanted/had to: vast armies of completely self-taught amateur
JavaScripters, ActionScripters and PHPers all achieving remarkable
results from a total standing start should prove ordinary folk's
fantastic ability to adapt and learn when they really need to. But as
a general rule, most folk are busy, lazy, disinterested, and/or have
much more important things to do with their time than waste it
learning some complex new framework and language. So the chances are
they don't. They just want to solve their problem in the least amount
of time and work so they can get on with the much more important
stuff they were doing before, so it won't much matter if Python is
the technically superior option because from where they're standing
if it looks like they can solve their problem quicker and easier by
going to the competition, then that's what they'll do.
Yes, they're a hacktacular bunch and the code that they'll write will
make a mature professional man like yourself howl tears of absolute
despair at the merest glimpse of it. But just do the math before you
write them off, because there's an awful lot more non-programmers out
there using Macs than there are programmers. It's the folks like you
and me too who are the exception - they're the rule. So if you can
bring even a percentage of them into the Python fold then you've just
up its marketshare, and getting bums on seats - as any marketing man
or Alan Kay will tell you - is the bit that counts most. Build your
userbase now, and you can always worry about setting them on the One
Path to True Enlightenment later. So again, the question is: do we
want 'em; and if we do, how do we ensure Python will be more
attractive to them than the competition?
Hey, if nothing else p'rhaps some of them newcomers'll be Babes...
Rotten job, I know; but gotta do it for the babes, man. ;)
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Python+Automator?
Bob wrote: Now, what about the newbies, the new blood? The folks who are complete newcomers to Python and/or to programming in general? Personally, I'd rather not be bothered catering to that class of users. Well, I know _you're_ not - that's why the Universe inflicted me upon you, as a form of karmic balance. ;) Still, it's a general question, open to all, and I'm curious to see what perspectives other folks can bring. I'm more inclined to expand what is possible in the first place (in my spare time anyway)... with occasional bouts of cleaning things up and hand-holding (writing documentation, speaking at PyCon, doing a tutorial now and then, answering the mailing lists, setting up websites, releasing software, etc.). All of which is hugely appreciated, of course. While I might not doff my cap at every encounter, I'd be the first to acknowledge that you're one of major backbones to MacPython; and without folk like you and Jack and Ronald to support it, it probably wouldn't exist. All the same, I would suggest one small caveat: when developing material intended specifically for the standard library, one should deal with the users one gets, rather than the users one might ideally like. One of Python's great features many other languages, for example, is that it doesn't by design exclude those who _don't_ know what they're doing; and IMO anyone contributing to the language or standard library should feel a certain, shall we say, 'moral obligation' to respect and uphold that position, even if it's not something they have an ideological interest in themselves. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Python+Automator?
Paul Berkowitz wrote: >> Now, what about the folks who are complete >> newcomers to Python and/or to programming in general? Actually, writing Automator actions is probably always going to be too difficult for that class of "users" (scripters). Even the AppleScript variety is rather complex for such users - lots of different apps and techniques. Forget about application scripting here: it's totally tangental to the main topic, which is can/should MacPython provide a newbie-friendly system for writing Actions using Python? There's a huge range of tasks Automator Actions could be written to perform that have absolutely nothing to do with application scripting, and for just about any of those Python is far better than AppleScript. Python's hardly the ideal end-user language either, regardless of what its more enthusiastic envangelists might like to claim, but in many respects it's 'good enough'. Like I say, if complete n00bs can pick up enough ActionScript or JavaScript to be a danger to the web, they can grok enough Python to knock some holes in their desktops if they want to too. It's probably on a par with AppleScript Studio [...] And most applescripters won't even go near Studio because it's "too difficult". Y'know what this says to me? "Opportunity." Indeed, Studio IS "too difficult" for many novice scripters: that's because it's a quick-n-dirty low-budget lash-up between Cocoa, Xcode and AppleScript, and miles away from a proper end-user oriented environment such as Hypercard. Yet people use it anyway because while it's fairly sucky at ease-of-use, it's still less sucky than anything else available at the same price point (free). Meanwhile, Studio alternatives such as Revolution and RB prove that significanlty lower suckiness _is_ achievable: RunRev & RB users ain't paying that premium price for nothing. So all you gotta do to beat Studio is provide something that's a decent bit less sucky than it is (which may or may not be easy, but it's certainly not impossible) while still holding the same price point (something OSS is reknowned for). Whether or not it's an opportunity worth taking - e.g. could the rewards justify the investment? - is another question. But on the technical side at least it seems likely that Apple's left a noticeable window of opportunity for anyone brave and/or foolish to try claiming it. The idea here is to develop Automator actions so that _end users_ can automate with complete ease and simplicity, not to make the writing of actions simple. False dichotomy. While I absolutely agree with the first, I see absolutely no reason why writing actions should not also be made as simple as possible. Otherwise you might as well argue that there's no point in creating languages like Python because you can already program anything in C. I would agree with Bob that you'd do better to concentrate on doing things right. The applescript code is simpler than ObjC for anyone who's done AppleScript, but not for those who haven't. Well, Action entry and exit points are pretty easy to nail: the AppleScript Action API already does that. Obviously, any folks with Tiger seeds can't discuss NDA'd details with those who don't, so for now a public analysis of the existing UI interaction model and brainstorming of possible better alternatives isn't yet an option. So this thread's really just to get the creative juices woken up; prehaps someone with a seed copy'll decide to pursue it a bit further in private just now, or we can take it to the next stage on-list as Apple releases more technical info into public. Just never say never. (Hey, was a time when you and me didn't know squat about AppleScript 'n Python 'n programming and stuff either - and just look where we are now! End-user's just another potential developer in-waiting, s'all...;) Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] iTunes scripting/Python shilling opportunity?
Hey, Saw this via Boing Boing: http://carlo.typepad.com/clo/2005/01/the_milliondoll.html Got me wondering if there might be potential for cooking up, say, a Python-based web UI for iTunes that could operate across a LAN? With appscript maturing and more webapp frameworks than you can shake a stick at, it might make a nice opportunity for (Mac)Python to promote itself if somebody with a bit of spare time and some prior webapp experience were interested. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] iTunes scripting/Python shilling opportunity?
Bob wrote: It doesn't sound like that's what he wants. Yeah I know, I was thinking laterally; throwing random ideas into the ring 'n that. iTunes... Mac Mini... media centers... cross-platform... LANs... etc... seems a very wide field; perhaps there's opportunities there for MacPython to do interesting things. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] [ann] appscript 0.11.0
Hi all, Updates to appscript, aem and osaterminology posted: http://freespace.virgin.net/hamish.sanderson/appscript.html Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] iTunes scripting/Python shilling opportunity?
Jack wrote: iTunes... Mac Mini... media centers... cross-platform... LANs... etc... seems a very wide field; perhaps there's opportunities there for MacPython to do interesting things. Definitely, [...] But, of course, I don't have the time:-( But it would really make me happy if people looking for pet projects could have a look at this... Same here... too many other pots already on the stove, plus I don't have all the skills needed anyway.:/ (Tho' I'd be happy to provide any help or advice needed on the iTunes scripting part, of course.:) S'why I threw the idea into the wild here. And even if nobody here picks it up themselves, I'm sure some folks subscribe to other OS X dev lists as well, and might like to promote Python/PyObjC/appscript as a solution if/when the topic arises there. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] How do you find the app that matches a creator type
Read Roberts wrote: Now that mcfs.py is deprecated, what is an alternative for the now unsupported FindApplication? from LaunchServices import LSFindApplicationForInfo from Carbon.CoreFoundation import kCFURLPOSIXPathStyle creator = 'ttxt' path = LSFindApplicationForInfo(creator, None, None)[1] \ .CFURLCopyFileSystemPath(kCFURLPOSIXPathStyle).toPython() print path LaunchServices is due for inclusion in MacPython 2.4. Meantime, you can find it on SourceForge CVS or just use the pre-packaged copy from my site: http://freespace.virgin.net/hamish.sanderson/appscript.html HTH has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] How do you find the app that matches a creator type
Read Roberts wrote: Using the package pointed to by Bob Ippolito, I find I cannot use the import statement suggested by has hengist, although it may work with the package that he points to. My version exported everything from package's main namespace, allowing one to write: import LaunchServices # imports LaunchServices' functions and constants but it looks like the official LaunchServices package requires one to import its sub-modules directly: import LaunchServices.Launch # imports LaunchServices' functions import LaunchServices.LaunchServices # imports LaunchServices' constants Not sure what the logic behind this is: it's less convenient for the user, but OTOH there may be a good reason for it. Maybe Jack or Bob can enlighten? has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] How do you find the app that matches a creator type
Bob wrote: it looks like the official LaunchServices package requires one to import its sub-modules directly: [...] Not sure what the logic behind this is: [...] Maybe Jack or Bob can enlighten? It's how gensuitemodule does things... Not that one could ever describe gensuitemodule as an arbiter of good taste... :p Well, for better or worse, I'll assume now it's Just The Way Things Are. Off to do a bunch of quick updates on all my own stuff... has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] How do you find the app that matches a creator type
Bob wrote: You should probably use my packages or source for bringing Python 2.4 features (OSA, LaunchServices) into Python 2.3. Will do. Must've missed the original announcement - didn't know of 'em till today. One thing: the binary installer only works for 10.3. I'd be happy to build a 10.2 version though if you can tell me how (given I'm not familiar with the CVS or making installers). has p.s. I've submitted patches for Carbon.AE [1090958] and OSATerminology [1113328]; don't suppose you know if/when they'll make it into 2.4, and from there into your 2.3 retro-package? -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] How do you find the app that matches a creator type
Bob wrote:
I'd be happy to build a 10.2 version though if you can tell me how
(given I'm not familiar with the CVS or making installers).
After checking out the repository with subversion (or just doing a
recursive web get, I guess), and having recent version of py2app
installed (I suggest also using svn, as it builds python source a
bit nicer):
% python setup.py bdist_mpkg
OK, I'll try and have a bash at it sometime this week. (Wish me luck.;)
p.s. I've submitted patches for Carbon.AE [1090958] and
OSATerminology [1113328]; don't suppose you know if/when they'll
make it into 2.4, and from there into your 2.3 retro-package?
Unfortunately these patches need to be rewritten such that they
change the gensuitemodule scripts
I think you mean bgen, yes?:) Don't suppose the patches could simply
be applied to the existing C code now, and formal rewrites deferred
until if/when the bgen scripts require other modifications? Or does
it generate different C code for different Python
versions/installations?
and Jack is really the only one good at doing that :)
And the proverbial bus, while not actively running over poor Jack,
does seem to be parked fairly firmly upon his foot at the moment.
Curse these inconvenient "real lives" that some people seem to have.
However, I do have to draw the line at learning bgen myself, as we'd
be onto OS XVI by the time I've mastered it. :p
has ("It rewrites the patches or it gets the hose again." ;p)
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] algorithm wanted
Henning Hraban Ramm wrote:
I'm looking for a better algorithm...
This is probably as terse as it gets:
def bool2cm0k(lst):
"""Converts a list of booleans to a CMYK color string,
e.g. [True, False, False, True] to 'C00K'
"""
return ''.join([b and c or '0' for b, c in zip(lst, 'CMYK')])
def cm0k2bool(s):
"""Converts a CMYK color string to a list of booleans,
e.g. 'CM0K' to [True, True, False, True]
"""
return [c1 == c2 for c1, c2 in zip(s, 'CMYK')]
print bool2cm0k([True, False, False, True]) # --> C00K
print cm0k2bool('CM0K') # --> [True, True, False, True]
HTH
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] 'Hello World' the OSA Way
Hey,
Well, it works (with thanks to Jack and Bob for getting me this far;):
#!/usr/local/bin/python
from Carbon.Cm import OpenDefaultComponent
from OSA.OSA import OSAComponentInstance
from aem.types import Codecs
c=Codecs()
ascpt = '''
set s to "hello" & space & "world"
say s using "Zarvox"
return s
'''
ascr = OpenDefaultComponent('osa ', 'ascr')
osac = OSAComponentInstance(ascr)
print `c.unpack(osac.OSADoScript(c.pack(ascpt), 0L, 'TEXT', 0))`
# -> '"hello world"'
Sweet. A couple immediate questions for Jack and anyone else who knows:
- Do I need to close components manually after use, or is that all
done automatically?
- There's a bunch of OSA functions not currently implemented by
OSA.so - what's the deal with those? There's a few I've not grokked
yet, but I can see several that will be needed to build a
comprehensively featured alternative to Cocoa's wimpy NSAppleScript.
- Has anyone tested or used the OSA package, written any example
scripts, etc. yet? Or am I the first?
Ta,
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] pythonw
Bob Ippolito wrote: > Are there any plans to remove this apparently unnecessary > dichotomy? It is not possible to solve this problem without changing the way Python gets installed (making /usr/bin/python a fork-exec stub or shell script) Any reason for not doing that then? Eliminating this wart would be good. BTW, there's already a couple patches filed on this: http://sourceforge.net/tracker/index.php?func=detail&aid=1056561&group_id=5470&atid=305470 http://sourceforge.net/tracker/index.php?func=detail&aid=1038911&group_id=5470&atid=305470 Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] pythonw
Bob Ippolito wrote: It is not possible to solve this problem without changing the way Python gets installed (making /usr/bin/python a fork-exec stub or shell script) Any reason for not doing that then? Eliminating this wart would be good. It would break bundlebuilder's --standalone option, probably other things. How so? The change should only add functionality to /usr/bin/python so that /usr/bin/pythonw is no longer required, allowing the latter to be deprecated and eventually removed. If changing /usr/bin/python itself affects BB, patch BB to reflect the change. (Or just deprecate BB too and tell folk not to use it to build new apps any more. This should be of relatively little inconvenience to users.) BTW, what about the sourceforge patches? Would one or both of those solve the problem any better? Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] pythonw
Bob Ippolito wrote: It makes /usr/bin/python depend on another executable at a specific location on the filesystem, Would it be possible to keep /usr/bin/python as a full-fledged interpreter while adding to it the ability to automatically start a second interpreter at a known location when needed? That should avoid breaking anything that's dependent on there being an interpreter at /usr/bin/python. Or maybe stick the path info in a hidden config file that the interpreter can read when it wants to know its location. I'm not clear on why we need to replace it altogether just to achieve the desired effect. bundlebuilder *needs* a local copy of a full Python interpreter, it would also need to be patched. How big a job would that be? BTW, what about the sourceforge patches? Would one or both of those solve the problem any better? No. Anyway, the best way to do it is to fix the GUI frameworks because that would solve other people's problems too (outside the Python world). Obviously. Though I think even Jack might struggle at trying to fix Apple itself. :) has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] pythonmac Wiki has been spammed.
Bob wrote: I'm not sure who maintain the pythonmac wiki, but it's been spammed. What a pain in the *&%*^! Unfortunately I do.. but I don't really have time to deal with the spam. It has a defense in that existing pages can't be edited with too many URLs, but creating new pages lets you use as many URLs as you want. I think I'd rather replace the installation with something else or a newer version of MoinMoin before I go hacking at it any more. How about merging it into the python.org wiki? Let someone else do all the hard work for a change. HTH has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: bgen and gensuitemodule (was: [Pythonmac-SIG] How do you find the app that matches a creator type)
Bob wrote: I think that some of bgen's parsing capabilities are going to fall apart when/if Universal Headers go away, because the new style headers use integer constants rather than four character codes in the cases where it is necessary to keep the source files as ASCII. This wouldn't be why OSA.so is missing about half the OSA API, would it? (I've also found 2 broken functions so far.) I'd fill in the gaps by hand and submit a full patch, only there doesn't seem much point if it then needs rewritten again to bgenify it. gensuitemodule has some pretty severe limitations, but I think that appscript is a suitable replacement... Not a backwards-compatible replacement so while gsm, aetools, etc. are certainly ripe for a sound deprecating in 2.4 I don't think they could be banished outright just yet. Although I doubt there's very many legacy scripts that use gsm, aetools, etc., so if they do break any time thereafter then I don't think there'd be too much tears shed. though I still use aeve in my product because I understand it, my requirements are simple, and it can do asynchronous events with PyObjC. I'm wide open to feature requests, criticisms, code reviews, etc. on aem. Especially aem.receive, which hasn't had much attention and is due for revision, though aem.send also needs assessed on more advanced features like asynchronous messaging, which is stuff you're a lot more familiar with than me. I would _really_ like to get its API and implementation locked down now, partly cos it's been dragging on for over a year now but also because I'd like to start flogging it to other language camps as a template to follow in bringing their own AE support up to scratch. (So far I've had a mention of interest from the Io camp and just run into a Lisper who might also be sellable on it. Plus I'd really like to approach Ruby, ObjC and Java folk as it could make some excellent killings there.) So any input at this point would be a serious help for me, and will be to everyone's benefit in the long run. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] How do you find the app that matches a creator type
Jack wrote: Yeah I mean bgen... I'm confusing the evil code generators Bob, I hope you realise that these "evil code generators" were written by Guido Himself (Our Beloved Leader, He Who Coded What No Man Coded Before, He Who Forever Enlightens Our Path, etc etc etc etc etc:-) ... He Who Just Recently Proclaimed: "We Don' Need No Steenkin' Macros!" ;p My main tasks in the MacPython world have been: a) Keep those two working with new releases of Python b) Keep those two working with whatever new stuff Steve (Our Beloved Leader, He Who Designed What No Man Designed Before, He Who Forever Enlightens Our Path, etc etc etc etc etc:-) came up with. Presumably though you're deprecating gensuitemodule and all its scruffy unwashed little friends as of MacPython 2.4? So if some tragic accident were to mysteriously befall them in 2.5 (something involving chainsaws might be nice) then perhaps you'll not be too sorry to see them go... >;) has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Mac User Python Newbies
Michael Hudson wrote: > [Many new developers] would > prefer to get started (at least) within the relative controlled environment of an IDE. However, it probably is a good deal less effort to explain to newcomers how to get going without an IDE thatn to write one. There's a paradox at work here. What newbies need from an IDE is _very different_ to what experienced users expect from one. On the one hand, newbies want something that is very quick and simple to learn - so the editor needs to be pretty narrow and minimal in its featureset. On the other, they also want it to provide some very powerful features - e.g. GUI editor, executable generator - that are non-trivial to develop so generally only appear in big, complex, bells-n-whistles environments. One option is to take an existing bells-n-whistles IDE and strip it right down to just the features that newbies will immediately need, minimizing and rearranging the remaining UI and adding/rewriting additional built-in help facilities. That'll let newbies get started without running smack into the immediate information overload that comes from being faced with an 'old-pro' oriented environment. Once they outgrow the newbie-oriented IDE they'll need to make the jump to the full-blown one which'l no doubt require some relearning, but at least by then they should be able to cope with the jump. Another would be to architect the IDE from the ground-up as completely component-oriented (e.g. a-la OpenDoc) where every feature is pluggable and replaceable, right down to the editor and interpreter windows themselves. That would allow the IDE to be distributed in its newbie-friendly form with all the 'old-pro' features left out, and once users become familiar with the basics they can start to add new components and replace existing ones so that the editor grows with them. This would be the better approach from the users' POV, though it also requires even better design and implementation to pull off. Obviously, either option requires a significant amount of work to be done by exactly the sort of old pros who have the least to gain directly from it. Which is always the problem with 'free as in beer' software, as it requires some other form of motivation, e.g. ego, evangelism, foundation grants or whatever. Especially writing an IDE that would be noticeably more correct than my current Emacs/Terminal/interactive Python setup. While that combination may well suit Python newcomers who are already experienced Emacs/Terminal users, it's a complete non-starter for anyone who isn't, because the last thing a newbie wants is to have to learn two or three different things all at the same time just to get started. For example, when I started learning Python I took a look at various IDEs, but learning one of those on top of learning Python was just going to be too much, so I ended up using a zero-feature syntax-coloured shell script editor instead. Might not do anything, but since it only took 2 minutes to learn I was able to get right on with the more important task of learning Python, so that I could actually get on with what I _really_ wanted to do, which was write cool software to do useful stuff. (BTW, I'm still using that editor despite it being really limited because I still can't be arsed sinking time and effort into one of these big, fat, complex IDEs when I can be writing code instead.) And that's the whole crux of the matter: Most people who come to Python aren't interested in learning IDEs, or Python, or anything else. The only thing they're interested in doing is creating cool software to do useful stuff, and every second they're having to sit and learn some tedious crap before they can do that is a second they're being kept from achieving that goal. Sure, there'll be some who enjoy all that "learning for learning's sake", but most are primarily task-oriented so you either directly help them reach that goal - e.g. by providing a completely intuitive drag-n-drop GUI builder so they can whip up that 2-minute UI when they need it - or you keep the hell out their way so you don't hack them off. Because if you do hack them off, or they think they can get better help by moving to another platform, then another platform is just where they're gonna go. And that's what the [Mac]Python community has to deal with if they want to attract new users better'n all their competition can. Me, I'm off to hack up a Script Editor clone now, so you can guess which particular audience I'm gonna be pitching to in the next few months. ;) HTH has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Mac User Python Newbies
Charles Hartman wrote: So an environment (in the vernacular, not the Unix sense) is what the beginner needs -- an IDE from within which everything you need to do can be done, and not dangerously much else. But if the IDE is complete enough for this beginner to work in, isn't it likely to be a reasonable place for someone to work who knows more, too? I think Joel Spolsky hits on the broader problem when talking about bloat vs features <http://www.joelonsoftware.com/articles/fog20.html>: "80% of the people use 20% of the features. Unfortunately, it's never the same 20%." Thus we end up with big, extremely complex programs like MS Word, and the first thing new users have to do is to determine all the bits that they can simply ignore so they can concentrate on learning the bits they actually do need. Uber-geeks may enjoy the feeling of absolute control that comes from having more buttons and knobs at hand than they can count, but us ordinary schmoes just drown in that crap. MS builds software that way cos they like to get their users locked into a perpetual upgrade cycle from which they can make money, but what's OSS's excuse? My preferred IDE architecture would be built on a completely component-oriented architecture. That way it can ship with the minimal components required to get started, and users can add, upgrade and remove components as and when they need them. For example, a new user needs everything visible so they can see what's available; an experience one may prefer everything driven by memorised keyboard combinations so they can devote screen estate to more important things like their code instead of floating palettes, on-screen help, etc. Furthermore, those users aren't locked into a single fixed solution for, say, building GUIs: as long as wxPython, PythonCard, etc. provide compatible components they can plug in whichever one they want. And it allows individual features to develop at their own rate, so you're not stuck with the perpetually 'almost-there-but-not-quite' situation that somebody else mentioned. Python's myriad web frameworks are in exactly the same situation, btw: they should be building smaller and simpler for greater flexibility and custom assembly, but instead seem only to build bigger and more complex with major lock-in and the result is systems that only their existing long-time users want to use because the cost of mastering one of these monsters has grown so high as to deter newcomers. Who then turn to simpler, less powerful systems, master those, and then complain about the lack of features until they too evolve into the same monolithic giants that they'd rejected in the first place. I've never understood what the obsession with building every conceivable feature into the application core, least of all when it's coming from unix folks who really should know better. The central tenet of Unix design philosophy is to build small, interchangeable, single-purpose components that can be easily assembled into whatever form the user needs. So I see this as just sensible design, and the fact that it happens to scale well to fit lots of different user requirements is an added plus. And I despair when I see all these other unix-raised OSS folk rushing in the exact opposite direction, and am at a loss to understand what they're thinking. HTH has -- "Oh, cut the bleeding heart crap, will ya? We've all got our switches, lights, and knobs to deal with, Striker. I mean, down here there are literally hundreds and thousands of blinking, beeping, and flashing lights, blinking and beeping and flashing - they're *flashing* and they're *beeping*. I can't stand it anymore! They're *blinking* and *beeping* and *flashing*! Why doesn't somebody pull the plug!" ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Mac User Python Newbies
t if you've a day to draw a life picture, then the best way to spend that time is 'wasting' the first half on throwaway sketches and only sitting down to the final version in the final few remaining hours, not spend all day hammering away at this one single drawing from 9 till 5. You mention py2app, but must realise yourself that py2app's potential for growth and improvement is itself ultimately constrained by the framework you've built it in, i.e. distutils. And, conversely, distutils' room for improvement is severely constrained by the need not to rock the boat for those that have already built upon it. The longer code is left to harden, the harder it will be to do anything to change it later, so best spend as much energy as you can as early on as possible to ensure that when it does set, it's not in a form you're going to regret years from now. (Unless you're the perverse sort that actively enjoys doing heroic total rewrites for the rest of your life...:p) IDEs are exactly the sort of problem that's crying out for exactly this sort of hard, hard tearing down and rebuilding approach because right throughout their lives there's going to be this strong requirement to add new features, specialist tools, remove obsoleted tools, replace, extend, rebuild, etc. One really good, extensible IDE application framework and we might not be in this foolish situation where there's a dozen all "nearly done" IDEs, all with a huge amount of overlapping functionality, which means duplication of effort; i.e. a waste of time and energy. Folk seem to acknowledge there's a constant underlying problem at work, so why don't they spend more time trying to put that right instead of reinventing the same old mistakes as before? It should be a wonderfully rich and tasty problem for those that fancy the exercise, and I'm sure there's folk that would; maybe not as instantly glamorous as "oh look I just made a yet-another-editor", but no passing flash in the pan either if/when they manage to pull it off. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Mac User Python Newbies
Bob Ippolito wrote: Maybe because in many cases, the users are the developers and adding those 20%s together makes for some big ugly mess. I'm not sure that qualifies as an excuse; more making their bed and lying in it. :) Well the people writing these things obviously write it such that it suits them, so perhaps they find this bed to be comfortable? People are generally lazy. They'll do less work now even if it means more work later. (Perl's definition of 'lazy', while charming, is seriously optimistic.) Personally, I hope that developers See The Light and do interface building in a separate but integrated application like Xcode and Interface Builder. Exactly. Or separate, integrateable components that plug into a common base framework. Well, separate processes is necessary.. a component based model can't work, because certain components just can't live in the same process with one another. Why not? And even where multiple processes are needed, why shouldn't we still hide the distinction from the user? (e.g. Erlang is virtually nothing _but_ processes.) Application-centric metaphors are nothing special. Hierarchical file/folder metaphors are nothing special. They're not inviolable holy of holies. > I've never understood what the obsession with building every > conceivable feature into the application core, I think this is largely caused by complexity of the alternative and the convenience of doing it in this way. Developer convenience up to a point, yes. It requires less up-front planning and major direction changes: just jump in and write some code. Yet the same could be said for procedural vs OO construction, so why are developers seeing the advantages of modular design in the small but still missing it so often in the large? I think in a lot of cases this may be somewhat incorrect. A lot of times you have a really modular framework, but it's not easy to rip apart into its constituent components and install just what you want (Twisted 1.x is an example of this). There's no excuse for coupling, say, persistence mechanisms and templating mechanisms into the framework. Argue the point again when they've at least managed to split those off. So what? Although Twisted 2.x is moving away from this model, it's to accommodate a more flexible release schedule, not to split it up for the sake of splitting it up. IOW, there are benefits to modular, componentized architecture. I'm certainly not arguing doing it simply for its own sake. In some cases, such as your own appscript/aem/etc., this kind of external componentization is more of a hassle than anything else. Bad example. Appscript/aem's heavily componentized architecture is not the problem. The problem with appscript is that 1. Python's own module management mechanism is mediocre, and 2. I haven't bothered compensating for this weakness by providing an easy 'all-in-one' installer. But there are ways. OpenDoc was built upon Apple events, for example. I've never seen it done in Python really easily. Which is not to say it can't be done. It just means than in order for it to be done, some poor sap will have to have to step up and do all the hard work themselves. Which means lots of exploration and experimentation and lots of throwing out and starting over until the answers start emerging. It's interesting that even MS are now moving away from the DCOM approach and towards an Apple event/Apple Event Object Model approach. I think Apple were definitely onto something with these: it's all about where you make the split, and finding the right point makes the difference between moving Mohammed or moving the mountain. And we all know how well Apple has been implementing Apple Events in its more recent applications. It's simply Not That Easy to do so, so it's simply not done well or not done at all. Apple can't even come up with a half decent explanation of what Apple events are. Wanna take bets on the total amount of resources they bother to invest in them internally? Is it any surprise they so often don't get supported properly? It's hardly like this is the first time Apple have come up with a great technology and consistently fumbled its deployment. Only Xerox seems able to consistently make an even bigger arse of things. I think you're much to quick in throwing up your hands; there's a big difference between a bolloxed execution and a bolloxed concept, and failure of one doesn't automatically imply failure of the other. that, and it's much easier to design something ad-hoc if you don't concern yourself with keeping things modular. Of course. I often start out that way myself; it's hard to know what kind of high-level structure you're going to need if it's your first time exploring this particular problem. Th
[Pythonmac-SIG] [ann] Appscript Installer 1.0
Hi all, Announcing the first release of the all-in-one Appscript Installer package for Mac OS X 10.3. Appscript brings AppleScript-quality application scripting support to MacPython on Mac OS X. This package installs everything you need to control "Applescriptable" applications using the Python 2.3 runtime included as standard in Mac OS X 10.3. In addition to a clean, easy-to-use, object oriented-like syntax for scripting applications, appscript also includes powerful built-in help facilities for exploring applications' terminology and object model - features normally found only in high-end commercial AppleScript editors. To download Appscript Installer, please visit the appscript webpage: http://freespace.virgin.net/hamish.sanderson/appscript.html To see some examples of use: http://freespace.virgin.net/hamish.sanderson/appscript_examples/index.html If you have any questions or comments, please don't hesitate to get in touch. We're still working to polish appscript and finish its documentation, so all feedback is greatly appreciated. Enjoy! has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] [ann] Appscript Installer 1.0
Bob wrote: Announcing the first release of the all-in-one Appscript Installer package for Mac OS X 10.3. Finally! :) You can thank Nick, not me - the installer is his work. :) has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] CFURL Pain
Hi folks,
I'm not really up on these APIs nor their Python wrappers, but I
suspect this stuff is broke:
First try:
import Carbon.CF as CF
f =
CF.CFURLCreateFromFileSystemRepresentation('file://localhost/Users/has/',
True)
print f #
print `f.CFURLGetString().toPython()` #
u'./file://localhost/Users/has' (Where did './' come from?)
print f.toPython() # MacOS.Error: (-192, 'Resource not found')
print f.CFURLGetFSRef() # crashes
print f.CFURLGetFSRef()[1].as_pathname() # MacOS.Error: (-35, 'no such volume')
Second try:
import Carbon.CF as CF
f = CF.toCF('file://localhost/Users/has/').CFURLCreateWithString(None)
print f #
print `f.CFURLGetString().toPython()` # u'file://localhost/Users/has/'
print f.toPython() # MacOS.Error: (-192, 'Resource not found')
print f.CFURLGetFSRef() # crashes
print f.CFURLGetFSRef()[1].as_pathname() # crashes
Anyone want to confirm/correct me? (OS10.2.8, MacPython 2.3.3)
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] CFURL Pain
Bob wrote: I'm not really up on these APIs nor their Python wrappers, but I suspect this stuff is broke: [...] Anyone want to confirm/correct me? (OS10.2.8, MacPython 2.3.3) I wouldn't be surprised if it's broken, Mmmm... encouraging. (Hey: if bgen is so great, why won't it generate some damn test suites to prove it?;p) use PyObjC and NSURL instead, those work. Introduces a big fat third-party dependency though, something I'm trying to avoid here. Why haven't you upgraded to 2.3.5 (not that I think it would help)? I'm sure it's on my ToDo list somewhere . has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] CFURL Pain
Bob wrote: Well I can verify that there definitely are serious problems with CFURL after screwing around with it a bit. Figures. Yuck. Must be bgen's revenge for all the nasty things we ever said about it. All the nasty things I ever said about it are because of things like this :) But it's so quick! As long as you're Jack and know how to use it. If you're not Jack, I guess you're screwed. On second thoughts, given Jack's existing To-Do list is probably the size of K2 he's probably screwed too. :p I wonder if it'd be easier just to hand-code wrappers using Pyrex, perhaps with a very basic macro system that automates only the simplest of tasks. A lower level automation that works well might ultimately be more productive than total automation that tends towards flakiness. While a single person wouldn't be able to wrap nearly as many APIs, the wrappers that did get done would probably be more reliable due to the extra attention; maybe a bit nicer to use too. Plus it'd make it easier for more folk to write these wrappers, taking some pressure off Jack. Too bad :) If you're writing Mac OS X specific code you **really** should have PyObjC anyway. Oh, I have. It's all the casual users who don't that present the problem. If PyObjC is going to be so essential to all aspects of MacPython usage then it's really time for it to join the standard library. So let's offer a package that includes appscript, PyObjC, and py2app in one installer. I do recall Jack saying something about maybe having a smaller core library and moving a lot of the non-essential stuff to an external package that could be managed independently; kind of a 'second tier'. Perhaps that would be the way to do it: more flexibility for individual package developers since they're not tied to the official Python upgrade cycle while still providing a quick and simple one-stop installation for users. Even modules that are destined for the core library would benefit from spending some time at this halfway house first while all the kinks are worked out (e.g. OSA.so). Might be worth exploring to see what sort of infrastructure it would require to run. HTH has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] CFURL Pain
Bob wrote: I wonder if it'd be easier just to hand-code wrappers Actually, the easiest way is to just use PyObjC! Maybe that's the way to go for CF stuff then: delegate the problem to PyObjC and get rid of the Carbon.CF extension completely (no sense in keeping broken modules if they're not worth fixing). This still leaves Carbon APIs to deal with, however. For example, OSA.so is currently pretty broken, and I would happily go in and fix it myself but there's little point in doing so if all my changes have to be rewritten for bgen before they'll be accepted into the standard library. Plus Jack's very busy these days, so who knows when that would happen? And then there's stuff like Carbon.File, which could do with both bug fixes (the FSSpec problem) plus a new layer on top that abstracts away all the various and frequently crusty file types under one or two standard wrapper classes (might be possible to turn most of them into NSURLs, for example). How should these sorts of problems be tackled? Additionally, since PyObjC wraps the functions with the signature they actually have, it's obvious (given Apple documentation or headers) how to use them. The way bgen wraps them attempts to objectify them, which tends to cause more problems than it solves -- at least for me. I don't mind that so much as I object to the lack of documentation to tell you what's actually there and where to find it. These undocumented APIs are a serious PITA to grok. I end up generating my own erstaz docs by scraping an extension's type/method/function names and minimal docstrings into a text file and then cutting and pasting from Apple's original API docs or header file comments until I've got something that's at least minimally readable. I do recall Jack saying something about maybe having a smaller core library and moving a lot of the non-essential stuff to an external package that could be managed independently The Windows guys seem to get along just fine with this approach (re: win32all). There are a select few Win32-specific modules in the core, but most of the things you actually need are elsewhere. So what would it take to get MacPython from its current state into that position? has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] CFURL Pain
Bob wrote: Maybe that's the way to go for CF stuff then: delegate the problem to PyObjC and get rid of the Carbon.CF extension completely (no sense in keeping broken modules if they're not worth fixing). Unfortunately getting rid of an extension is a lot harder than it sounds. Better is to just stop using it, and possibly deprecate it. Getting rid of junky crap takes time, but adding a warning and deprecating it at the nearest opportunity is a good start. I don't think anyone is really using that module anyway. All the more reason to deprecate it before they start to. :) This still leaves Carbon APIs to deal with, however. It's unlikely that anyone is going to ever bother doing a better job wrapping Carbon than is already done, because it's a hell of a lot of work and Carbon isn't really the best way to do most things anyway. True and semi-true (there's still functionality in Carbon that's not in Cocoa). However, it's not a case of wrapping all of Carbon simply as a point of principle, but rather individuals wrapping the bits they need themselves as needed and that code ultimately making it into the official distribution. Instead of fixing OSA, you can write an alternative that isn't bgen based. If I do that, will the current OSA.so be thrown out (preferably right now) and replaced with my version once it's done? *What* FSSpec problem with Carbon.File? http://sourceforge.net/tracker/index.php?func=detail&aid=706592&group_id=5470&atid=105470 Although there is generally not a very good reason to use FSSpec or FSRef, Legacy mostly, e.g. when dealing with Carbon APIs that use them. In my case, because they're still heavily used by scriptable apps and Apple's built-in coercions aren't sufficiently up to snuff to let me ignore them outright (which is damned annoying, especially when they're the ones telling us we should now be ignoring these and using their shiny new types instead). So what would it take to get MacPython from its current state into that position? Just tell people to stop using standard library stuff and use the more robust alternatives. What when there's overlap, e.g. the 'robust alternative' is a modified version of the original - say, a partially rewritten OSA.so extension? The standard library bits can't disappear, because that would break compatibility. Add warnings to these modules and deprecate them now. Strip all their documentation out of the main Python docs and leave it in a separate 'Deprecated Docs' package preserved for legacy use only. Get all the crap well away from ordinary decent users as quickly as possible. Depending on how much a deprecated item is used it could be removed completely in the following major release, moved to 'MacAll' at some point or left in the core library indefinitely. There's quite a bit of obsolete stuff in the standard library that's been broken or non-functional since OS9. With 2.4 finally throwing off OS9 commitments it seems the ideal time to get brutal with the useless baggage and strike a red marker through everything that doesn't measure up. You'll inevitably be leaving folks behind anyway, so make the most of the opportunity. Even if modules don't go completely, scrubbing the code to get rid of the cruft leaving only warnings and non-functional stubs might be a good idea. It's not worth twisting oneself into religious knots to preserve some perceived 100% backwards-compatibility over code that probably hasn't worked or been used in years. Future health, vitality and growth are much more important, and worth an occasional minor break with the ancient past. Of course, this is assuming that more robust alternatives to the standard library's exists. Even if there isn't, leaving broken stuff in the core library isn't doing any favours. If it's recoverable, why not punt it into MacAll where its failings can be addressed more easily? If it's terminal, put it on the road to disposal. I don't have a problem throwing out stuff that's definitely had it: you may see this as leaving a void, but I see it as creating a fresh new opportunity. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] CFURL Pain
Bob wrote:
Instead of fixing OSA, you can write an alternative that isn't bgen based.
If I do that, will the current OSA.so be thrown out (preferably
right now) and replaced with my version once it's done?
Unlikely, but what does it matter?
1. What's the point of adding a new extension to the standard library
when that extension is not only untested but _already known_ to be
broken?
2. What's the point of me going to the effort of writing a brand new
fully functioning OSA.so extension if it has to play perpetual third
fiddle to some
known-to-be-broken-but-inviolable-now-as-it's-in-the-standard-library-neener-neener
version?
Aside from the self-evident foolishness of loading the standard
library full of worthless crap, it's also rather insulting to folk
who spend the time and effort to write and thoroughly field-test code
before even thinking of submitting it for possible future inclusion,
only to see rubbish getting fast-tracked right past them. Come to
think of it, it's somewhat insulting to MacPython users in general:
"Sure the quality sucks ass, but just feel the quantity!" If bulk's
all you want, just pack line noise into modules and release that;
it'll work just as well and be even easier to produce.
I may not know much about programming, but I know what a bullethole
in the foot looks like. If nobody cares enough about using these new
wrappers to test and debug them thoroughly before inclusion, they
should not go in, period. Simple as that. All it does is create a
mess that then can't be cleaned up properly, because throwing out a
busted-ass module that _nobody can actually use_ will somehow - oh
noes!!1!1! - 'break compatibility'.
*What* FSSpec problem with Carbon.File?
http://sourceforge.net/tracker/index.php?func=detail&aid=706592&group_id=5470&atid=105470
Ah, right. I ran into that problem once with QuickTime, but it
turned out that there was another way.
Do tell!
Does that FSSpec bug really effect you? When do you need to pass
FSSpecs to files that do not exist across processes?
Most commonly when saving new documents to file, as in:
app('TextEdit').documents[1].save(in_=FSSpec('/Path/To/NewFile.txt')
Just tell people to stop using standard library stuff and use the
more robust alternatives.
What when there's overlap, e.g. the 'robust alternative' is a
modified version of the original - say, a partially rewritten
OSA.so extension?
I don't see what its origins have to do with anything.. You
obviously can't give it the same __name__ as something in the
standard library.
That would be my point. Python users don't want, need or deserve to
thrash through a dozen different first- and third-party
implementations of the same module to find one that works. There
should be one way to do it, and that solution should NOT be in the
standard library unless it can swear, hand on heart, that it's the
Right One. Kicking a lot of this stuff back out the standard library
would be a good start, because it's clearly not qualified to be
there. Push it into 'MacAll', and take it from there.
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] CFURL Pain
Bob wrote:
1. What's the point of adding a new extension to the standard
library when that extension is not only untested but _already
known_ to be broken?
They're automatically generated, these things happen.
Absolutely. I have no problem with mistakes being made. It's setting
them in stone that's the trouble.
2. What's the point of me going to the effort of writing a brand
new fully functioning OSA.so extension if it has to play perpetual
third fiddle to some
known-to-be-broken-but-inviolable-now-as-it's-in-the-standard-library-neener-neener
version?
Ok, there are three options:
(1) Fix the current implementation
(2) Write another, outside the standard library (unless you only
care about Python 2.5+)
(3) Live with a broken implementation
Pick one.
The only person in a position to do (1) is Jack, which is unfair on
both Jack and any third-party who might otherwise fix it themselves,
(2) is just ducking the issue and (3) is obviously a non-option.
(4) Remove the current implementation from the standard library.
In OSA.so's case this could be done completely painlessly as it's not
like anyone's actually using it. Older material may require more
delicate extraction and a proper repackaging to allow separate
installation, but it's still perfectly doable.
Does that FSSpec bug really effect you? When do you need to pass
FSSpecs to files that do not exist across processes?
Most commonly when saving new documents to file, as in:
app('TextEdit').documents[1].save(in_=FSSpec('/Path/To/NewFile.txt')
What you *actually* want is a Finder alias anyway.
Umm, no, I don't. I've been using file specs to refer to non-existent
files for years. It was the standard solution in OS9, and while
fileURL is supposed to supercede it in OS X it persists for legacy
reasons and because fileURL support still isn't quite what it should
be. And I've really no desire to start kludging up Python; I've
already endured enough kludges in AppleScript to last a lifetime and
the whole point of shifting to Python was to get away from all that
crap.
Kicking a lot of this stuff back out the standard library would be
a good start, because it's clearly not qualified to be there. Push
it into 'MacAll', and take it from there.
Well obviously that's not an option,
Why? All it means users have to do two installs instead of one to get
set up which is no huge effort, and in practice the MacPython
installer could bundle and run a recent copy of the MacAll installer
for convenience. And once all this stuff is out the standard library
it's free to be working on without the onerous scheduling
restrictions and personnel bottleneck that comes from being locked up
in the standard library. Have I missed something?
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] CFURL Pain
Bob wrote: FSSpec is legacy. It should not ever be used in any code except to reference nonexistent files or to deal with legacy APIs. You shouldn't use them if the API will take an FSRef or an Alias. Neither FSRef or Alias can be used to refer to non-existent files. FileURL does, but I'm not sure it can yet be used safely in place of FSSpecs in all cases, plus their standard Carbon.CF implementation is busted. FSSpecs suck, but I'm not sure they can be completely ignored just yet - any time I've tried to streamline aem/appscript to save the user from dealing with crap like this I've ended up having to re-expose it again in all its ugliness after something else ralphed on the 'clean and elegant' version. Rock, hard place. What's really needed is for MacPython to provide a standard high-level File class that abstracts over all this mess so module authors can have a solid and reliable API to implement against and end users don't normally need to futz directly with this stuff. No doubt an interesting and challenging problem for anyone that wanted to tackle it. In this case, the API *asks* for an Alias. So, yeah, you do actually want an Alias. No, the TextEdit dictionary says 'alias', but the dictionary is merely documentation, not the API itself, and dictionaries are regularly incorrect. It should almost certainly read 'file'. IIRC, the sdef format doesn't even list 'alias' as one of the standard primitive types, so I've no idea where TextEdit gets it from. Probably a blow on the head or something. Cocoa Scripting APIs are _also_ frequently buggy and ill-designed, and specifying files was one of its classic blunders in earlier incarnations which they've been trying to rectify ever since. So it is possible that they've buggered things up differently in 10.3 such that you do have to specify an existing file in a 'save' command; I don't have 10.3 so can't check offhand. If they have, I'm sure there's bugs filed on that as well, but I can't recall hearing anything about it. Nevertheless, 'save' commands have always traditionally accepted a file handle specifying an as-yet non-existent file for saving documents to a new file, and ignoring periodic Apple incompetence I don't believe this policy has formally changed for one moment. Apply one dose of healthy skepticism and a large dollop of plain common sense - both absolutely essential when it comes to Mac application scripting - and this should be obvious. has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: broken modules (was: Re: [Pythonmac-SIG] CFURL Pain)
Bob wrote: Absolutely. I have no problem with mistakes being made. It's setting them in stone that's the trouble. Not stone, just molasses. Near enough as makes no practical difference. It's a situation that should not occur in the first place. These molasses are entirely man-made. If you learn bgen and submit proper patches Without proper documentation and tutorials? Sorry, but masochistic self-flagellation is not my thing. This is somebody else's house of cards to sort out before everyone else can seriously be expected to play in it. Besides, what's the point in me going to the trouble of properly patching something if the fix won't percolate into the main distribution for another year when I need it now? You're confusing issues here. The problem is that you need OSA functionality. Removing something from the standard library does nothing to solve that problem. No, I'm using OSA.so as an illustrative example because I'm already familiar with it. The point is that potentially broken modules should not be going into standard library. And until they've been tested, all modules should be considered potentially broken. OSA.so is a prime example: I _know_ it hasn't been tested, because it took me five minutes to discover the first deal-killer bug. Other modules may be just as untested, but I can't speak for them as I've not tried them myself. In the case of OSA.so and any other new MacPython 2.4 additions that haven't been tested, until Jack posts a final MacPython 2.4 distribution then it ought to be safe to revoke their inclusion. Removing the extension may or may not be a good idea. If /some/ of it works, it might be worth keeping. In OSA.so's case the breakage is pretty fundamental, e.g. not being able to compile scripts from source is pretty much a deal-breaker by itself, never mind the other bugs and huge chunk of missing API. I hear no great clamour from the gallery to use this module, broken or otherwise, so just punt the bastard out. It's virtually worthless as it is, and sticking it in will only make it harder to clean up the mess later on. Other modules I can't speak for, other than to say that if nobody's tested them yet then it would be better to keep them out than until they are. If folk really care about them, they'll whip together and run some tests quickly enough. And if they don't care about them, it means those modules aren't worth including in the standard library in the first place. (Seriously, what are the justifications for putting stuff nobody needs or wants into the standard library?) Kicking a lot of this stuff back out the standard library would be a good start, because it's clearly not qualified to be there. Push it into 'MacAll', and take it from there. Well obviously that's not an option, Why? All it means users have to do two installs instead of one to get set up which is no huge effort, and in practice the MacPython installer could bundle and run a recent copy of the MacAll installer for convenience. And once all this stuff is out the standard library it's free to be working on without the onerous scheduling restrictions and personnel bottleneck that comes from being locked up in the standard library. Have I missed something? It can't happen until Python 2.6 at the earliest. I don't think it's very likely to go away anyway. Good luck! Why so long? Merely refactoring the distribution doesn't break backwards compatibility so I don't see why the reorganisation couldn't be done during 2.4's tenure? My point is that it's perfectly fine to IGNORE THE STANDARD LIBRARY. It's fine for users to avoid the standard library. But that doesn't excuse filling it up with crap and then saying we shouldn't be concerned by this behaviour because users can always go elsewhere if they don't like it. Different issue. If you can't see any problems in having two parallel libraries: one an officially sanctioned and bundled broken-ass POS and the other a giant third-party band-aid, then you really need to start looking harder. The damage it could cause MacPython's public image and credibility alone should be of significant concern. It's like letting your house get covered in three feet of rotting unwashed dishes and cat poop and then wondering why nobody wants to come round and visit any more. It does a disservice to Python's reputation, its developers and its end-users, and it's the sort of behaviour that'll eventually turn folk off Python and onto something else. My point? Doing a job badly is the _worst_ thing possible. If you can't or won't do it properly, you shouldn't to do it at all. has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: broken modules (was: Re: [Pythonmac-SIG] CFURL Pain)
s the point of wasting valuable time and effort doing a half-assed job? It could be spent much more profitably elsewhere doing something more productive: writing modules you actually care about yourself, providing better documentation for existing modules, spending time with the kids, getting pleasantly hammered down the pub, etc. And it does matter, because sooner or later folk will want to use Mac-specific features either directly or indirectly - it's one of the reasons for choosing MacPython in the first place. It's the same BS that Apple pull with AppleScript: looks ultra-tasty from the outside, but some munching later and you start to realise there's this really really bad taste in your mouth, plus a wriggling sensation you don't even want to think about. Apple are just a bunch of classy tarts only interested in my wallet, but I expect better from the honest and hardworking artisans behind MacPython. And I expect the folk at the top - the ones directly responsible for the project's current and future well-being - to be the most stringent, selective and disciplined of all. has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Re: repackaging MacPython (was: Re: broken modules)
Bob wrote: If you named it carbon, it would definitely be the cause of headaches and confusion due to the default case insensitivity of HFS+ and the similarity to the existing namespace. 'lo-carb'? :) I wasn't exactly putting any thought into it; nit-picky details really aren't important here. To summarise: My main suggestion was that the whole Carbon package plus other Mac-specific modules might be moved out of the Python.framework distribution and into a separate 'MacAll' distribution (c.f. Win32All), leaving Python.framework as basically just a plain-vanilla framework build of the standard Python distribution. That'd allow the Mac community to evolve the Mac-specific stuff at its own rate, rather than being inextricably tied to the slower (and slowing?) upgrade cycle of standard Python. IOW, loosen the couplings between standard Python and Mac-specific extensions without changing any of the content or behaviour, because Loose Coupling = Better. I know Jack's mulled over this idea of repackaging MacPython (though I dunno to what extent) and I personally believe it has serious merit, even if this thread does seem to keep losing sight of it by sidetracking into nitpicky details (hey, mea-culpa, seeing as it's my thread:p). Anyway, I've probably said my bit about as well as I can and I'm off for the next week, so I'm going to leave it there and maybe someone else can run with the thought if they want to. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: OSA.so (was: Re: [Pythonmac-SIG] CFURL Pain)
Donovan Preston wrote: > No, I wanted a Python OSA component. Different thing. The only person > I know was asking for an OSA wrapper was Donovan, and he went off to > work on Nevow yonks ago and AFAIK never did anything with it. I wanted an OSA module so that it would be possible to write a Python OSA component using a more inside out approach. There's basically two halves to OSA. One half is used to implement OSA language components. The other half allows client apps to use them. OSA.so implements the API for the second of these, allowing Python to load and execute scripts written in any OSA language. The Carbon equivalent to Cocoa's NSAppleScript, except with a much more powerful and much less friendly API. To implement a PythonOSA component, you need to write a C wrapper around the Python interpreter's C API [1]. That wrapper then exports a bunch of callbacks (UUPs to be precise) that OSA calls to compile/decompile/execute/load/store/etc a Python script on behalf of a client. I don't think there's anything in OSA.so that'd help with that. I've been looking at OSA.so recently as I'd like to implement attachability in a PyObjC-based app I'm writing and NSAppleScript is too limited for what I want to do. While I've occasionally given the PythonOSA problem a passing glance, it's not something I'm as interested in solving myself as I haven't had any personal need for it to date and my C isn't good enough anyway. I am still interested in producing a Python OSA component, hopefully with the OSA module, but unfortunately it is a lot more work than I have free time for at the moment. I lost my drive to work on it when it became clear that HAS was far more energetic in this space than I was, and HAS didn't seem willing to listen to what I had to say about the subject or collaborate with anybody. I do remember being very grateful for advice when I was starting out on appscript. Can't recall ever being anti-collaborative or that; I may be abrasive and critical and behave differently to other programmers, but then I'm from a different background so maybe there was some accidental culture clash? Apologies if any offence was caused; it certainly wasn't intentional. Cheers, has [1] It might be possible to write a smaller C wrapper that allows you to install Python functions as callbacks for handling the compile/decompile/execute/etc. stuff within Python using exec and friends rather than doing the whole lot in C, which might be a bit more convenient than doing everything in C. I don't know enough about how the Python interpreter works to say if this would be practical or not. -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] CFURL Pain
Paul Berkowitz wrote: The type 'alias' for the Save command in the Standard Suite is a long, longstanding bug in AppleScript. Replacing (as of 10.3) a previous long, longstanding implementation bug where it was specified as a POSIX path string. :p I take it 'alias' is just a documentation error then, and the application will also accept a file spec/file url type identifying an existing/not-yet-created file. Fortunately there is an equally longstanding coercion, performs by AppleScript itself, that allows you to use a string or Unicode text there Presumably there's a POSIX path string-to-file object coercion introduced in 10.3 to maintain compatibility scripts written for Cocoa apps in 10.2, where 'save...in' took a POSIX path string instead of a file object. In aem's case at least, I'd be extremely reluctant simply to replace all use of Mac file objects with POSIX path strings. I've already tried this once and it just caused problems. I really would like an elegant, easy-to-use solution that respects AE file objects and provides user-friendly Python equivalents that hide as much of the underlying clumsiness without introducing any new problems. Might be a non-trivial task, but I think it'd be worth doing, especially if Python's to become a genuine replacement for AppleScript. In OS X, the coercion is now to fileURL, I believe. Whether this coercion takes place at a deep enough level (AppleEvent?) that it will work also for appscript and MacPython, I don't know. If you try it, what happens? I've tried supplying FileURLs to Tex-Edit Plus in 10.2 and it seemed to work ok. If CFURL worked properly I'd probably just sling in the code to coerce AEDescs of typeFSSpec and typeFSRef to typeFileURL and spit out CFURLs, then wait and see if anyone runs into problems. NSURL is an alternative, though I'm still a little uncomfortable about coupling aem to PyObjC just for the sake of one little type; I'll think about this a bit more. It would definitely be nice if the whole Mac file type muddle could be reduced - at least at the end-user level - to high-level, user-friendly FileURL and Alias classes. The only questions are: can we get there safely, and if so, how? Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] PyMac_Initialize()?
Hi, Reading up on embedding the Python interpreter, and <http://www.python.org/doc/2.4/ext/embedding.html> says to use PyMac_Initialize() instead of Py_Initialize() to initialise it on Mac; however it doesn't appear to be declared. Is this a typo in the Python docs? has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] appscript and XXXX - what is my app instance returning?
'me' wrote:
I am having much fun with appscript and QuarkXpress6.x [...]
Unfortunately, when you do get lost like I am. You're completely
lost.
While appscript saves you from the vagaries of the AppleScript
language, it can't do anything about bugs and quirks in individual
applications' scripting interfaces.
Would someone please share their method for
figuring out what my app instance is returning,
and how I can coerce that into a form I can utilize?
[...]
Quark = appscript.app('QuarkXpress')
pw = Quark.documents[1].page_width #This is what I want
Remember that while appscript uses an OO-like syntax for convenience
it's not OO. It's a simple relational query builder plus RPC wrapper.
Ditto AppleScript, except it has an even thicker layer of syntactic
and semantic sugar on top. The downside of this is that it causes
quite a bit of confusion amongst users who assume that because it
looks like OO it will behave like it too.
(I've considered changing the syntax to avoid this problem, but
that'd impact badly on its ease of use. I'd rather keep the syntax
but make sure users know it's really just smoke and mirrors. Expect a
bigger health warning in the docs for the next release.)
>>> type(pw)
The line:
pw = Quark.documents[1].page_width
simply constructs a query (represented as an appscript Specifier
object) identifying the page_width property of the first document
element of the QXP application. To actually retrieve the value of
that property from the application, you have to send the application
an explicit 'get' command:
pw = Quark.documents[1].page_width.get()
>>> pw.get()
<_AE.AEDesc object at 0x1181c38>
This is a typical Quarkism: returning an opaque value that only it
understands instead of using a standard AE type. AEDesc is the
MacPython type used to hold raw Apple event data (in AS it'd appear
as <>), and is returned here as appscript doesn't have a
suitable converter for it. If you're sending this value back to QXP,
no problem. If you want to manipulate it in your script, you'll need
to ask QXP to coerce it to a standard datatype (integer, float,
string, etc.) before returning it, e.g.:
pw.get(astype=k.Char)
Not sure which coercions are supported here, so you may need to
fiddle with it a bit. Good place to ask for QXP-specific advice would
be [e.g.] the MacScrpt mailing list
<http://listserv.dartmouth.edu/scripts/wa.exe?A0=macscrpt>.
HTH
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] appscript and XXXX - what is my app instance returning?
Paul Berkowitz wrote: If appscript is meant to replace the vagaries of AppleScript with the sanity of Python, there's no getting around the fact that its whole raison d'être - healthy application scripting - can founder on poorly implemented application AppleEvent syntax, with no one around to explain it, let alone fix it. The 'syntax problem' I mention is common to both AppleScript and appscript and has _nothing_ to do with individual applications' Apple event support. The problem is that both wrap Apple events in a very OO-like syntax which is easy to use and perfectly sound in itself, but tends to mislead unwary users who assume that because it looks like OO it *is* OO. Which it's not: it's an RPC interface plus simple relational query builder. While I could change appscript's syntax to make it look less OO-like, it would also make it less easy to use. The solution is better education (starting with better documentation, obviously) so that appscript users aren't labouring under any false assumptions when they start to use it. BTW, the last place to learn this stuff is from AppleScript, which plays even more syntactic and semantic tricks and is even worse about informing its users of this. It's something we Python folks will have to provide for ourselves, and I'm sure we will. All of which is a completely separate issue to learning how to effectively script individual applications, which is the problem the OP's having. That has nothing to do with the language/bridge used, and everything to do with learning how an application's Apple Event Object Model works, what it can and can't do, where all the quirks and bugs lie, etc. Information that should be supplied by application developers, of course, but they often don't so users often have to rely on experimentation and shared knowledge to fill in the blanks. Personally I don't think the language difference should be too much of an issue when asking application-related questions, though we'll only find out for sure when appscripters start asking these questions on traditionally AppleScript-oriented lists such as MacScrpt. (As opposed to Python/appscript-related questions, which are still best asked here.) has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] appscript and XXXX - what is my app instance returning?
Paul Berkowitz wrote:
> Personally I don't think the language difference should be too much
> of an issue when asking application-related questions,
I think it might be an issue.
Didn't say there wouldn't be any issue at all; of course there'll be
a degree of mismatch any time someone posts an appscript/AppleScript
code sample. I assume there will be sufficiently enlightened folk
around who won't let the unfamiliar accent get in the way of trying
to be helpful to one another.
And some questions will go to the wrong forum: application-specific
questions to here, appscript-related questions to there. One of the
reasons I recommend MacScrpt is that there's at least one person
reading it daily who can pick up any of the latter.
Python users who know appscript but not
AppleScript will tend to ask questions about application scripting in a way
that AppleScripters who don't know Python won't understand.
The fact that most ASers don't know Python isn't an issue. The fact
that most are borderline computer literate at best is a bit of a
pest, since it means they won't be very good at recognising the
common underlying concepts. Appscript users will need to take a
degree of care in how they phrase application-specific questions. But
what's new?
As an example, the OP's question breaks down into two parts: how does
appscript work, and how does Quark work. Assume that an appscript
expert will answer the former, and rephrase bits of the latter so
that Quark experts will be more able to take a shot at it. Better
appscript documentation should ensure appscript users understand how
the bridging technology works, allowing them to better separate
application-specific questions from appscript-related ones before
asking them. Learning how to ask questions clearly and precisely is
something everyone has to learn. It's not like there's any shortage
of vague, confused and downright undecipherable questions already
being asked on AS lists.
(Somehow I don't see Shane Stanley answering too many appscript questions
about Quark.)
Who knows? Hopefully he'll answer Quark questions about Quark.
Hopefully if someone asks a Quark question that's all muddled with an
appscript question he'll ask for the question to be rephrased so it's
easier to understand. And maybe someday he'll decide that knowing a
bit about Python+appscript will be useful in its own right, and will
then be able to answer appscript-specific questions too (when he
feels like it). Python's a much better development tool than
AppleScript, after all, and as a shrewd professional workflow
developer he ought to recognise the commercial benefits of it.
That will keep you quite busy. If I, or other AppleScripters,
ever manage to get around to learning Python properly and then appscript, we
might be able to pitch in.
You don't need to be an expert in Python to answer questions about
application scripting. Understanding the fundamental principles by
which something operates is way more valuable, since that knowledge
is transferrable with little effort. Literals, variables,
conditionals, commands, references, etc. are all common to both AS
and Python and should be recognisable even without knowing the
language itself. I mean, seriously, any moderately competent
AppleScripter who understands what these things actually are and
still can't figure out that:
app('TextEdit').documents[1].text.get()
is equivalent to:
tell app "TextEdit" to get text of document 1
in their native tongue really isn't trying. Ditto the reverse.
Nobody's expecting an ASer to write a fluent Python solution in
response to a question by a Python user. Nor do they need to: a
fluent AppleScript solution will do just fine. Writing code may be
hard but _reading_ code is a piece of piss. And all that anyone needs
to do is read code just well enough to infer its meaning, something
both languages make pretty easy.
Furthermore, the more that folk ask and answer questions on-list, the
better they'll become at doing it. I don't expect the first burst of
communication to be instant and flawless; it's a learning process and
is going to take a bit of time and a bit of work by all parties.
But even the very limited documentation that
application creators provide for their AppleScript implementations will not
be extended to appscript, or even to raw AppleEvent documentation (I think
FMP may provide a bit of that.) It will mostly be up to you.
I won't be answering technical questions on QXP, ID, FMP, Entourage,
etc. myself because I'm not an expert in scripting any of them. I
will be around to ride shotgun on them, filtering the appscript
issues from the application issues where necessary (and I hope other
appscript veterans will feel free to chip in here too;).
I think you'r
[Pythonmac-SIG] Re: Re: appscript and XXXX - what is my app instance returning?
'me' wrote:
tell application "QuarkXPress"
tell document 1
set pw to page width as real
pw = app('QuarkXPress').documents[1].page_width.get(astype=k.Float)
But I haven't a clue where to find Quark's coercion method,
You pass the type you want the result returned as as an optional
argument to the command. It's the same for any app, e.g.:
from appscript import *
print app('Finder').home.items.get(astype=k.alias_list) # return a
list of Carbon.File.Aliases
Of course, working out what coercions an application implements can
be a barrel of laughs as it's one of those items that's often not
documented by the developer.
or the keyword for number.
AE type constants are in Carbon/AppleEvents.py. Appscript scrapes the
constant names and lops off the 'type' so that e.g. typeChar becomes
k.Char, typeFloat becomes k.Float, etc. A better system is definitely
needed, but I haven't figured one out yet.
Any other suggestions for converting this AppleScript coercion into python?
tell application "QuarkXpress"
tell document 1
set pw to (page width as number)
pw.get(astype=k.Char) ## it doesn't like 'astype' or 'k.Char'
The 'astype' argument should work ok. The problem is figuring out
what value to supply; you'll get a coercion error otherwise. Try
k.Float (what AS calls 'real').
pw.get(type=appscript.k.inch_units)
Unfortunately, using one of Quark's classes simply returns
another <_AE.AEDesc object>
The 'type' keyword argument isn't recognised, so is simply ignored.
(I should really go back to raising an error on unknown argument
names.)
The trick of passing a coercion was a complete surprise.
It's what AS does, except AS obfuscates it to look like it's the
language doing the coercion, not the application. AS is master of
leaky abstractions.
That idea isn't really obvious from the very nice documentation for appscript.
That's because I somehow forgot to document it. Apologies; I've added
it to my TO DO list.
I am still hoping to spawn a more fruitful discussion of how to
explore an app's interface using appscript.
What do you need to know?
The built-in help() system is good for interactive exploration. Of
course, since it depends on the application's terminology resource it
can't show you any information not already supplied there; all it
does is present what is available in a more helpful fashion. The
appscript documentation still lacks a section on the basic concepts
and principles behind application scripting which is a problem if you
don't already know what you're looking at; obviously this will be
addressed at some point.
But if we're complaining about having to be pre-cognizant of the
most minute detail
for an App's implementation of AppleScript before being able to do
anything with it;
I'd like to point out that being omniscient is a standard
requirement for writing IN AppleScript.
Yep. Appscript is NOT a magic fix for the problems caused by
individual applications' weird or broken scripting implementations
and painfully inadequate documentation; the only solution for that is
for individual users to petition those applications' developers to
fix these problems. File bug reports, file feature requests, have all
your fellow users get onto them too.
The one thing appscript does give you is a decent language to write
your scripts in. The AppleScript language, while it has some nice
features and [largely unrealised] ideas, is mostly a piece of crud:
slow, buggy, woefully short on the sorts of basic functionality you'd
expect from any half-decent scripting language, and virtually zero
library support. (Not the fault of the AS developers; blame the
clueless suits in Apple management for suddenly choking off its life
support two minutes after it was born and neglecting it ever since.)
To do the most simple thing, you must bang your head against the
wall until you hit upon the secret. Either by chance or by reading
other people's discoveries. You're never, ever privy to the source.
Don't even try to ask.
The first really useful thing to learn in AppleScript is how to
distinguish application-related problems from language-related
problems. At least with appscript you only have the
application-related problems to deal with (well, once it's finished,
anyway; for now there's still some appscript-related issues to knock
out, which is why threads like this are always very helpful for me
too). And once you know a problem is application related, you'll know
exactly whose balls to go bust until it gets fixed. :) No doubt
starting with lots of very insistent requests for radically improved
documentation.
I am honestly amazed appscript works at
[Pythonmac-SIG] application scripting info on pythonmac.org wiki
Hi all, I've extended the appscript entry on the pythonmac.org wiki to provide appscript users with a place to post tips, tricks, example scripts, links, etc. on scripting individual applications with Python+appscript: http://pythonmac.org/wiki/AppscriptModule Not much there yet, obviously, but hopefully over time it'll grow into an important and valuable resource for application scripters. Please contribute! has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] [ann] MacPythonOSA 0.1.0
Hi all, Just a quick heads-up on my latest venture into the wild and wonderful world of the Open Scripting Architecture, MacPythonOSA: http://freespace.virgin.net/hamish.sanderson/MacPythonOSA_project.dmg.gz Only semi-complete and minimally documented, and functioning more at proof-of-concept than production-quality level, but you should be able to build it and get a taste of Python a-la OSA. See the Tests folder for example scripts. Basic stuff like compilation, execution and display is fairly complete, and event sending and handling is mostly working at the raw AE code level. Other things like terminology support and recording are still to do, along with somehow insulating scripts from one another by providing each with its own module namespace, stdout and stderr. Please make sure you read the docs and install the latest version of aem before use: http://freespace.virgin.net/hamish.sanderson/aem-0.6.0.tar.gz If there's any problems getting it going then drop me a note. I will definitely need expert advice on the finer points of OSA component implementation in order to complete it, so if someone can help me out there it would be hugely appreciated. Regards, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] [ann] MacPythonOSA 0.1.0
Bob Ippolito wrote: >In the implementation, you do this: > >#define MAX_CSTRING_PATH_SIZE 32768 /* Because 32KB should be enough for >anyone... */ > >32KB is *way* oversized and could actually cause a problem because the default >stack size on Mac OS X is rather small. The right way is to just use >MAXPATHLEN. MAXPATHLEN is defined in , but you're already >including python.h -- which should guarantee that it is defined (even on >platforms that don't on their own). Yeah, it's pretty goofy; didn't know what to make it so just stuck in something big for the meantime. Fixed. (BTW, needed to include for some reason; compiler wasn't finding it without.) >You #include -- which should actually be #include >"MacPythonOSA.h" -- because it's not a system header. Though obviously it >doesn't make a difference in this case. Fixed. Much appreciated; my C is not exactly great, as you can tell. Project's re-uploaded. >The style you use for C code is totally whack, especially the indentation. It >would be a lot more readable if you wrote it in a standard style, the obvious >choice would be PEP 7 <http://python.org/peps/pep-0007.html>. That's just me; really don't care for either PEP7 or C syntax in general. It can always get run through a pretty printer later on. Spite just makes it tolerable in the meantime.:) >You should refactor this so that it doesn't link to Python.framework directly, >and instead loads up all of the symbols at runtime based upon a configurable >Python library. The biggest reason for this is: if the process is already >linked to Python, and you link in a different one by virtue of this component >being loaded into the process (not even initialized), it could very well >crash. The py2app plugin template doesn't currently look for an existing >linked interpreter, but it will at some point soon because I have to refactor >it anyway. If you detect an interpreter other than the one you expected, it >should probably prevent the component from being initialized -- since you need >the aem extension to be present. Good advice, though I'm not sufficiently up on C programming or OS internals to have a clue how to do it. Any pointers? Many thanks, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] [ann] MacPythonOSA 0.1.0
Bob wrote: >>>A multi-process model would be a lot more robust overall. [...] If you [...] >>>communicate with existing Python interpreters exclusively, it would probably >>>be much better overall (though much more work). >> >>Yep, removing Python from the component would require quite a lot more in C, >>which I'm not keen on for maintenance's sake. > >Not as much extra code as you'd think. The easiest way to do it would be as >an apple event "router". You receive the events from the OSA interface, start >up a Python process running code that can accept apple events from your router >(if it's not already running), and then toss the events to the correct process >(each component instance could correspond to a pid, maybe). Bit more to it than that, unfortunately: - OSA uses Component Manager - not Apple events - to communicate with language components, so the MacPythonOSA component would need to handle each OSA call, stuff its arguments into an IPC message, send the message to the script daemon to process and wait for its response. (This is just the easy bit, btw.) - In addition, the daemon also has to be able to send various messages to the OSA component to be handled there concurrently: CallActiveProc, CreateAppleEvent, SendAppleEvent, RedispatchAppleEvent. - Finally, it needs to do all this without any support from the client app and without treading on its toes in any way. And, very preferably, without an onerous IPC overhead that would limit its usefulness. Not trivial, and might get very sticky. Figuring out the details of what's involved and what the potential problems are is beyond my own modest abilities; someone else will have to do all the legwork here. >>>Threading sounds like a bad idea, given the constraints on them, the >>>difficulty to do it correctly, and the pain they are to debug when not >>>behaving correctly. >> >>Yep, I suspect there's no easy solution and it's going to be a struggle >>either way. Stupid Python. Just how painful are Python threads anyway >>(sub-interpreters specifically)? >> >>The only other option would be to find some way to provide each script with >>an independent module namespace and std I/O objects despite Python's global >>obsession, in which case we could safely run all scripts in the main thread >>(still not ideal, but good enough for most situations). I've no idea if >>that's practical or not though; it'd need someone familiar with Python's >>internals to answer it. > >Nope, not practical. Sub-interpreters are going to cause problems with >extension modules, Yep, I'm aware of that. The question is how serious those problems would be? Concurrency is less of a problem than usual as OSA scripts are typically executed sequentially; the main issue is when script A imports module X and sets some of its state, then script B imports module X and sets the same state to something else, which will cause A some serious upset the next time it attempts to use it. My goal is for MacPythonOSA to be a great OSA component first, and a great Python second. "Good enough" will be acceptable (after all, it's Python's fault we're in this mess in the first place:p). MacPythonOSA is not a 'standard' Python, and isn't intended to be: it's provided as an alternative to AppleScript and other OSA languages, not as an alternative to other Pythons. It's always going to provide a subset of normal Python functionality by its very nature and has no real application outside of OSA. So if I need to impose a few modest rules regarding usage (e.g. "Thou shalt not open and close the same file handle from different scripts at the same time", which is fair enough) then that may be entirely acceptable. The question is, how difficult will Python make it for users to reasonably follow these rules: will it merely take a modicum of common sense (acceptable), or require intimate knowledge of the inner workings of half of Python (not)? >and there is no way to have separate module namespaces for different code >running in the same interpreter. The only possibility is we could install custom import hooks each time we initialise/call into an OSA script and provide our own non-global module management system. Which might be practical as long as there's only ever one script being executed at a time. Still not an ideal solution though, since it would limit _all_ use to strictly single-threaded. i.e. Some multithreaded clients may open a separate component instance in each of its own threads, allowing it to execute multiple scripts in parallel even when the component language doesn't support threading itself - e.g. AppleScript. Not su
Re: [Pythonmac-SIG] [ann] MacPythonOSA 0.1.0
Bob wrote: >>- OSA uses Component Manager - not Apple events - to communicate with >>language components, so the MacPythonOSA component would need to handle each >>OSA call, stuff its arguments into an IPC message, send the message to the >>script daemon to process and wait for its response. (This is just the easy >>bit, btw.) >> >>- In addition, the daemon also has to be able to send various messages to the >>OSA component to be handled there concurrently: CallActiveProc, >>CreateAppleEvent, SendAppleEvent, RedispatchAppleEvent. >> >>- Finally, it needs to do all this without any support from the client app >>and without treading on its toes in any way. And, very preferably, without an >>onerous IPC overhead that would limit its usefulness. > >Python over IPC is going to be way faster than AppleScript ever was. Python+aem's actually a bit slower than AppleScript given most of the data conversion and event packing/unpacking is done in Python rather than C. (Not much though.) I think the main bottlenecks for AE-based IPC lie elsewhere; AS is guilty of a lot of things but I don't believe this is one of them. >Mach is good at IPC anyway. Mach messages could be preferable to Apple events: less chance of stepping on others' toes, perhaps? I really don't know the first thing about Mach messaging though. How big and complex a job would you guess a Mach messaging-based system would be, given the requirements above? >>Not trivial, and might get very sticky. > >I'd say the same thing about Python sub-interpreters. Of course. Like I say, there is no particularly good solution. If I thought the multi-process option would be trivial to do there wouldn't be any question, but it's not (especially not for me) so I'm just keeping my options wide open at this stage. >Python modules that use the PyGILState macros will likely be incompatible with >anything that does sub-interpreters, and likely a lot of other ones will be >too. Sub-interpreters get just shy of no testing whatsoever. Many extensions >aren't going to like being initialized twice. PyObjC is definitely, without a >doubt, going to barf with sub-interpreters. Other stuff probably will too. Yep. The next question is how significant these limitations would be for users, given the types of tasks OSA languages are actually used for (a fairly small list)? I suppose a reasonable parallel would be with mod_python, another specialised Python environment that manages to find sub-interpreters useful for all their caveats. Mind, it's not competing against standard MacPython but filling a separate niche, so lack of support for even something major like PyObjC may not be such an issue as it seems. Just as long as it doesn't lack support for Carbon.AE...;) Compared to the IPC option, which I know is a big technical job, how much work and complexity would there be in implementing a sub-interpreter solution? If it's the sort of thing that could be gotten up and running in a few dozen lines of code then I'd be very tempted to do that for now. (mod_python might even provide a useful template for doing this; I'd need to look.) Even if it's only a stopgap measure to be subsequently be reworked at leisure for IPC, at least it'd give us something we can ship. Or will it be just as big and complex as the IPC option? >>>Redirecting I/O at all sounds like a bad idea in the first place. >> >>stdin/stdout/stderr have no meaning within OSA: > >Yeah, they have no meaning -- so why bother mapping them to something else? Because 'print' in Python serves pretty much the same purpose as 'log' in AppleScript, and since Python prints to stdout it seems logical to redirect stdout to send log events to the host process instead. It can still go to Console as well if folks think that'd be useful. The primary goal is to make MacPythonOSA a good OSA citizen, even when it means diverging from conventional Python behaviour; any useful Unixisms we can retain on top of its OSA-ness are simply a bonus. Many thanks, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] [ann] MacPythonOSA 0.1.0
Bob wrote: >>>Python over IPC is going to be way faster than AppleScript ever was. >> >>Python+aem's actually a bit slower than AppleScript given most of the data >>conversion and event packing/unpacking is done in Python rather than C. > >Yes, the brokering of messages to and from an application may be marginally >faster in AS, but everything else is slow. Yep, the AS language itself is slow, but I don't care about AS being crap - I care about MacPythonOSA being not-crap. :) >>How big and complex a job would you guess a Mach messaging-based system would >>be, given the requirements above? > >You really shouldn't do mach directly, use sockets. Apple events use mach >ports to do IPC on a single machine anyway. Further proof that this task _definitely_ needs to be done by somebody other than me. :) >>Yep. The next question is how significant these limitations would be for >>users, given the types of tasks OSA languages are actually used for (a fairly >>small list)? > >PyObjC support *is* a big deal. Presumably people will be wanting to call >into Mac OS X APIs from scripts that run in Mac applications! Some will, some won't. (Those that do could just stuff the PyObjC bits into a scriptable FBA and call it from their OSA script. So it's not like it'd be impossible, just lame.) Lots of useful OSA scripts are actually quite trivial code-wise. Anyway... Truth to tell, after a month spent swearing at the atrocious lack of documentation on implementing OSA components, right now I don't really care much for dealing with the braindeadedness of the Python C API as well. I just want to get _something_ stuffed in there so I can call the project "finished" and kick it out the door; leave other folks to make improvements in their own time. I'll even kick it out with zero script insulation, no concurrent execution support and a big fat health warning if nothing decent turns up. Though if someone want to step up and give me an ETA on a code patch that'll meet the necessary requirements by whatever means they like, please do; it would be much better for users if MacPythonOSA could ship with a permanent solution already in place. Either way though I want it out the door soon; I've already got enough 18 month-old "slam-dunk" projects on my books as it is. :p >>>>>Redirecting I/O at all sounds like a bad idea in the first place. >> >>Because 'print' in Python serves pretty much the same purpose as 'log' in >>AppleScript > >So put something in the script's namespace that's called "log" and make it do >what log does. Thought of that, but 'print' feels natural from the end-user's POV and 'log' does not. Duplicating existing functionality simply to avoid doing a bit of extra work is just a copout; it's the developer's problem to make the users' lives easy, not vice-versa. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] converting file paths between HFS and POSIX formats
Hi all, Just wondering if there's anything in MacPython for converting HFS paths to POSIX and vice-versa, or is my memory playing tricks on me? If not, does anyone have some code they don't mind sharing? Ta, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] converting file paths between HFS and POSIX formats
Dave Opstad wrote:
> > Just wondering if there's anything in MacPython for converting HFS paths to
> > POSIX and vice-versa, or is my memory playing tricks on me? If not, does
> > anyone have some code they don't mind sharing?
>
>To clarify: are you asking for something that converts a string with colons
>to one with slashes and back; or something that converts from a slashpath
>into FSRefs or FSSpecs?
The former; e.g. 'Mac HD:Users:has:' to '/Users/has' and back.
...
Larry Meyn wrote:
>Jack helped me out awhile back in creating HFS paths. The archive is at
>http://mail.python.org/pipermail/pythonmac-sig/2003-August/008527.html
Thanks, I hadn't thought of that. (BTW, that code should really use FSRefs and
FSGetCatalogInfo() as FSSpecs can't show long filenames.) For what I'm doing,
it'd probably be better if it wasn't limited to existing filesystem locations
though.
...
Nicholas Riley wrote:
>Keep in mind that HFS paths aren't unique, whereas POSIX paths are, so
>you should be using FSRefs, CFURLs, POSIX paths or aliases for
>canonical representations, cognizant of all the tradeoffs between
>those formats.
>
>from Carbon.CoreFoundation import *
I'm kinda leery of using MacPython's CF wrapper as it's a bit buggy in places.
Still your example looks like it works ok - good suggestion, thanks.
One bit I'm not sure about though - if I run this:
u = toCF('A Non-mounted
Drive:').CFURLCreateWithFileSystemPath(kCFURLHFSPathStyle, False)
print u.CFURLCopyFileSystemPath(kCFURLPOSIXPathStyle).toPython()
I get '/A Non-mounted Drive' whereas I was assuming it should be '/Volumes/A
Non-mounted Drive' - is that correct?
...
Anyway, might help to show what I'm actually working on:
http://freespace.virgin.net/hamish.sanderson/macfile-0.1.0.tar.gz
It's a simple Swiss-army-knife wrapper for the various filesystem-related types
floating around MacPython, mostly cos I got sick of dealing directly with them
in appscript all the time. The Alias class is quite straightforward; the File
class tries to be clever by retaining the original object it was constructed
with and deferring to that as much as possible when performing conversions, etc.
I'm not sure how useful HFS path conversion options will really be; it seemed
an idea to put it in for completeness' sake, but perhaps it's just overkill?
I'd be very happy to take a second opinion on this, as well as any comments on
the rest of the design and implementation folks might have (e.g. there may be
some unsafe assumptions being made, subtle bugs and user gotchas, etc. that
I've not accounted for).
Many thanks,
has
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] appscript: click command not working
Demian Godon wrote:
>Question from a newbie (to both applescript and python):
>Can someone please explain why the following script does not cause the
>"Start Server" button to be clicked?
>
>app('/Applications/Utilities/OSXvnc.app').activate()
>app('System
>Events').application_processes['OSXvnc'].windows[1].buttons[4].click()
Not sure. It works on 10.2 (where I am), but this is the second time someone's
reported this problem on 10.3. If I can reproduce it when I upgrade to 10.4 I
should be able to nail it quite quickly. In the meantime, I believe the
alternate form works correctly:
app('System Events').click(app('System
Events').application_processes['OSXvnc'].windows[1].buttons[4])
HTH
has
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] converting file paths between HFS and POSIX formats
Larry Meyn wrote: >On Apr 22, 2005, at 7:00 PM, Bob Ippolito wrote: > > >> There are still some scriptable applications that only deal with HFS > >> paths, so I would vote for including conversion options if it's no > >> too much trouble. However, the need will decrease with time. > >> (Although I think KaleidaGraph may never get upgraded scripting > >> abilities.) > > > > Does it really take HFS paths as strings, and not FSSpec? Even if it > > did, wouldn't a FSSpec be coerced to a HFS path string along the way? > > >KaleidaGraph has it's own scripting language, so for anything beyond >open and close commands, one passes a KaleidaGraph script as a string. >Hence the need for HFS path strings. I've got some code, based on what >Jack suggested, that does what I need. Offhand, I can't think of any >other applications with this requirement, so it may not be worth Has' >time to support HFS path strings in his project if this is such a rare >need. Yeah, I think based on what folk here have said I'll leave out HFS path support for the time being. If I start getting lots of requests for it I can always add it in later along with the relevant caveats, but if it's just an occasional thing then they can always get a POSIX path and use Jack or Nicholas's code to convert it themselves. Many thanks to all for the input, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Python 2.3+Py23Compat/Python 2.4 compatibility problem
Hi all, Probably one for Bob, but there's an unpleasant disagreement between Py23Compat and Python 2.4 on where the LaunchServices, OSA, and other new 2.4 modules are located: the former installs them in individual directories of the same name under site-packages, the later keeps them at the top level of plat-mac/Carbon. This means scripts written on Python 2.3 break on 2.4 and vice-versa when importing any of these modules. What's the fix? has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Python 2.3+Py23Compat/Python 2.4 compatibility problem
Bob wrote: >>Probably one for Bob, but there's an unpleasant disagreement between >>Py23Compat and Python 2.4 [which] means scripts written on Python 2.3 break >>on 2.4 and vice-versa when importing any of these modules. What's the fix? > >This is not a bug, Maybe not, but it's hardly good design either. Any time I wish for gratuitous complexity or broken-by-design-ness I can easily use Perl or AppleScript instead. :p >try: >from LaunchServices import Launch, LaunchServices >except ImportError: >from Carbon import Launch, LaunchServices I figured that, but I'd rather hoped a more elegant solution might be forthcoming at source. Is there a good reason why they couldn't both agree on a common location, or at least provide the relevant aliases in 2.4 to preserve Python's much-vaunted backwards compatibility? Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Python 2.3+Py23Compat/Python 2.4 compatibility problem
Bob wrote: >>I figured that, but I'd rather hoped a more elegant solution might be >>forthcoming at source. Is there a good reason why they couldn't both agree on >>a common location, or at least provide the relevant aliases in 2.4 to >>preserve Python's much-vaunted backwards compatibility? > >This is *FORWARDS* compatibility, not backwards. Forwards compatibility is >always messy. Touché. ;) >1) Work around it On my todo list. (Requiring 2.4 isn't an option as casual Python users are more likely to be using the stock 2.3.5 and won't want to upgrade just on my account.) Still, can't blame my hoping there might've been a better solution... language warts are always unhappy things, Python warts doubly so. Pity Apple decided to stuff Python.framework into /System instead of /Library, otherwise having Py23Compat install into plat-mac/Carbon might not have been out of the question. I don't suppose Apple would be interested in including these modules (in the correct location) in future Tiger updates...? Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] [PyOXIDE] Drop support for 10.2?
Glenn Andreas wrote: > So given that 10.4 is currently available, I'm considering dropping support > for 10.2 from future versions of PyOXIDE. Sounds fine to me. Most folk will be on 10.3/10.4 now so focus your resources where it'll do most good, in this case getting PyOXIDE to a polished, stable 1.0 state. It's reasonable to expect something mature and irreplaceable like Python.framework provide compatibility across several OS versions, but a plain text editor and shell scripts can always stand in for an IDE if push comes to shove. I think if you can manage to support one major OS/Python version behind the current release while still in development then you're doing pretty well. HTH has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Carbon.AE problems revisited
Hi all, I'm working on the next version of aem/appscript for release later this month, and need some expert advice on the following problem: As some folks will know, some parts of aem rely on patches I've made to Carbon.AE's _AE.so extension that haven't yet been applies to the standard MacPython distribution. Previous aem releases required users to replace the current lib-dynload/_AE.so with this new version, which obviously becomes a bit of an issue when it means patching an Apple-installed Python.framework. To avoid arguments over permissions, it'd be best to put the modified _AE.so into site-packages. However, this means that there's now two _AE.so extensions in use, and therefore two non-interchangeable AEDesc types. This means that Python code that uses one is incompatible with code that uses the other, which is obviously not a good situation either - two AEDesc types is really one too many. Is there an 'official' way to deal with this sort of problem? If not, what other solutions are available to me, and what are the pros and cons of each? Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Free Python code and Licenses
Bob wrote: >>I have nothing against the GPL (well, yes I do, I think it makes the >>free and commercial software sides enemies, but that's a completely >>different topic), but I do think it would be nice if all free Python >>software was released under the same license as Python itself. > >Well the PSF license has certain issues in that it's only really meant to be >used by the PSF for software wholly owned by the PSF. >However, using MIT/BSD style license is equivalent to using PSF since they >are compatible. More info here: http://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq HTH has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] donation
Lee Cullens wrote: >All well and good Robert (and no disrespect intended) - but to me they seem >to be more interested in sending spam than alerting those that do business >with them. I've had a PayPal account since last year and have never received unsolicited mail from them. If you really are getting unwanted mails from PayPal (as opposed to scam mails that only pretend to be), check the Profile > Notifications settings for your PayPal account. As for catching the phishing spam, they're dead easy to spot once you know what they are: like Nigerian 409s, they tend to follow pretty predictable patterns. Any mail with a subject line like "Paypal Team identified some unusual activity in your account" is already more or less a dead cert. The "Dear Anonymous Customer" introduction is another giveaway (real PayPal emails always address you by your real name), as is the "click this link to login" bit (something you should NEVER do, as PayPal themselves will tell you). Just forward with full headers to [EMAIL PROTECTED] if you're feeling civic minded, and delete. An additional trick might be to set up a separate 'private' email address solely for use with your PayPal account, and put a filter on your inbox that automatically marks as spam any message claiming to be from PayPal that arrives at any other address. HTH has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] making a C extension compatible across OS versions?
Hi all, please forgive my crappy knowledge of C, etc. in advance... ;)
In updating my osaterminology package to support Tiger, I've added a new
function, OSAGetSdef(), to its OSATerminology.so extension [1]. To allow the
extension to build on older OSes, I've inserted an #ifdef as shown:
static PyObject *
PyOSA_GetSdef(PyObject* self, PyObject* args)
{
#ifdef AVAILABLE_MAC_OS_X_VERSION_10_4_AND_LATER
...
err = OSACopyScriptingDefinition(&fsref, 0, &sdef);
...
return res;
#else
/*
Return None when sdef is unobtainable.
Client can then call OSAGetTerminology() instead.
*/
Py_INCREF(Py_None);
return Py_None;
#endif
}
But now I realise this doesn't help in making a compiled extension work across
different OSes, so I obviously need to do something more/else.
Obviously the extension needs to be built on Tiger to provide sdef support, but
what should I do to ensure that, say, applications containing that binary
extension will still work OK when run on earlier OSes? For example, should I
include both extension builds in the osaterminology package and have it import
the appropriate one according to OS version, or is there a better/more
elegant/official way of doing it?
Many thanks,
has
[1] This is a modified version of OSATerminology.so that's bundled in the
osaterminology package, btw; I don't use the original copy in lib-dynload as
it's buggy.
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] making a C extension compatible across OS versions?
Nicholas Riley wrote: > > Obviously the extension needs to be built on Tiger to provide sdef >> support, but what should I do to ensure that, say, applications >> containing that binary extension will still work OK when run on > > earlier OSes? > >You can use weak linking if you don't need to support 10.1.x or >earlier, Ah, thanks. nm says OSACopyScriptingDefinition is weak, so I've added the appropriate 'OSACopyScriptingDefinition != NULL' check to OSATerminology.c and recompiled it for Tiger's Apple-installed Python. No problems using it there there, of course, but I do get the following (unrelated) error when trying to import it into user-installed Python 2.3.5 on 10.2.8 (I don't have a copy of Panther so dunno if it works on that): ImportError: Failure linking new module: /usr/lib/libmx.A.dylib: dyld: /Library/Frameworks/Python.framework/Versions/2.3/Resources/Python.app/Contents/MacOS/Python can't open library: /usr/lib/libmx.A.dylib (No such file or directory, errno = 2) Any ideas? (Source and binary are at <http://freespace.virgin.net/hamish.sanderson/osat.dmg.gz> if it's any help.) Many thanks, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] making a C extension compatible across OS versions?
Glenn Andreas wrote: >>ImportError: Failure linking new module: /usr/lib/libmx.A.dylib: dyld: >>/Library/Frameworks/Python.framework/Versions/2.3/Resources/Python.app/Contents/MacOS/Python >> can't open library: /usr/lib/libmx.A.dylib (No such file or directory, >>errno = 2) > >[...] Switching to gcc 3.3 will make this problem go away. Cool, ta. Next dumb question: how do I tell Distutils (Python 2.4.1 on OS 10.4.1) to use gcc 3.3 instead of 4.0? Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] making a C extension compatible across OS versions?
Bob wrote: >>ImportError: Failure linking new module: /usr/lib/libmx.A.dylib: dyld: >>/Library/Frameworks/Python.framework/Versions/2.3/Resources/Python.app/Contents/MacOS/Python >> can't open library: /usr/lib/libmx.A.dylib (No such file or directory, >>errno = 2) >> >>Any ideas? (Source and binary are at >><http://freespace.virgin.net/hamish.sanderson/osat.dmg.gz> if it's any help.) > >Well that error is solvable, but Tiger's python links extensions with a linker >flag that Jaguar does not understand -- so, it's time to give up. Not a big problem; don't supply Jaguar binaries as it is. More interested in Panther/Tiger portability. (I don't have a copy of Panther to test on myself.) Will extensions built on 10.4 work on 10.3, or will I have to create separate OS-specific binaries for those as well? Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] making a C extension compatible across OS versions?
Bob wrote: >>Will extensions built on 10.4 work on 10.3, or will I have to create separate >>OS-specific binaries for those as well? > >Maybe, it depends. > >You really should be building packages on the least common denominator, you >have to test there anyway. It's hard to do right, Xcode is the only >environment that can properly manage SDKs and such, Apple didn't really put >that functionality anywhere else, and autoconf REALLY gets in the way (i.e. >./configure). Not a problem for other modules where the APIs are the same over multiple OSes. (I've had no problems so far using .so binaries built on Jaguar under Tiger, for example.) Given that OSATerminology needs to use Tiger's weak-lined OSACopyScriptingDefinition function when running under Tiger, is it possible/practical to build it on Panther? It sounds like the easiest thing would be to put the Tiger-only code in a separate file and build that on Tiger, and build the remainder on an older OS as before; then have osaterminology import or ignore the Tiger-only extension at runtime as appropriate. Many thanks, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] making a C extension compatible across OS versions?
Bob wrote: >> It sounds like the easiest thing would be to put the Tiger-only code in a >> separate file and build that on Tiger, and build the remainder on an older >> OS as before; then have osaterminology import or ignore the Tiger-only >> extension at runtime as appropriate. > >Yeah, the "easiest" thing is basically to do that, or to build an entirely >separate version for users with Tiger. Will do. Much thanks for your patient advice. has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] best way to get os version?
Hi all, Apropos to last thread, what's the best way to check Mac OS version from Python at runtime? Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] binary extension portability
Hi folks, One more question: am I right in thinking that extension binaries aren't portable between major Python versions, e.g. an .so file built under Python 2.3 won't work on Python 2.4 and vice-versa? Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] binary extension portability
Bob wrote: >>One more question: am I right in thinking that extension binaries aren't >>portable between major Python versions, e.g. an .so file built under Python >>2.3 won't work on Python 2.4 and vice-versa? > >Correct, binary extensions are not portable between major Python versions on >ANY platform. Thought as much, just couldn't seem to find confirmation in the Python docs. Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Appscript Installer 1.1a1
Bob Ippolito wrote: >An installer, as built by bdist_mpkg, won't install anything unless >Python is where it expects it to be. Thus, it's not possible to >install into a framework that doesn't exist. Interjecting a moment, the appscript installer needs to carry both 2.3 and 2.4 versions of half a dozen package binaries (including osaterminology, which needs to be hand-built across two different OSes), so that it can install the appropriate set of binaries into each Python.framework it finds: Apple-installed 2.3.x on 10.3 and 10.4, user-installed 2.4.x on either; maybe more. Plus a couple pre-built helper apps to go in /Applications/Utilities. Is bdist_mpkg suitable for building such general-purpose installers? My impression was that it's limited to building a binary installer for a single Python package on a single major Python version, or can it do more? OK, back to you guys now... :) has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Appscript Installer 1.1a1
Bob Ippolito wrote: >There are three situations you should be concerned with: >1. Python 2.3.0 on Mac OS X 10.3 >2. Python 2.3.5 on Mac OS X 10.4 >3. Python 2.4.x on either > >1 and 2 can be dealt with by a single package, built on Mac OS X 10.3 >with bdist_mpkg installed for Python 2.3.0 > >3 can be dealt with by a single package, built on Mac OS X 10.3 with >bdist_mpkg installed for Python 2.4.1. I'd better point out - as much for Nick's benefit as anyone's - that bdist_mpkg currently isn't suitable for building an appscript installer as osaterminology's OSATerminology extension has to be built on both OS 10.3 and 10.4 and the resulting pieces assembled by hand. Though I think I could split osaterminology into three separate packages, two to be built on 10.3 and the other on 10.4, to get around that problem. If bdist_mpkg was used for that, would the third installer, the one built on Tiger, also work correctly on Panther? has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Appscript and iTunes track deleting
Jared Barden wrote:
>If I'm using appscript to delete a track from a user_playlist (which
>is where I need to start from), what is the best way to delete that
>same track from the library playlist as well? Deleting from the
>playlist only removes it there, obviously, and that's not what I'm
>looking for.
iTunes scripting implementation is pretty skanky. You have to use the track's
database_ID:
from appscript import *
itunes = app('iTunes')
tracktodelete = itunes.playlists['test list'].tracks['test track']
itunes.playlists['library'].tracks.filter(its.database_ID ==
tracktodelete.database_ID.get()).delete()
If you're deleting multiple tracks, you'll have to iterate over a list of
database IDs and delete the tracks one at a time.
HTH
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Finding what a broken alias refers to.
Hubert Holin wrote:
> It would seem that the best function to get that information is
>thru the FSFollowFinderAlias function of the Alias Manager, but
>unfortunately the only version which is wrapped is a member of the
>Alias class, which I have not found a way to use, as all I have is an
>instance of FSRef.
As Bob says, you want to create a new Alias out of the alias file's alis
resource, e.g.:
from Carbon.File import FSRef, Alias
from Carbon.Res import *
f = FSRef("/Users/has/a 'broken' Finder alias file")
resfile = FSOpenResFile(f, 1)
data = Get1IndResource('alis', 1).data
CloseResFile(resfile)
alias = Alias(rawdata=data)
To get any useful data out of this 'broken' alias you'll have to get your hands
dirty though.
> Likewise, the Alias Manager functions FSMatchAlias and
>FSMatchAliasNoUI seem not to be wrapped.
Ditto FSCopyAliasInfo. Unfortunately I don't think Python's Carbon wrappers
have been updated much since their creation back in pre-OS X days. You could
probably patch up a copy yourself without much trouble; it's a slightly hackish
solution, but not that hard to do (I've done it myself and my C's rubbish).
HTH
has
--
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Finding what a broken alias refers to.
Bob wrote: >>Is there a way I can contribute (using some of the time >>slots I now try to put aside for Boost and the unreasonable number of >>things I intend to do)? > >Currently, all of the wrapped Carbon functionality is done with an ancient, >fragile and undocumented parser/generator called bgen, which parses out >Universal Headers and spits out potentially working Python bindings. In >order to make a useful contribution to those modules, you'd have to learn it, >which really isn't worth doing. For your own purposes you could hack the C >code it spits out directly, but unless it's done with bgen, it's not going to >end up in Python CVS. I blame Joseph Heller myself. has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Finding what a broken alias refers to.
Bob wrote: >Nobody is suggesting that we manually wrap Carbon. Indeed. However, given the effective deadlock that bgen is causing (great-in-theory being the enemy of good-in-practice) perhaps we could find a pragmatic compromise? A semi-automated system that works adequately would, I think, be preferable to a fully automated one that doesn't. 1. Could we take the current bgen-generated C source and turn it over to manual maintainers? Apple's Carbon APIs aren't changing much these days, so I doubt there'll be much need to regenerate existing extensions from scratch, and it'll be easier to find volunteers willing to apply bugfixes and minor addition by hand than via bgen. Copy-n-paste and C macros should be more than adequate for this kind of work. e.g. I'd be willing to fix and maintain the AE and OSA extensions by hand, whereas there's probably zero chance of finding someone willing to actively work on them via bgen. 2. Could we take the more useful Carbon extensions and create a new third-party 'CarbonX' package where they can be actively developed and maintained? The original Carbon extensions in the standard distribution could be quietly deprecated; a lot of it's just deadweight anyway. I can't see them being thrown out before Python 3.0, but we can discourage their use in favour of alternatives like CarbonX and PyObjC. has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Finding what a broken alias refers to.
Ronald Oussoren wrote: >I'm not happy with the way that the Carbon wrappers work, adding Carbon >functions as methods of seemingly related classes. This makes it harder to map >documentation for Carbon to Python. It is also ugly. But this might not be a >problem with bgen itself. > >I'd prefer to see the function wrapped as functions in the Carbon module. That would be my preference as well, at least for any new work. Stick with plain functions + opaque types. I'd rather deal with a well designed ADT-based API than a not-so-well designed OO one. Part of bgen's problem is that it's a victim of its own cleverness: it tries to do much more than it actually needs to, which ends up creating additional complexity; i.e. more things to learn, more things to go wrong. >If needed one could add convenience methods to type wrappers as well, but with >a more pythonic interface. That would require more work because you'd have to >make up a nice interface and document it. I'd suggest writing any new OO wrappers as Python classes. Less work than doing it in C, and it'd make it much quicker and easier to tweak and polish the high-level API design. has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
