On Fri, Feb 10, 2012 at 23:56, Terry Reedy <tjre...@udel.edu> wrote: > On 2/10/2012 9:06 AM, Eli Bendersky wrote: > >> Whenever the Python core development team decides that a new package >> should be >> included into the standard library, but isn't entirely sure about whether >> the >> package's API is optimal, the package can be included and marked as >> "provisional". >> >> In the next minor release, the package may either be "graduated" into a >> normal >> "stable" state in the standard library, or be rejected and removed >> entirely >> from the Python source tree. > > > This could be interpreted as limiting provisional status to one release > cycle. I suggest that you add 'or continued as provisional'. In particular, > if the api *is* changed, another provisional period might be advisable. >
I think this was agreed upon when PEP 408 was discussed. Keeping a package provisional for too long is detrimental. Isn't a single release enough to decide that we want something or not? Keep in mind that many users won't touch the provisional packages in production code - we would like to make new parts of the stdlib functional as soon as possible. > >> The<X> package has been included in the standard library on a >> provisional basis. While major changes are not anticipated, as long as >> this notice remains in place, backwards incompatible changes are >> permitted if deemed necessary by the standard library developers. Such > > > 'as long as' implies no particular limit. Perhaps it should also? Eli _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com