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

[Steve Alexander]

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

That's depends on the application. Perhaps that is the case in your 
application. It is not the case in some of mine.


>>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'.

None doesn't universally mean "missing" in Python programs in general.
It depends on the application. I think schemas and fields and widgets 
should not force applications to use None to indicate "missing".


>>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". 
> 
> 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'.

In the zope.interface package, None is more general than Interface.

Why should Fields force Python code to consider None to be "a field's 
notion of missing"? I should not need to consider the limitations of 
schema and fields when designing a system. I think it would look pretty 
poor if the design guidelines said "If you use None to mean anything 
other 'missing value', your objects will not work properly with Zope's 
schema system.".


Considering the zope.interface package, we have a general pattern: I 
want to use a package that is independent of Zope 3 (zope.interface) 
with the Zope 3 framework, and I want to present data types from this 
independent package using schemas fields and widgets.
Yet, I find I cannot do so because of a requirement that fields make: 
None is a special value for Fields.

I think schema, fields and widgets should be flexible enough so that 
they can present third-party packages without imposing unnecessary 
conditions on those packages.


>>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'.

Why should I have to change existing software when I decide I want to 
use fields and widgets to present it?

What if we're not talking about zope.interface but about some other 
third-party package? Are you suggesting I should contact the author of 
this package and tell them that they have made an incorrect design 
decision by using None to mean something other than "the value is missing" ?

--
Steve Alexander