On Sunday, October 23, 2011 5:14:17 PM UTC-4, Massimo Di Pierro wrote: > > I am not happy with extra. > > Currently we have three mechanisms to deal with "extra" fields. > table._extra, lazy virtual fields, links in grid/smartgrid. None of > them are undocumented in the book which means that for none of them we > promise backward compatibility. >
Right now, Row._extra is used to store the results of expressions (such as aggregate functions) in selects. The key used to store the expression is the expression itself, and I think that does have to remain backward compatible (i.e., row[expression] should retrieve the value of the expression returned by the select, regardless of the internal implementation). The question is whether it should be possible to do row[expression] = some_other_value (i.e., alter the value returned by the select). Currently it is not possible without hacking _extra. We could make it possible now, which would involve making an assignment to _extra in Row.__setitem__, and if the internal implementation of _extra fields in Row objects changes in the future, presumably we could just make sure the new implementation also allows such assignments. In other words, should the API allow assignments to expression results in Row objects (without reference to _extra), or should they remain read-only? Anthony
