RetroSearch Browse

Fri Jun 19 10:23:01 CEST 2009 · https://mail.python.org/pipermail/python-dev/2009-June/090122.html

Benjamin Peterson <benjamin <at> python.org> writes:
> 
> This policy applys to all public APIs.

applies?

> * 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?

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

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

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

[Python-Dev] draft pep: backwards compatibility