[Python-Dev] Re: Deprecation

[Michael Gilfix]

  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.  These dependencies can then be checked using the
current version in a perl-esque regression test style to determine
how well the current version meets the applications needs (I say
this because some code may not be run normally but require more
advanced features - this could also allow for some very interesting
approaches to modularity and using available python features in larger
applications). It would then be very easy to determine the cause
of breakage and/or the need of the application.

                      -- Mike

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.
> 
> The more intransparent the versioning/deprecation scheme
> the harder it is to handle and the more people
> will scream at every deprecation-proposal.
> 
> deprecated-4223-seconds-after-7th-reply'ly yours, holger

-- 
Michael Gilfix
mgilfix@eecs.tufts.edu

For my gpg public key:
http://www.eecs.tufts.edu/~mgilfix/contact.html