[Pythonmac-SIG] Some new tools: plistservices, userdefaults, and CFPython

[Bob Ippolito]

On Friday, Sep 5, 2003, at 19:51 America/New_York, Sarwat Khan wrote:

>> I dunno if it's more functional than the pycfbridge... I've been able 
>> to get away with using the bridge's conversion functions and crossing 
>> my fingers and hoping what I wanted to get pops out.
>
> It's more functional in that it handles datetime.datetime/CFDate and 
> CFData objects. It's also configurable for that functionality.

 >>> import Carbon.CF
 >>> data = Carbon.CF.CFDataCreate('some arbitrary data...')
 >>> data.CFDataGetData()
'some arbitrary data...'

What more do you want from that?  Sure, it *should* have a toPython 
that works, but unfortunately it doesn't at the moment.

I agree that CFDate needs an additional type, but you can add that 
additional type outside the scope of Carbon.CF while still maintaining 
compatibility (i.e. allow it to init from a Carbon.CF.CFTypeRef, and 
allow it to be converted to a Carbon.CF.CFTypeRef).  If you want to 
figure out whether or not it's a CFDate coming in as a CFTypeRef, you 
simply have to compare CFTypeRef.CFGetTypeID() to the CFTypeID of 
CFDate and then if it is a CFDate then you can use the C API functions 
to grab the real CFTypeRef from C.

>
>>
>> Some quick suggestions:
>> 	You should probably rewrite the module to use the existing 
>> pycfbridge for interoperability, like PyObjC and my LaunchServices >> do.
>
> It's not actually a module though, and that's why it doesn't have a 
> setup.py. For an example use of the thing take a look at the source 
> for the userdefaults module at http://sarwat.net/opensource/ .
>
> CFPython is meant for writing C code. I did hack in a module for 
> testing but that's not supposed to be used for anything else. It's 
> like choosing between putting pycfbridge.c or CFPython.c in your 
> project to translate PyObject*s into CFTypeRefs.
>
> Although if you think it has a useful future a module, let me know; I 
> wrote it because it was an easier way of writing the userdefaults 
> module. I haven't considered it to be anything else.

I see that now, but I still think you should simply use the 
CFDataGetData/CFDataCreate methods when you need a CFData, and write a 
simple CFDate extension module to add that functionality to Carbon.CF.

-bob