[Zope3-dev] bug setting value to None via edit form

[Garrett Smith]

Steve Alexander wrote:
> In general, I want to consider an empty string to be "missing". The
> way I generally write my Python classes that have variables that are
> strings is to start with the strings initialized to '', not to None.
> In most cases, '' is a more appropriate way to say "no value present"
> than using None. The only time I'd want to use a value of None for
> something that is usually a string is when '' is valid and meaningful
> data that has been set for that string.

This is a classic example of 3-value logic: missing, empty, and
non-empty. This is like storing boolean values in a database -- there
are three possible values: missing, false, and true.

An empty string is not missing/unknown -- it's known and zero-length.

> I'd like the Schema and Fields and Widgets to allow me to write Python
> classes in the way that works for me, and not make me use None where I
> would not normally use it.

You can certainly abstract the concept of 'missing' away from None, but
I think this is going to lead to confusion. I'd keep None as 'missing'
and designate something else as your 'special value'.

>=20
> 2: Interface fields
>=20
> Consider a field that represents a chosen interface. In the
> zope.interface system, None means "the most general interface". Right
> now, an Interface field cannot properly represent its special use of
> the None value, and it cannot properly represent a "missing
> selection".=20

No one's forcing you to interpret None as "the most general interface"
-- that's a design decision. Personally, I'd use something like
zope.interface.Interface, or some explicit marker. None should be
reserved for the 'missing value'.

> If I could define a special "missing value" for an Interface field,
> then I could use None as a legitimate value, and be unambiguous about
> when no value has been set.

You can just as easily define a special "other value" to serve your
purpose (e.g. default value, most generic value, etc.) and leave None as
'missing'.

>> If a value is None, I'd say it's missing. If that's a legtimate
>> value, then the field's not required.
>=20
> If None is a legitimate value then the field is not required? I
> disagree. If None is a legitimate value then it should be offered for
> selection along with all the other legitimate values.
> This should not interfere with whether or not a field is required.
> That would be messy.

How do you know when a value is missing? Based on the proposed field
design, you'd compare the value to

  field.missing_value

But this is going out of your way to allow None to have some special
meaning. Instead, keep None as missing and designate something else as
your special value. This special value can be provided in your
vocabulary or allowed_values list and interpreted as needed.=20
=20
>> I.e. if I set something to None, I expect it to stay None, else
>> raise an error...at least in the case of setting field values.
>>=20
>> I suspect we'll end up seeing field.missing_value =3D None in every
>> case, with perhaps some very funky exceptions.
>=20
> Of course field.missing_value will be None by default. As it will be
> the default, you won't ever see it.

I'm going to argue that if missing_value is anything other than None,
you have a bad schema design -- there's a better way to handle the
requirements.

It might be worth going through some use cases and playing around with
some design alternatives.

> Have I provided a convincing case?

I'm interested in your response to my points. Of course, I'm as open
minded as the next fella, but remain unconvinced at this point :-)=20

 -- Garrett