Raphael, But i have a concern, I remember Guido saying something related to this in the python 3000 change meeting.... I am still searching for the info...
If this is going to be removed in a future version we need to find a workaround right away.... Cheers! Sharoon 2009/12/8 Raphaël Valyi <[email protected]> > 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 <[email protected]> > > 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 <[email protected]> >> >> >>>> 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 >> > > -- Sharoon Thomas Business Analyst & ERP Consultant http://bit.ly/5FAJKU
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
