Michael Gilfix wrote:
This would be very cool. Rather than having to go by python version numbers, which seem obscure, an application can declare its dependencies by module. Perhaps even some tool to determine an apps dependencies. (...)
while i agree to this basic idea i wanted to remind of the other point buried in my mail ... Changing the deprecation process to be based on *version numbers* rather than *uncertain future points in time*...
On Wed, May 29 @ 20:29, holger krekel wrote:
IMO Enforcing version numbers in standard libraries is a good idea.
Eventually, a good versioning scheme for the standard-lib with automated deprecation may be what is needed. Making the introduction of new (or deprecation of) features
a) by hand
b) by measures of 'x years', example from from PEP4: "The deprecation warning will be added to the module one year after Python 2.3 is released, and the module will be removed one year after that."
seems unreliable. How do you construct an if-statement for 'One year after 2.3 is released' if the current version is 2.2 <wink>.
Instead deprecating
a) (semi-) automatically
b) by saying '2.3 issues deprecation warning, 2.4 does not support it'.
seems much saner. Even a program can be teached to check this.
Am i the only one to find this an evident change for the good (tm) ? holger