A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2009-June/090135.html below:

[Python-Dev] draft pep: backwards compatibility

[Python-Dev] draft pep: backwards compatibility [Python-Dev] draft pep: backwards compatibilityBenjamin Peterson benjamin at python.org
Fri Jun 19 15:56:12 CEST 2009
2009/6/19 Antoine Pitrou <solipsis at pitrou.net>:
> Benjamin Peterson <benjamin <at> python.org> writes:
>>
>> This policy applys to all public APIs.
>
> applies?

Yes, thanks.
>
>> * The behavior of an API *must* not change between any two consecutive
>> releases.
>>
>> * A feature cannot be removed without notice between any two consecutive
>>   releases.
>
> By induction, this would mean no API could change and no feature could be
> removed without notice between any N consecutive releases. Do you really mean
> it?

No, I'll reword.

>
>> * Addition of a feature which breaks 3rd party libraries or applications
>> should
>>   have a large benefit to breakage ratio, and/or the incompatibility should
>> be
>>   trival to fix in broken code.
>
> There is always the possibility that a new feature breaks existing code, for
> example because it relies on a similarly named attribute, or on some obscure
> internal condition. I think this should be qualified so that it only applies
> when e.g. a fair number of third-party apps or libraries are broken.

I add a few examples.



-- 
Regards,
Benjamin
More information about the Python-Dev mailing list

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