[Pythonmac-SIG] CFURL Pain
bob at redivi.com
Tue Mar 1 19:55:30 CET 2005
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
>>> 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
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
> 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
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?
>> 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:
What you *actually* want is a Finder alias anyway.
Something like this will probably work:
rval = Carbon.File.FSRef(path).FSNewAliasMinimal()
>>>> 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
>> 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
More information about the Pythonmac-SIG