This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Function for creating/extracting CoreFoundation types
Type: enhancement Stage:
Components: macOS Versions:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: jackjansen Nosy List: jackjansen, ronaldoussoren
Priority: normal Keywords:

Created on 2003-05-08 15:15 by ronaldoussoren, last changed 2022-04-10 16:08 by admin. This issue is now closed.

Messages (6)
msg15915 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2003-05-08 15:15
pymactoolbox.h contains a number of functions for
converting from CoreFoundation references to Python
wrappers for those functions (e.g. CFTypeRefObj_New).
Simularly there are functions for extracting the
CoreFoundation reference from a wrapped Python object
(e.g. CFTypeRefObj_Convert).

It would be nice if CFTypeRefObj_New would automaticly
create a more specialized Python wrapper if you pass it
a CFArrayRef, this decreases the coupling between the
python core and 3th party extension modules.

Simularly CFTypeRefObj_Convert should "work" when
passed a CFArrayRefObj.
msg15916 - (view) Author: Jack Jansen (jackjansen) * (Python committer) Date: 2003-05-27 21:43
Logged In: YES 
user_id=45365

Implemented in CVS, but I have called the new generalized functions 
CFObj_New() and CFObj_Convert().

One issue is open to discussion: currently CFObj_New() expects a CFTypeRef 
object for which a wrapper is available. An alternative would be to use 
PyCF_CF2Python() otherwise (so CFNumber would get mapped to a Python 
int, etc). Similarly for CFObj_Convert(), which expects an object of one of the 
classes Carbon.CF implements. It could also fall back to using 
PyCF_Python2CF(). Let me know which solution is better.

Also: the code is pretty much untested. Please test, and close this report 
when you're satisfied (and after answering the previous question).
msg15917 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2003-05-29 19:55
Logged In: YES 
user_id=580910

The new functions seem to work just fine, and the
implementation looks OK too.

I think the current implementation is fine, automaticly
converting only some types to/from their python equivalent
would be confusing. Furthermore the current behaviour allows
me to get as close as possible to 'toll-free bridging' ,
which means it should be possible to translate code examples
that use this feature into Python without too many problems.

Thanks for implementing this!
msg15918 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2003-05-29 20:55
Logged In: YES 
user_id=580910

My initial tests were a little too easy, now that I've
completely rebuild PyObjC I see:

ImportError: Module did not provide routine: Carbon.CF:
CFObj_New

Shouldn't there be code in _CFmodule.c to make sure that the
mactoolboxglue can find the two new functions?
msg15919 - (view) Author: Jack Jansen (jackjansen) * (Python committer) Date: 2003-05-31 22:09
Logged In: YES 
user_id=45365

Oops, sorry, I thought I had added it! It's in there now.
msg15920 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2003-06-08 15:00
Logged In: YES 
user_id=580910

Yup, it works now. What I don't like is that the mutable
variations of datastructs (e.g. CFMutableArrayef) get mapped
onto wrappers for the immutable versions (e.g. CFArrayRef).
This seems to a limitation of CF.
History
Date User Action Args
2022-04-10 16:08:39adminsetgithub: 38466
2003-05-08 15:15:45ronaldoussorencreate