Dag Sverre Seljebotn wrote:
> Stefan Behnel wrote:
>> Dag Sverre Seljebotn wrote:
>>> A way to get around this would be to split generate_result_code. So
>>> mainly my proposal, but with this modification:
>>>
>>> self.subexpr.preparation_code(code)
>>> tmp = code.funcstate.allocate_temp(...)
>>> self.subexpr.store_result_code(tmp, code)
>> That's something I thought about, too. Most of the time, within an
>> expression, all you really want is to say "do whatever it takes to
>> calculate the result, and then put it *here*", where 'here' may be a temp
>> or a name.
>>
>> How would the DECREF handling work for the target in that case? If it's a
>> temp, I'd expect it to be empty in any case, but if it's a variable name,
>> it needs a DECREF-after-INCREF. Or would the parent always hand in a temp
>> and always handle variables itself?
>>
>> If we call this directly, we could also pass keyword arguments like
>> "target_needs_decref" and "make_owned_reference".
>
> I don't like those keywords as such, responsibility should be in parent.
> I think a can_raise_exception flag on the node gets us a long way.
Sorry!, I didn't fully realize what you were asking. Partly because I
couldn't think of situations where the subexpr would not want to incref,
but of course there are plenty of examples of that (like "print x").
So yes, you'd need the "needs_target" variable, and if that is set to
False, there would be another protocol.
Finally if something both needs a target, but is able to return a
non-incref-ed value (cannot think of any examples -- perhaps some buffer
code), then I'd prefer for store_result_code to return some status about
whether it returns an incref-ed result or non-incref-ed one. So that
you'd do something like this for "print x":
if self.operand.needs_target:
# allocate tmp etc
needs_decref = self.operand.store_result_code(tmp, code)
# output code to print tmp
if needs_decref:
# decref tmp
# release tmp
else:
# code to print self.operand.result() directly
Perhaps this calls for a wiki page with these examples etc. before any
implementation work is done.
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
