Issue734695
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.
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) * | 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) * | 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) * | 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) * | 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) * | 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) * | 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:39 | admin | set | github: 38466 |
2003-05-08 15:15:45 | ronaldoussoren | create |