4 ms·

> whereas a function with a signature will need its arguments changed whenever the database schema changes. True there is some work in keeping the two synchron

> whereas a function with a signature will need its arguments changed whenever the database schema changes. True there is some work in keeping the two synchronized, but there are benefits. 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. 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)`. A clear docstring would help, but I'd prefer to have the code just fail-fast on this unexpected input.

j-kidd 14y ago
> 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.
- shmeedogg 14y ago
  > 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. True, let me try to clarify. There might be some attributes like `admin` that you don't want twiddled via the `update` method but rather mutated via a setter function. In this case, the signature of the `update` function would be helping to indicate that. (A better example might be the attribute `active` with two methods called `activate` and `deactivate` that send emails and what-not.)

j-kidd 14y ago

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

shmeedogg 14y ago
> 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. True, let me try to clarify. There might be some attributes like `admin` that you don't want twiddled via the `update` method but rather mutated via a setter function. In this case, the signature of the `update` function would be helping to indicate that. (A better example might be the attribute `active` with two methods called `activate` and `deactivate` that send emails and what-not.)