Robert Bradshaw wrote: > On Dec 1, 2009, at 11:01 AM, Christopher Barker wrote: >>>> we need a Cython type: >>>> >>>> ANSI_string (not that that's what it should be called)
>> the idea is that this would be used >> explicitly for "text", not data -- so the user would not want to get >> bytes back. > Yes, this is the case that I'm thinking of as well. I wasn't seeing > how a new type would fix the > > cdef char* s = ... > return do you mean "return s"? but anyway -- the point is that when you do: cdef char* s you've declared a char* only -- and that could be anything, so you're right, the only sane thing to return to python would be a bytes object. Maybe I'm confused about what's possible (I've only done a tiny bit of "real work" with Cython), but what I had in mid was that you'd do: cdef ansi_str s = ... and s would be a char*, but you'd have told Cython that you are using it as and ansi string, and thus: return s would return a python unicode object *using an ansi encoding -- I'm not sure how'd you'd tell Cython what encoding to use, though. Lisandro Dalcin wrote: > Suppose Cython could be enhanced by a mechanism where users can setup > mappings C->Py and Py->C for any type using a user-provided cdef > functions or even external functions. Then we should be able to do: > > cdef current_encoding = "latin-1" Maybe something like this would solve it -- I do like the general idea. > At some point in the future when Danilo's C++ support is merged, and > some C/C++ header parser is available, Cython typemaps would enable > AUTOMATIC wrapper generation, pretty much like SWIG does right now. And that would be fabulous! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
