On Wed, 13 Aug 2008, Dag Sverre Seljebotn wrote:
> Robert Bradshaw wrote:
>> On Aug 6, 2008, at 9:35 AM, Dag Sverre Seljebotn wrote:
>>
>>> Robert Bradshaw wrote:
>>>> On Aug 6, 2008, at 1:49 AM, Dag Sverre Seljebotn wrote:
>>>>
>>>>> Obviously my past efforts weren't good enough:
>>>>>
>>>>> DEF MYLEN = 3
>>>>> c = sizeof(MyStruct[MYLEN])
>>>>>
>>>>> So it seems that the parser can never discern the current syntax
>>>>> (MYLEN
>>>>> could have been a typedef and MyStruct and extension type, and
>>>>> then it
>>>>> would have been buffer syntax).
>>>>>
>>>>> So if keeping the current syntax, I seem to have no choice but to
>>>>> create
>>>>> a TrailingBracketTypeNode and delay the decision until type
>>>>> analysis.
>>>>> This takes some work, and adds complexity, so I want to be sure
>>>>> that it
>>>>> is needed first.
>>>> I'm not understanding why we need to introduce a new node here, why
>>>> not let the sizeof operator be OK with index nodes?
>>> Yes, if you can guarantee me that the sizeof operator is the only
>>> place
>>> this happens, and that the sizeof name cannot ever be overriden and so
>>> on, I could do that.
>>>
>>> The thing is, I've been bitten so many times by wrong assumptions
>>> by now
>>> that I'd rather use a new rule controlling the thing: If [] is used
>>> on a
>>> pyobject, then it is buffer, on a native type, then array. But then I
>>> need to defer the resolution of what the [] means until type analysis
>>> time.
>>
>> I think this makes sense.
>
> To backtrack to this discussion:
>
> - Apparently, sizeof will always be sizeof -- it is resolved in the
> parser by string comparison and p_sizeof is called (it is considered an
> operator, like in C).
>
> - Also, a flag nonempty ("context requires that some variable name is
> present") is passed to the type parsing code, which is set to True in
> the kind of situations Lisandro Dalcin reported.
>
> So the fix was really easy, in the parser only, and I didn't attempt the
> much more complicated solution outlined earlier.
Excelent.
> (BTW, an assumption made by this is that we don't allow
>
> cdef external_func(object[int])
>
> I.e. if exporting a function using a buffer, you must do
>
> pxd file:
> cdef myfunc(object)
>
> pyx file:
> cdef myfunc(object[int] param): ...
>
> This makes kind of sense as the caller knows nothing about the buffer
> access anyway, it's an implementation shorthand. If it is too
> inconvenient we could work around it later but the changes are quite
> extensive and I'd rather do more useful stuff. BTW this was already
> explictly disallowed in existing buffer code, so only the error message
> changes by this.)
I think this fine.
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
