On Apr 16, 2008, at 1:17 PM, Dag Sverre Seljebotn wrote:
>> I think this significantly impacts usability. For example, if I have
>> a function
>>
>> def foo(char* x):
>> ...
>>
> For this specific example, one could hypothetically do something like
>
> def foo(utf8charbuf x):
> ...
>
> (or more generally encodedcharbuf("utf-8"), but one could typedef).
> The
> caller shouldn't notice.
>
> I.e., such a new type would then automatically coerce unicode <->
> char*
> using the encoding indicated by the type. Behaves exactly like
> char* in
> every situation, except that it can be assigned to/from a Python
> unicode
> object and knows what to do (compile-time). One could even be able to
> define external functions using such a type, and it would be
> understood
> that the external function took a char buffer.
>
> I believe most usecases could be made practical and easy in this
> manner;
> while keeping what goes on very explicit. But I see that a) being able
> to use the name "char*" will be much more friendly to C users, and
> b) it
> doesn't help with backwards compatability.
I think both (a) and (b) are non-negligible issues, especially in the
context of wrapping existing C libraries. Having to learn a new type
like utf8charbuf, (which it masks the pointer nature of it as well,
is its memory managed?) isn't desirable, especially if one is casting
everywhere back between any object and char*. It also creates the
expectation that all different kinds of encodings need to be
supported with their own special type, and I don't think we want
anything as heavy as a class.
The more basic question is if we can transparently support unicode in
char*, why not? Even for non-English speakers, the majority of
strings being passed around will be ASCII.
> (The class above could potentially be implemented in a pxd using
> some of
> the same (hypothetical/planned) features as in my NumPy project
> proposal. Though native Cython support wouldn't hurt either for such a
> feature.)
>
> --
> Dag Sverre
>
> _______________________________________________
> Cython-dev mailing list
> [email protected]
> http://codespeak.net/mailman/listinfo/cython-dev
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
