openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

Hey Sharoon,

shame on me, you are absolutely right, I did the test in a Python console
with "and" instead of "or", that's why I believed "" was casted as True by
mistake.
Usually I'm disappointed by Python expression casting vs Ruby. Example of
this are: table[out_fo_range_index] is casted to Nil (None) in Ruby which is
more handy than a fucking exception.
But I should admit that here Python got it right too with "" so it does just
what you mean and your proposal seems good on all points so far.

Raphaël Valyi
http://www.akretion.com

2009/12/8 Sharoon Thomas <sharoonthomas@xxxxxxxxxxxx>

> Hi Raphael,
>
> It wouldnt break the existing behavioour because by default it should
> continue to return False.
>
> My point was we should be able to specify in the context what should be the
> null value. If theres no null value specified, then work like how it works
> now. (Return False)
>
> Also the said problem (about  [[ product.price_extra or "No extra cost!"
> ]]) doesnt exist because "" is treated as False by python.
> Example:
>
> >>> price_extra = ""
> >>> print (price_extra or "No extra cost")
> No extra cost
>
> For python {},[],"",'' are all False type in logical operations
>
>
>
> 2009/12/8 Raphaël Valyi <rvalyi@xxxxxxxxx>
>
>
>>> The generic issue IMHO is the open erp browse object/class which has two
>>> problems:
>>>
>>>    1. raises an error when the expression is wrong eg.
>>>    user.partner_id.name (if partner id doesnt exist or is false it
>>>    returns err so we are forced to write user.partner_id and
>>>    user.partner_id.name)
>>>    2. if a field is empty it return False, it should be possible to
>>>    selectively change what should be the return value if database/computed
>>>    value is null. So if we can selectively opt to choose like
>>>    self.pool.get('model').browse(cr,uid,ids,context={'null_value' = ''}) and if
>>>    browse object respects this, there should be no problem.
>>>
>>> Sharoon, nice suggestion, and I agree for 1). However, for 2), returning
>> "" instead of False would break a lot commonly used boolean expressions.
>> For instance [[ product.price_extra or "No extra cost!" ]] would return ""
>> rather than "No extra cost!" if we do what you propose. So I don't think
>> this would be more user friendly than the current awkwardness.
>> What I propose for 2) is a bit different. I propose that the expression
>> evaluator, change False to "" but only at the expression level (once the
>> whole [[ ]] block has been evaluated), not at the object attribute level
>> which would screw up boolean expressions.
>>
>> Do you agree on this? Do you see any way of doing it?
>>
>> Raphaël Valyi
>> http://www.akretion.com
>>
>
>
>
> --
> Sharoon Thomas
> Business Analyst & ERP Consultant
> http://bit.ly/5FAJKU
>