* Cédric Krier [2011-05-12 11:03 +0200]:
On 12/05/11 10:25 +0200, Nicolas Évrard wrote:
>I too find myself in need of being able to add zero-priced invoice
>lines to invoices from time to time - which is not supported by
>tryton out-of-the-box.
>
>This makes me wonder if perhaps the whole required state machinery
>needs to be able to allow zero values on numeric fields to satisfy
>the requirement. I'm well aware of where this comes from: in
>python numeric values of zero evaluate to False. However, is a
>business context an explicit zero-amount is *not* the same as an
>unspecified amount, or in other words: 0 is not False, only False
>is False.
I am a strong supporter of this idea. We are discussing it right
now in fact. ;)
I will let Cédric explain his view on this subject but I think that
there is a difference between not having the information and
knowing that this information is 0.
We designed the application in the way that if you use a Float
(Integer, Numeric) field you are sure to have a float value (not
False). In other terms, all numeric value are "not null" in the
database. We did this because we thought it makes the development
easier and also because we did not find clear way in the client
interface to distinct both cases.
It makes it easier to (sometimes) use a wrong value. I would rather
having a ValueError because I am trying to use None in a numerical
context (and thus displaying a problem in my code) than silently pass
this error and having a computation with no meaning what so ever.
A way to make the distinction in the client would be an empty field
which means "I don't know".
I think the problem is bigger than that there is some kind of fields
where it will be possible to get a null value (which mean I don't
know) and others not.
Possible fields which can handle unknow values:
- Date/DateTime
- Integer/Float/Numeric (if we change it)
Others:
- Char/Text (no difference to display between '' and False/None)
- Many2One (not possible to have unknow value as False/None is no
link)
An empty values means either means that you don't know or that there
is no value. It is the same ambiguity there is currently with the 0 in
numeric fields.
- One2Many
- Many2Many
- Boolean
- Binary
- Selection (we need to put a empty value in the list)
But I am overall ok with this list.
There is many more type of fields where the "unknown" value is not
supported.
So for me, there is no problem to implement the "unknown" value in
Float fields but we need to keep the "not zero" mechanism and perhaps
keep the default value for required True.
I don't think this is a good idea. If a numeric field is required then
people have to input a value. There might be a good default defined in
the module but we don't know which value this is and we should not
choose one from one of the א0 value available in integer or (א1 if
we're talking about floats).
But as we already need to keep the "unknow" information about a many
other kind of fields into an other field. For me I don't see the need
to make this change. We can always fix the (not so often) cases of
"unknown" value for Float with a Boolean field that will show/hide
the field.
The unknown value is problematic only when the field is required. In
this case we must have a way to discriminate between "unkwown" values
and any other valid values, otherwise not knowing the value of a field
is not problem.
Choosing not to reduce the ambiguity is in my opinion more error prone
than the other way around
Remember:
import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do
it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
In the face of ambiguity, refuse the temptation to guess ...
Which is not what we are doing when 0 has two meaning.
--
Nicolas Évrard
B2CK SPRL
rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
E-mail/Jabber: [email protected]
Website: http://www.b2ck.com/
--
[email protected] mailing list
