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