Oren Tirosh wrote:

...

What would writing

isinstance(obj, types.int)

ever gain you except restricting execution to 2.3+?

It's like asking what do you gain by using string methods instead of the string module.

no, it's not. it's not like that at all. as michael pointed out, we've already added a *third* way to access type objects in 2.2. you're adding a *fourth* way. string methods were added at a time when Python went from one to two different string types; they solved a real implementation problem. reducing/eliminating the need for the string module was a side effect.

It's part of a slow, long-term effort to clean up the language while trying to minimize the impact on existing code.

or as likely, part of a slow, long-term effort by to make Python totally unusable for any serious software engineering... "who cares about timtowtdi? we add a new one every week!" "we know what's better for you. you don't." "deprecation guaranteed!" (etc)

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

On Tue, Jun 25, 2002 at 02:08:54PM +0200, Peter Funk wrote:

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.

I don't like it very much either. I prefer the string module to be silently deprecated "forever" without any specific schedule for removal. That's why the Backward Compatibility section of this PEP says that "it is not planned to actually remove the long names from the types module in some future version." I think that actually breaking backward compatibility should be reserved for really obscure modules that virtually nobody uses any more. Another case is when the programs that will be broken were using somewhat questionable programming practices in the first place (e.g. lst.append(x,y) instead of lst.append((x,y)) or assignment to __class__).

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.

In fact, reusing the types module instead of deprecating and eventually removing it will ensure that no ImportError will be raised. The new types module will also serve as a retirement home for the long type names where they can live comfortably and still be of some use to old code instead being evicted. There is a problem though. "from types import *" would import the short names, too, overriding the builtins. If you redefine int or str you probably deserve it :-) but if you have an innocent variable called "function" somewhere in your module it will get clobbered. This is a problem. The solution might be to include only the long type names in __all__. Oren

>> 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. aahz> This can be solved by a combination of changing the documentation aahz> and using __all__ (which I think is in part precisely the point of aahz> creating __all__). I don't think __all__ would help here. The problem as I see it is that the docs say "from types import *" is safe. If you add new names to the types module, they would presumably be added to __all__ as well, and then "from types import *" could clobber local variables or hide globals or builtins the programmer didn't anticipate. So, if we add an object named "function" to the types module and Peter's stable code has a variable of the same name, it's possible that running on a new version of Python will introduce a bug. Still, I have to quibble with Peter's somewhat extreme example. If you take a stable system of the complexity of perhaps Linux or Windows and upgrade it four years later, Python compatibility will probably only be one of many problems raised by the upgrade. If you have a stable program, you try to leave it alone. That means not upgrading it. If you modify the environment the program runs in, you need to retest it. If you write in C you can minimize these problems through static linkage, but the problem with Python is no different than that of a program written in C which uses shared libraries. Names can move around (from one library to another) or new names can be added, giving rise to name conflicts. I seem to recall someone reporting recently about another shared library which defined an external symbol named "socket_init". Skip