On Tue, Sep 7, 2010 at 10:49 AM, Kay Hayen <[email protected]> wrote: > 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.
We have lots of this, thanks mostly to Stefan's great work to support the Py_UNICODE type and its optimized interaction with unicode strings. Python semantics for faster execution is not the only goal--we also want to easily use and wrap existing C libraries. >>> 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. Because some of us prefer coding in Python :). But there's a lot of useful code out there in C. This is like asking, "if you want to have faster execution, 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. Creating a (logical or actual) Python string just to convert it to a C string for use with foreign code is wasted overhead compared to being able to use the C literal directly. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
