[Pythonmac-SIG] Finding what a broken alias refers to.

[Bob Ippolito]

On Jun 23, 2005, at 11:54 AM, Hubert Holin wrote:

> On 21 juin 2005, at 22:35, pythonmac-sig-request at python.org wrote:
>
>
>> From: Bob Ippolito <bob at redivi.com>
>> Date: 21 juin 2005 17:49:59 HAEC
>> To: Hubert Holin <Hubert.Holin at meteo.fr>
>> Cc: pythonmac-sig at python.org
>> Subject: Re: [Pythonmac-SIG] Finding what a broken alias refers to.
>>
>>
>> On Jun 21, 2005, at 11:21 AM, Hubert Holin wrote:
>>
>>>      Likewise, the Alias Manager functions FSMatchAlias and
>>> FSMatchAliasNoUI seem not to be wrapped.
>>>
>>>      What can I do, short of writing a C++ extension?
>>>
>>>
>>
>> Writing a C extension or using the FFI available in PyObjC or
>> ctypes are the only ways to bridge unwrapped functions.
>
>          A question: I'd much, much rather use C++ than C (and never
> mind Objective-C). I have some idea of how to write Python extensions
> in C++, using Boost.Python. From reading what little documentation
> there is on Objective-C++, I see there are possible issues between
> the C++ and Objective-C runtimes. If I build a C++ extension and
> intend to use it along with PyObjC, am I inviting trouble ;-)   ?

Yes, but you really don't want to use something like Boost unless you  
have a fair amount of existing C++ code.  In this case you need one  
or two functions, and it's more than overkill.

C++ code and Objective-C code play together just fine.  In the case  
of Objective-C++ (a separate language, but the same runtime), you can  
mix the two in the same source file with a few limitations (namely  
putting C++ in ivars and expecting ctor/dtor stuff to happen  
automatically, etc.).  This is a don't-write-broken-source-code kind  
of issue, it can't happen by mixing things at runtime with Python.

>> From: Chinook <chinook.nr at tds.net>
>> Date: 21 juin 2005 18:20:07 HAEC
>> To: pythonmac-sig at python.org
>> Subject: Re: [Pythonmac-SIG] Finding what a broken alias refers to.
>> Reply-To: chinook.nr at tds.net
>>
>>
>>             csvline = _cellpos(dlfpath, alvl, blvl, clvl)
>
>          Thank you for the suggestion. May I ask where "_cellpos" is
> documented? Yes, I am a newbee in more fields than one :-)   .

In his project, if you're lucky.  It's certainly nothing standard.

> On 22 juin 2005, at 12:00, pythonmac-sig-request at python.org wrote:
>
>>
>> From: has <hengist.podd at virgin.net>
>> Date: 22 juin 2005 01:39:32 HAEC
>> To: pythonmac-sig at python.org
>> Subject: Re: [Pythonmac-SIG] Finding what a broken alias refers to.
>>
>>>     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).
>
>          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.

-bob