4 ms·
The problem with this idea, or rather its implementation, is that it's just a matter of time until someone uses NotSet as a legitimate value assigned to a varia
by reinhardt 14y ago
The problem with this idea, or rather its implementation, is that it's just a matter of time until someone uses NotSet as a legitimate value assigned to a variable/attribute, just like None is today. At this point someone will introduce a new singleton, "NotSetIReallyMeanItThisTime", and so on and so forth. It never ends.
The only way this might work is if NotSet (or whatever it's called) is a keyword and it is only allowed in (a) function signatures and (b) comparison with `is` and `is not`; everything else throws a syntax error.
- sltkr 14y ago> it's just a matter of time until someone uses NotSet as a legitimate value assigned to a variable/attribute, just like None is today. No, because the NotSet value (unlike None!) isn't global; it's private to the package (or even class) that uses it. Callers never need to reference it, and never should. (Python doesn't actually enforce access restrictions but using undocumented variables/attributes is frowned upon; if you do that, your code deserves to break!) If you really want to hide it (to prevent mistakes), you could write something like this: NotSet = object() def isset(val, magic=NotSet): return val is magic def update(person, name=NotSet, age=NotSet): if isset(name): person.name = name if isset(age): person.age = age del NotSet update(None,name='foo') update(None,age=27) (I'm sure there are still ways to get to the NotSet value if you really want to, but not by accident, and if you abuse this, you deserve all the problems you'll receive.)