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

[Casey Duncan]

On Monday 14 July 2003 12:33 pm, Steve Alexander wrote:
[snip]
> >>2: Interface fields
> >>
> >>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
> >=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'.
>=20
> In the zope.interface package, None is more general than Interface.
>=20
> Why should Fields force Python code to consider None to be "a field's=20
> notion of missing"? I should not need to consider the limitations of=20
> schema and fields when designing a system. I think it would look pretty=
=20
> poor if the design guidelines said "If you use None to mean anything=20
> other 'missing value', your objects will not work properly with Zope's=20
> schema system.".

Fields are data descriptors. It seems to me that they *should* determine =
what=20
the missing value is.
=20
> Considering the zope.interface package, we have a general pattern: I=20
> want to use a package that is independent of Zope 3 (zope.interface)=20
> with the Zope 3 framework, and I want to present data types from this=20
> independent package using schemas fields and widgets.
> Yet, I find I cannot do so because of a requirement that fields make:=20
> None is a special value for Fields.

Perhaps fields need to be smarter than this. Perhaps there should be a si=
mple=20
way to override the missing value.
=20
> I think schema, fields and widgets should be flexible enough so that=20
> they can present third-party packages without imposing unnecessary=20
> conditions on those packages.

However, if fields cannot impose data restrictions, and allow for some=20
predictability, then their value is dubious. However, if the missing valu=
e is=20
configurable and you could ask the field what it is, then this might be=20
enough.

I agree that None may, in some cases, be a legitimate value that does not=
=20
imply "missing". However, it is convenient in the common case. Therefore =
to=20
me it makes sense to improve field such that the missing value can be=20
overridden in cases where None is not the missing value.

-Casey