On Feb 27, 2009, at 3:59 AM, Lisandro Dalcin wrote:
> On Fri, Feb 27, 2009 at 12:23 AM, Robert Bradshaw
> <[email protected]> wrote:
>> On Feb 26, 2009, at 5:05 PM, Lisandro Dalcin wrote:
>>
>>> On Thu, Feb 26, 2009 at 9:21 PM, Robert Bradshaw
>>> <[email protected]> wrote:
>>>> It mostly looks good to me. To summarize, you basically made a
>>>> macro
>>>> that's the function for converting to/from the various types, and
>>>> applied that everywhere, right?
>>>
>>> Yes, though this is preliminary...
>>>
>>> Perhaps I should make Cython emit the code directly?
>>
>> I think that's what was there originally. I'm OK with it either way.
>>
>
> IMHO, the only benefit of macro-based would be to save disk space...
> These functions are generated for every ext module.
OK, makes sense. It might actually be nice to have a flag which uses
a (common) .h file for lots of the boilerplate code. Using .h files
to share declarations across modules could save a lot of space too
(and probably make compilation faster when you cimport a lot of
stuff, like Sage).
>
>>> Moreover, I need to review the Py_ssize_t/size_t converters..
>>
>> For Py_ssize_t we should be using PyNumber_Index--probably should use
>> the same for size_t.
>>
>
> OK.. that was what I meant...
>
>>> However, I would like to point a gotcha... The some converters use
>>> PyNumber_{Int|Long} ... This is good as they would exercise general
>>> Python types implementing the special methods "__int__()" or
>>> "__long__()" ... However, they will also accept strings, and even
>>> (char) buffer objects !!!! What to do here ?? This makes me feel
>>> a bit
>>> uncomfortable, seems too much ...
>>
>> I'm confused, I don't think PyNumber_(Int|Long) accept strings, etc.
>> They only accept objects that have implemented the __int__ method.
>> Note that I wrote an inline function to extract it directly if it's a
>> Python int (as this is an extremely common case).
>
> Unfortunately, you are wrong. Plese check PyNumber_(Int|Long)
> implementation at core CPython sources...
You're right, in that case we should definitely be avoiding them
PyInt_AsLong looks like the right thing to use here.
> Anyway, I'll try first to make this work right, signaling overflows
> where appropiate...
>
> IMHO, we cannot use things like PyInt_AsUnsignedLongMask()... Do
> you agree here?
I'd certainly like to avoid this.
> Next we can discuss how to optimize this....
As long as we don't slow down the (very common) Python int -> int/
long code, I'm OK with deferring optimization.
>
> BTW, can I asume that if I write
>
> if ( sizeof(c_type) < sizeof(long) ) {
>
> } else if ( sizeof(c_type) == sizeof(long) ) {
>
> } else {
>
> }
>
> then C compiler will be smart enough to eliminate the branching? (I
> know, I have to learn how to read disasemblies....)
Yes, the C compiler will kill all but the correct branch.
> I'm thinking on extending all this to extern ctypedef'ed integral,
> this way Cython will stop using the base-type's longness of the
> typedef.
Yes, for sure we should be doing this.
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
