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 - Pythonmac-SIG@python.org 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 - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] CFURL Pain
On 3/3/05 7:31 AM, has [EMAIL PROTECTED] wrote: 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 Bo, that one was quite short-standing (OS 10.1 and 10.2) and only for TextEdit. Only TextEdit specified a POSIX path string for 'save' - it has now been changed to standard AppleScript colon-delimited paths to correspond with all other apps. 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. Yes. 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. No, that's broken - it was only TextEdit in OS 10.1 and 10.2 that ever did the POSIX paths. ( 'save document 1 in /Volumes/PB G5 HD Panther/Users/berkowit/Desktop/TestDoc.rtf' saves the document in a file of that exact entire name - complete with forward slashes - on my root startup disk!!) Only colon-delimited paths work correctly now, not POSIX paths. I can't imagine that there are too many broken scripts since TextEdit's scriptability is so limited in the first place that there's not much you can do with it. -- Paul Berkowitz ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: broken modules (was: Re: [Pythonmac-SIG] CFURL Pain)
Hi Bob: Very few people care that undocumented modules don't work correctly. You have to look pretty hard to even notice their existence in the first place. I've never heard of a broken undocumented standard library module becoming a deal-breaker for someone new to Python. Looking at the Global module index http://python.org/doc/2.4/modindex.html it's hard not to notice the existence of the long list of Carbon.something modules in the left column. I think it would be a good idea to replace this with a single entry for Carbon, that explains that those modules are deprecated and one should use PyObjC instead. ciao Martina ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] CFURL Pain
On 3/2/05 6:00 AM, has [EMAIL PROTECTED] wrote: 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. The type 'alias' for the Save command in the Standard Suite is a long, longstanding bug in AppleScript. It should say 'file specification', or 'file', I guess. There's a special problem in AppleScript applications which have their own 'file' keywords meaning something else (like Outlook Express and Entourage), as you can imagine. Fortunately there is an equally longstanding coercion, performs by AppleScript itself, that allows you to use a string or Unicode text there. 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? In _any_ AppleScriptable application, you can always just use the text file path for 'save' in AppleScript, and it works. -- Paul Berkowitz ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: broken modules (was: Re: [Pythonmac-SIG] CFURL Pain)
Bob wrote: 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. Yet you screw around with the Carbon modules, which also have no documentation or tutorials? No more than I can help. And there is documentation if you're willing to work through docstrings and Apple docs to extract the relevant info. It's not much fun, but it's doable. 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? If the fix didn't consist of adding new features With specific regard to OSA.so, of course it would consist of adding new features: half the damn OSA API is missing from the stupid thing. 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. The extension(s) are part of Python 2.4, and follow the same policy as anything else in there. The lack of a binary release doesn't really mean anything. Whatever; if it's too late to change then write it off; leave it in the standard library but expunge all mention of it and maybe add a warning to let the unwary know it's duff. Anyway, let's not lose site of the big picture: what really matters is to change the rules so this kind of nonsense doesn't happen again. Do you agree with that? It's already there, so it's not going anywhere in 2.4. The justification is that people *did* ask for an OSA wrapper -- I believe you were one of the larger proponents. 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. It's partially your fault for not testing it *before* final release. No, don't you try dumping this on me. It's _entirely_ the fault of whoever decided to include an untested module in the standard library. Doesn't matter if there's a hundred or a thousand or a million people screaming for it; doesn't matter how loud they scream, throw tantrums or turn blue in the face. As I already said, it's really simple: if nobody cares about it enough to test it then don't put it in. No exceptions. Look, if I submitted a completely unused, untested and potentially broken module for inclusion in the standard library I'd be told to get lost and not come back until I'd fully addressed that, and quite right too. Please tell me the justification for the apparent double standard here. In addition, I believe submission rules for the standard Python distribution require modules not only to work but also be in widespread usage before it'll even get looked at. Why should MacPython not be following this rule too? This is not personal: I'm not looking for blood, to cause embarassment, assign guilt, score petty points, etc. I am simply trying to show there is an ongoing problem here that folk should acknowlege and try to address. 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? As I stated before, MacAll can't use the Carbon namespace, so this trivial reorganization is not possible. It could if you just punted the _entire_ Carbon namespace into MacAll. Or are there dependencies in the core Python framework that prevent this? And if there is, hell, why not just deprecate the whole thing and create a new 'carbon' namespace in MacAll and tell folk to use that in future? You might never get rid of Carbon, but at least it'll get it sufficiently out the way for a clean new officially sanctioned version to set up shop. 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. Very few people care that undocumented modules don't work correctly. You have to look pretty hard to even notice their existence in the first place. I've never heard of a broken undocumented standard library module becoming a deal-breaker for someone new to Python. MacPython: We've all this great Mac-specific stuff, but we won't tell you how to use any of it. Also, quite a bit of it is broken because we couldn't be bothered to do do a decent job of it. This is not the way to make a great impression with users. And really, what is 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
Re: broken modules (was: Re: [Pythonmac-SIG] CFURL Pain)
On Mar 2, 2005, at 16:02, has wrote: Bob wrote: 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? As I stated before, MacAll can't use the Carbon namespace, so this trivial reorganization is not possible. It could if you just punted the _entire_ Carbon namespace into MacAll. Or are there dependencies in the core Python framework that prevent this? And if there is, hell, why not just deprecate the whole thing and create a new 'carbon' namespace in MacAll and tell folk to use that in future? You might never get rid of Carbon, but at least it'll get it sufficiently out the way for a clean new officially sanctioned version to set up shop. If you punted the entire Carbon namespace into MacAll, it wouldn't be compatible with any current Python, which is a non-starter. 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. Anyway, many of the things in the Carbon namespace aren't Carbon at all. QuickTime, for example. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: broken modules (was: Re: [Pythonmac-SIG] CFURL Pain)
On Mar 2, 2005, at 1:02 PM, has wrote: It's already there, so it's not going anywhere in 2.4. The justification is that people *did* ask for an OSA wrapper -- I believe you were one of the larger proponents. 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. Writing a Python OSA component is going to require accessing much of the functionality in OSA.h from Python, and bgen is a reasonably expedient way to expose Carbon headers in the Universal Headers format. Unfortunately, unless you try the resulting module, things do tend to be broken without manual tweaking. I was able to write bgen wrappers for CarbonEvents and IBCarbon and tweak the bgen module by hand until the resulting modules were actually usable for trivial applications, but obviously nobody ever tried this with the OSA module. 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. dp ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] CFURL Pain
On Mar 1, 2005, at 9:55 AM, has wrote: 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). Unfortunately getting rid of an extension is a lot harder than it sounds. Better is to just stop using it, and possibly deprecate it. I don't think anyone is really using that module anyway. 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? 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. Instead of fixing OSA, you can write an alternative that isn't bgen based. *What* FSSpec problem with Carbon.File? Although there is generally not a very good reason to use FSSpec or FSRef, unless you're working with resource forks or Aliases, I haven't had problems with Carbon.File at all. This is probably the most robust module in the bgen Carbon wrappers, as it's the one that actually gets used. 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. Well the problem I have is that even if you know the C API then you will stumble with the Pythonized version of it (with bgen generated stuff). 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? Just tell people to stop using standard library stuff and use the more robust alternatives. The standard library bits can't disappear, because that would break compatibility. Of course, this is assuming that more robust alternatives to the standard library's exists. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org 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=detailaid=706592group_id=5470atid=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 - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] CFURL Pain
On Mar 1, 2005, at 11:58 AM, has wrote: Bob wrote: 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? Unlikely, but what does it matter? We're talking about making a package separate from the standard library. Even if it did happen right now, that would mean Python 2.5, which really means probably next year. *What* FSSpec problem with Carbon.File? http://sourceforge.net/tracker/index.php? func=detailaid=706592group_id=5470atid=105470 Ah, right. I ran into that problem once with QuickTime, but it turned out that there was another way. 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). Does that FSSpec bug really effect you? When do you need to pass FSSpecs to files that do not exist across processes? 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? 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. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org 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=detailaid=706592group_id=5470atid=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 - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] CFURL Pain
On Mar 1, 2005, at 1:21 PM, has wrote:
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?
They're automatically generated, these things happen.
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.
It's not hard to usurp something from the Carbon namespace because most
of the stuff in there isn't documented anyway. The third fiddle
problem is only relevant to people like you who like to complain about
dependencies and try to do things the hard way for very little benefit.
*What* FSSpec problem with Carbon.File?
http://sourceforge.net/tracker/index.php?
func=detailaid=706592group_id=5470atid=105470
Ah, right. I ran into that problem once with QuickTime, but it
turned out that there was another way.
Do tell!
This was specific to QuickTime, not a general solution. I don't
remember what it was specifically.
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.
Something like this will probably work:
import Carbon.File
import MacOS
import os
def alias(path):
try:
return Carbon.File.FSRef(path).FSNewAliasMinimal()
except MacOS.Error:
pass
file(path, 'w').close()
rval = Carbon.File.FSRef(path).FSNewAliasMinimal()
os.unlink(path)
return rval
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.
Well obviously that's not an option, so pretend that the Carbon
namespace doesn't exist, except for the modules that work as you expect
them to.
-bob
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
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 - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] CFURL Pain
On Mar 1, 2005, at 3:08 PM, has wrote:
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.
Not stone, just molasses. If you learn bgen and submit proper patches,
you can fix existing modules in the 2.4 maintenance branch and add/or
features to the 2.5 branch.
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.
You can learn bgen and fix it the correct way, and submit a patch.
Jack doesn't need to commit the patch. I did this once or twice, it's
possible for someone other than Jack to do it.
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.
Removing the extension may or may not be a good idea. If /some/ of it
works, it might be worth keeping.
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.
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. In this case, the
API *asks* for an Alias. So, yeah, you do actually want an Alias.
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!
My point is that it's perfectly fine to IGNORE THE STANDARD LIBRARY.
Whether or not the Carbon package exists in the standard library has no
effect whatsoever on a MacAll package! The only harm it's doing is
taking up the name 'Carbon' in the sys.modules namespace. For
compatibility reasons, the MacAll package can't use the name Carbon
anyway.
-bob
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
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 # CFURL object at 0x000c10e0 for 0x000de810
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 # CFURL object at 0x000c10f0 for 0x0004fec0
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 - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] CFURL Pain
On Feb 28, 2005, at 1:41 PM, has wrote:
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 # CFURL object at 0x000c10e0 for 0x000de810
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 # CFURL object at 0x000c10f0 for 0x0004fec0
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)
I wouldn't be surprised if it's broken, use PyObjC and NSURL instead,
those work. Why haven't you upgraded to 2.3.5 (not that I think it
would help)?
-bob
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] CFURL Pain
On Feb 28, 2005, at 3:41 PM, has wrote: 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) Well I can verify that there definitely are serious problems with CFURL after screwing around with it a bit. I don't have time to chase bugs, though. use PyObjC and NSURL instead, those work. Introduces a big fat third-party dependency though, something I'm trying to avoid here. Too bad :) If you're writing Mac OS X specific code you **really** should have PyObjC anyway. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org 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 cough. has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] CFURL Pain
On Mon, Feb 28, 2005 at 06:41:47PM +, has wrote:
import Carbon.CF as CF
f =
CF.CFURLCreateFromFileSystemRepresentation('file://localhost/Users/has/',
True)
That's not a filesystem representation (code for UTF-8 encoded path).
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')
When CF stuff crashes, you can often get more information by using the
debug version of frameworks:
% DYLD_IMAGE_SUFFIX=_debug ipython
2005-02-28 15:34:18.928 python[16198] CFLog (0): Assertions enabled
In [1]: import Carbon.CF as CF
In [2]: f = CF.CFURLCreateFromFileSystemRepresentation('/Users/nicholas', True)
In [3]: f.CFURLGetString().toPython()
2005-02-28 15:34:29.168 python[16198] CFLog (15): CFStringGetCharacters():
string range 0,32 out of bounds (length 31)
Out[3]: u'file://localhost/Users/nicholas'
In [4]: f.CFURLGetFSRef()
zsh: 16198 bus error DYLD_IMAGE_SUFFIX=_debug ipython
[...]
In [3]: f.CFURLGetFSRef()[1].as_pathname()
DebugAssert: Third Party Client: err == 0 [-43]
FSPathMakeRef_GetObjectInfoFailed [line 1670, file Files/HighLevelCalls.c]
DebugAssert: Third Party Client: volume != NULL FSMakePath_VolNotFound [line
848, file Files/FilePathUtils.c]
DebugAssert: Third Party Client: (tempMapOffset = (fileLength -
kNullMapLength)) exit CheckMapHeaderCommon(), Resource Manager: EOF truncates
resource map.[line 195, file Resources/Source/ResourceUtils.c]
---
Error Traceback (most recent call last)
/Users/nicholas/console
Error: (-35, 'no such volume')
In [4]: f.CFURLGetFSRef()[1]
DebugAssert: Third Party Client: err == 0 [-43]
FSPathMakeRef_GetObjectInfoFailed [line 1670, file Files/HighLevelCalls.c]
Out[4]: Carbon.File.FSRef object at 0x5756a8
In [5]: f = CF.CFURLCreateFromFileSystemRepresentation('/Users/nicholas/', True)
In [6]: f.CFURLGetFSRef()[1].as_pathname()
Out[6]: '/Users/nicholas'
It's hard to say if the crash is Python's fault or CF's fault, but
there's definitely a wrapper bug in there. And it looks like you need
the trailing slash; didn't bother to check if that is by design or
not.
--
Nicholas Riley [EMAIL PROTECTED] | http://www.uiuc.edu/ph/www/njriley
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
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 - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
