On Tue, Jun 25, 2002 at 10:56:47AM +0200, Peter Funk wrote:
"""This module defines names for all object types that are used by the standard Python interpreter, [...] It is safe to use "from types import *" -- the module does not export any names besides the ones listed here. New names exported by future versions of this module will all end in "Type". """
Thanks for pointing this out!
It would be possible to change the documentation of types module now and start telling users that the Python development team made up their mind. That would open up the possibility to really deprecate the module or change the type names later (but only much much later!), without causing the effect I called "version fatigue" lately here.
I don't understand exactly what you are suggesting here. Would you care to explain it more clearly?
A recent thread here on python-dev came to the conclusion to "silently deprecate" the standard library modules 'string' and 'types'. This silent deprecation nevertheless means, that these modules will go away at some future point in time. I don't like this decision, but I understand the reasoning and can now only hope, that this point in time lies very very far away in the future.
It is a reasonable expection, that source code written for a certain version of a serious programming language remains valid for a *LONG* period of time. Backward compatibility is absolutely essential.
What I was trying to suggest is to change the documentation of the Python language and library as early as possible, so that programmers get a reasonable chance to become familar with any upcoming new situation.
Unfortunately this will not help for software, which has already been written and is in production. If in 2004 certain Python programs written in 2000 or earlier would start raising ImportError exceptions on 'from types import *' after upgrading to a new system which may come with the latest version of Python, this will certainly cause damage.