3.5b: Python optional value mapping questions

in Help Center
First question: Regarding Ice.Unset, one checks if a data member is unset using ==. My question goes to PEP-8 which states that:
Is Ice.Unset a singleton? Is it safe to compare against Ice.Unset with 'is' instead of '=='? Should we be using 'is' instead of '=='? From a code style point of view, that seems to be preferred and could be a little faster.
Second question: Why wasn't None used instead of introducing Ice.Unset?
Thanks,
Blair
Comparisons to singletons like None should always be done with is or is not, never the equality operators.
Is Ice.Unset a singleton? Is it safe to compare against Ice.Unset with 'is' instead of '=='? Should we be using 'is' instead of '=='? From a code style point of view, that seems to be preferred and could be a little faster.
Second question: Why wasn't None used instead of introducing Ice.Unset?
Thanks,
Blair
0
Comments
Unset is a singleton, so you should use is for comparisons.
We cannot use None as the "marker" value for optional values because None is already a legal value for non-optional types, such as strings, sequences, dictionaries, and classes, and that leads to ambiguities. For example, if you pass None as the value of an optional class argument, did you mean that Ice should pass the optional set to a nil value, or did you mean that the optional is unset?
We use Unset to avoid such ambiguities.
Regards,
Mark
Before Ice 3.5:
Ice 3.5:
The "wrong" case is the naive porting of the old code, where the old code follows the PEP8-recommended technique of using a list in boolean context to test if it is empty. My expectation in Ice 3.5 is that Ice.Unset would also evaluate to false in boolean context. But because of an implementation detail, Ice.Unset is an instance of 'object' and evaluates true in boolean context.
I understand that using the 'is' operator is the only foolproof way of checking if a value is unset, and that many "set" values would evaluate to false in a boolean context. However, I still feel it would be highly convenient if Ice.Unset behaved more like None and evaluated false in boolean context.
In our organization we are considering modifying Ice to change this behavior. We are wondering if you are interested in sharing your opinion on this, if you have any plans to change this behavior, or if you would be interested in a patch from us.
The proposed change is to change Ice.Unset to be an instance of a new custom type that implements __nonzero__ to return False.