Steven D'Aprano <steve@...> writes:
On Thu, Jan 30, 2014 at 08:58:20PM -0800, Larry Hastings wrote:
The statistics module isn't marked as provisional. So the semantics that ship with 3.4 are going to be set in stone. Changing them later simply won't be an option--that will break code. If you want to treat Counter objects differently in the future than you do now, then I agree with Wolfgang: the best course of action would be to add an exception now. But again I'll defer to your judgment about what's best for your module.
Hmmm. Well, that's a much stronger promise of backward compatibility than I would have expected. The fact that (say) variance works with a dict is a pure accident of implementation, not advertised or promised in any way. But I'll accept your ruling. I want to reserve the right to add special handling of mappings in the future. In order of preference (highest to least) I'd like to:
1) Put a note in the documentation that handling of mappings is subject to change;
2) As above, plus raise warning.warn(); or
3) Raise an exception (this one only if you insist).
I thought about this further and, yes, I guess at least point 1) is essential and even if that means marking the module as provisional it is a bit sad, but worth it. Mappings may be an excellent way of specifying frequencies and weights in an elegant way. You could use them to calculate weighted means and variances, and even to specify variable interval widths for median_grouped to calculate a weighted median as defined here: http://en.wikipedia.org/wiki/Weighted_median Most of this is quite easy to code I guess and it would be a pity to deprive yourself of this possibility because people start passing mappings now and start relying on iteration happening over keys only. I agree with Larry that once this happens, it will be hard to change the behavior even in 3.5. Best, Wolfgang