Hi,
skipping through the patch, the changes seem to make sense in general. I'll
have to look through it a bit more thorough, but not today.
There are still a couple of places where you mix up strings (i.e. "bytes") and
unicode, like this:
------------------------
@@ -4309,7 +4336,11 @@ static int __Pyx_InitStrings(__Pyx_Strin
if (t->is_unicode) {
*t->p = PyUnicode_DecodeUTF8(t->s, t->n - 1, NULL);
} else {
+ #if PY_MAJOR_VERSION < 3
*t->p = PyString_FromStringAndSize(t->s, t->n - 1);
+ #else
+ *t->p = PyUnicode_FromStringAndSize(t->s, t->n - 1);
+ #endif
}
if (!*t->p)
return -1;
------------------------
The original code already handles unicode strings properly. For Py3 source
code, this has to be adapted in the Cython parser, not in the generated code
(i.e. parse "abc" as if it was u"abc" and b"abc" like "abc").
For current Cython code, this should just work unchanged - assuming you import
the string compatibility header file that #defines PyString_* as PyBytes_*.
Although I might want to see plain PyBytes_* calls generated here - not sure
yet.
Robert Bradshaw wrote:
> On May 8, 2008, at 8:33 AM, Lisandro Dalcin wrote:
>> - Finally, in the very clever part of traceback hackery, the call to
>> Py_CodeNew receives 'filenames' created with PyUnicode_AsString. I do
>> not know what the C preprocessor uses for enconding __FILE__ macro, it
>> its always ASCII, then all is fine, if not, the filesystem encoding
>> should be taken into account.
>
> I actually have no idea on this one--maybe there's some system call
> that can give this information? Stefan would probably know better
> than me.
Not sure either. I expect __FILE__ to be in the platform specific filesystem
encoding, so decoding to unicode can easily fail. We should store the UTF-8
encoded filename in the file so that it can be read instead of __FILE__.
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
