undefined | Better HN

0 pointsj-kidd13y ago0 comments

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

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

0 comments

1 comments · 1 top-level

shmeedogg13y 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 / k navigate · click thread line to collapse