Stefan Behnel wrote:
> Dag Sverre Seljebotn, 13.04.2010 19:53:
>   
>> def some_operation(np.ndarray[double] a, np.ndarray[double] b,
>>   np.ndarray[double] out=None):
>>      if out is None:
>>          # no output buffer allocated; allocate one
>>          out = np.zeros_like(a)
>>      # computation, store result in out
>>      return out
>>     
>
> Hmm, I expect that you still want a and b to be non-None, don't you? So 
> assuming the proposed change, the above would have two bugs less and 
> otherwise run out-of-the-box.
>
>
>   
>> But there's also stuff like (making up the concrete example):
>>
>> def some_operation(np.ndarray values, np.ndarray jacobian):
>>      for k in ...:
>>          ...
>>          if jacobian is not None: # include it in the computation
>> ...
>>
>> These could all be handled by special-casing "arg=None", but I'd really,
>> really prefer choosing default values for arguments to be an orthogonal
>> issue to this.
>>     
>
> It's not completely orthogonal. If you use "np.ndarray jacobian=None", this 
> would get expanded to "ns.ndarray jacobian or None = None" (ugly as it 
> looks). However, in the above example, you'd have to be explicit and say 
> "np.ndarray jacobian or None", so your code would need to change. I 
> actually find that "or None" represents your intention very well, much 
> better than a plain "np.ndarray jacobian", which suggests that the argument 
> must be of type "np.ndarray" (especially when read in the autogenerated 
> docstring signature).
>   
Sure. You make good points.

But it can still be compared to Cython-with-control-flow-analysis, at 
which point I don't have to bother about "or None" or "not None" at all, 
meaning one less thing to think about (and learn!) with respect to pure 
Python. (I almost always write my code in Python first and only 
Cythonize if needed -- anything that can be kept the same between pure 
Python and Cython is good.)

So

1) I agree that in the absence of control flow analysis, requiring "or 
None" would be a much safer default behavior (no accidental segfaults). 
I certainly wouldn't have voted for today's semantics!

2) But, one presumably want control flow analysis eventually, and it 
seems bad to change behaviour twice, however minor the changes are 
(point at which exception is raised and its type).

Anyway, I think/hope we understand each other now. I'm all for Robert's 
suggestion of doing a compiler directive first and reviving this debate 
later.

Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to