Steven Lott wrote:
The numbering scheme should cover this need. After all, Wirth had a series of numbered versions for Modula (<empty>, 2, 3).
I think the individual modules may need explicit version numbering, also. I find 15 of 158 .py files in my release of the library have __version__ numbers.
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