Am 07.09.2010 18:44, schrieb Stefan Behnel: > Kay Hayen, 07.09.2010 18:24: >> Am 07.09.2010 10:27, schrieb Stefan Behnel: >>> Kay Hayen, 07.09.2010 00:15: >>>> I may be misunderstanding people >>>> because of my different goal to stay close to CPython. >>> >>> You may want to keep the level of unnecessary FUD down, especially on this >>> list. Cython has very good and seamless support for Unicode and CPython's >>> string type semantics. >> >> What you quoted was not a statement about Cython, but about me. > > Hmm, guess I misunderstood you then. Sorry.[...]
My goals are independent of the tool. So it is true for Cython as much as for any other tool. I am interested in having Python semantics and faster execution. I heard that Cython is a tool for that. Is it not? I would therefore like to point out solutions that preserve Python semantics, but instead hand it over to C as well. >> Therefore I might not understand that the discussion is about "Cython C >> string literals", because I don't understand what that should be and why >> it should be technically. > > It's what you get when, for example, you write a string literal as input to > a C function that accepts a char*. It's basically a Python bytes string > mapped into C space, or an "unboxed" bytes string. Cython does these things > in order to talk to foreign code. From my point of view, if you want to call C function with C literals, why not use C in the first place. From a bindings point of view, I don't see the problem with the user getting a "pchar_t *" and him (or the compilers on the fly) to convert it as required. Yours, Kay _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
