Ivan Raikov scripsit: > Pyffi uses the Python C interface to convert Python values to Scheme > values and vice versa, and to invoke Python procedures and methods, > and automatically convert their arguments and return values to and > from Python and Scheme representations. It supports Python numeric > values, strings, lists, tuples, and dictionaries; all other types are > represented in Chicken as pointers. I have not made any attempts to > optimize the value conversion code, and I have only tested pyffi with > very simple code and small data structures.
This is great stuff. Two points about Unicode (inevitably): 1) UTF-32 representations are definitely unsigned, so a u32vector is better than an s32vector. It doesn't matter in practice, since the largest possible UTF-32 value is #x10FFFF. 2) I would argue that for Chicken, 32vectors are a bad choice; it makes it annoying within Chicken to treate Unicode strings as strings. There is a good package for treating Chicken strings as UTF-8, and IMHO both Python strs and Python unicodes should be represented on the Chicken side as strings, converting the Python unicode to UTF-8. This of course leads to the question of when a Chicken string should be passed to Python as a str, and when it should be passed as a unicode. A simple approach such as using a pair like '(UTF-8 . "foobar") to pass a unicode vs. simply "foobar" to pass a str would not be optimal, but would suffice. Looking at the content is not enough, since some Python code requires unicodes even if the content is all-ASCII. It's a question whether this representation should also be returned to Chicken, or not to bother. -- The experiences of the past show John Cowan that there has always been a discrepancy [EMAIL PROTECTED] between plans and performance. http://www.ccil.org/~cowan --Emperor Hirohito, August 1945 _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
