> First, unexpected arguments are immediately caught since they throw a TypeError. > Without this, you either have to manually check for unexpected keys (proba

> First, unexpected arguments are immediately caught since they throw a TypeError. > Without this, you either have to manually check for unexpected keys (probably doing a set difference with `allowed_keys` or something) or you just silently pass through unrecognized attributes, probably causing strange behavior later on. The default constructor for SQLAlchemy declarative base does a simple check for unexpected keys, and it has served me well: https://bitbucket.org/sqlalchemy/sqlalchemy/src/acbaeb1acb7d/lib/sqlalchemy/ext/declarative/base.py?at=default#cl-406 https://bitbucket.org/sqlalchemy/sqlalchemy/src/acbaeb1acb7d... > Second, you are forced to say explicitly which attributes are modifiable. To draw from the 'person' example, `name` and `age` might be modifiable, but `admin` might be protected. That would be made abundantly clear by `update(person, name=NotSet, age=NotSet)`, but less so, by `update(person, attrs)` or `update(person, kwargs)`. Whether a field is modifiable is often determined by the current user's access level and the current state of the object. So, putting such restriction at the function definition may have made things too rigid.