Notset: A Do-Not-Care value for Python

The kwargs form is a more obvious API. When your users grow more fields -- email, registration date, avatar -- this code will be reusable, whereas a function with a signature will need its arguments changed whenever the database schema changes.

The three-valued logic of set-to-something, set-to-None, don't-set is perfectly adequately captured by a dictionary. You're introducing an application-specific concept (the NotSet value) when a built-in concept (a dictionary) works just fine.

This is one of the features of Scala I like; explicit types for Option/Some/None in the core language and standard API. It's generally used for return types (ex: a hashmap 'get' will have a return type of Option[ValueType] and return either Some[ValueType] or None) but you can use it for function parameters as well.

  scala> def foo(name:Option[String] = None, age:Option[Int] = None) = {
       |     println("==========")
       |     if( name.isDefined )
       |         println("Name: " + name.get)
       |     if( age.isDefined )
       |         println("Age: " + age.get)
       |     println("==========")
       | }
  foo: (name: Option[String], age: Option[Int])Unit
  
  scala> foo()
  ==========
  ==========

  scala> foo(Some("Alice"))
  ==========
  Name: Alice
  ==========
  
  scala> foo(age = Some(10))
  ==========
  Age: 10
  ==========

Plus with some implicit syntactic sugar...

  scala> implicit def strToSome(s:String) = Some(s)
  strToSome: (s: String)Some[String]

  scala> implicit def intToSome(i:Int) = Some(i)
  intToSome: (i: Int)Some[Int]
 
  scala> foo("Alice")
  ==========
  Name: Alice
  ==========
  
  scala> foo(name = "Alice")
  ==========
  Name: Alice
  ==========
  
  scala> foo(age = 10)
  ==========
  Age: 10
  ==========
  
  scala> foo(name = "Alice", age = 10)
  ==========
  Name: Alice
  Age: 10
  ==========

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

Interesting. I love the idea of not having to import an external library, but much like the `NotImplementedError` suggestion, it overloads a value that already has a specific meaning, in this case related to slice-notation.

I'd worry that this approach could end up being even more confusing.

To my ear, this does sound the best. Thanks for the suggestion!