On Mon, Sep 14, 2009 at 2:36 PM, Robert Bradshaw
<[email protected]> wrote:
>> Lisandro Dalcin wrote:
>>> I'm inclined for a warning... and that warning would not be generated
>>> in this case: "cdef char*cs = <bytes>s" , right?
>
> That could be bad, <bytes>s doesn't actually do a typecheck,
> especially if the bytes -> char* is eventually optimized. One should
> do <bytes?>s or <object>s (neither of which generate a warning).
>
Of course, <bytes> is as dangerous as any <some_py_type> cast (and
these casts defaulting to no-typecheck are the root of the evil)...
Still, as <some_py_type> casts are "blindly" honoured, I'm not sure if
we should special case this usage ...
>>
>>>> BTW, we shouldn't forget to adapt the .pxd files in Cython/Includes
>>>> accordingly, so that they return either "bytes" or "unicode", but
>>>> *never*
>>>> "str" (or "object", if we know it's a string type).
>>>
>>> Could you point to a couple of the C-API calls you are talking about?
>>
>> Things like the encoding functions, for example, that convert
>> between bytes
>> and unicode. Using str here would be wrong.
>>
>> Plus, changing the argument/return value types from "object" to the
>> right
>> types will allow Cython to do actual type checking.
>
> Often the type checking will be redundant with the type checking that
> happens inside the method, so I'm not so sure this is a good idea.
>
Perhaps it is time to generate Cython compile-time warning when
calling with an untyped arg value? Again, an explicit cast would
suppress the warning...
I mean, suppose this code:
cdef void foo(tuple t): # REMEMBER!!, foo() does not typecheck that
"t" is actually a tuple!!!
pass
cdef object a = 1
foo(a)
cdef list b = [1]
foo(b)
cdef tuple c = (1,)
foo(c)
1) When calling foo(a), we could emit a compile-time warning and
generate C code with runtime type-check... What's the point of duck
typing here iff foo() actually requires a tuple?
2) When calling foo(b), we could generate compile-time ERROR... What's
the point of letting this Cython-compile silently and making it fail
as runtime (like currently happens) ?
3) When calling foo(c), no warnigns and no C runtime type-check (as
currently is being done)
BTW, perhaps all this stuff is important enough as to start a new thread?
>>
>>>> And "str", "bytes" and "unicode" wouldn't be assignable to each
>>>> other,
>>>> right? Or would you also leave that to runtime?
>>>
>>> "bytes" <-> "unicode" (obviously?) would not be assignable, tough for
>>> the case of "bytes" <-> "str" or "str" <-> "unicode", we could
>>> generate similar Cython compile warnings as for the "[unsigned ]char
>>> *" conversions.
>>
>> Yes, I guess that's a similar case.
>
>
> I'd be inclined to outright disallow them, favoring requiring <bytes?
> > or <unicode?> or <object> cast. Currently, though, I can't think
> of any reason to type str/bytes/unicode variables at all.
>
In the future, you could optimize item access for "bytes" ?
Additionally, you could need to use typed variables because you want
to enforce automatic compile-time/runtime type-checking on assignement
or when calling functions ... Or you want to save the type-check
before call, as in foo(c) in my example above
--
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
