On 2 February 2014 02:11, Terry Reedy <tjreedy at udel.edu> wrote:
>> example, sum({1: 100, 2: 200}) returns 3. If one wanted to reserve the
>> opportunity to handle mappings specifically in the future, without being
>> locked in by backwards-compatibility, how should one handle it?
>>
>> a) document that behaviour with mappings is unsupported and may
>> change in the future;
>
>
> I think the doc should in any case specify the proper domain. In this case,
> I think it should exclude mappings: 'non-empty non-mapping iterable of
> numbers', or 'an iterable of numbers that is neither empty nor a mapping'.
> That makes the behavior at best undefined and subject to change. There
> should also be a caveat about mixing types, especially Decimals, if not one
> already. Perhaps rewrite the above as 'an iterable that is neither empty nor
> a mapping of numbers that are mutually summable'.
Generally, my view would be that users should not rely on undocumented
behaviour. But as documentation is sometimes less than 100% precise,
it's worth in a case like this, documenting that a particular
behaviour is not defined (yet). Then, picking and implementing the
desired behaviour will be a new feature and hence totally acceptable.
Changing the way mappings are treated in a bugfix release (as opposed
to a feature release) is unlikely to be acceptable no matter how you
do it, as there's no way you can reasonably deliberately implement one
behaviour now and claim it's a bug later :-)
Paul
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4