[Python-Dev] Re: [Python-checkins] python/dist/src/Lib types.py,1.26,1.27

Guido van Rossum guido@python.org
Thu, 23 May 2002 16:04:14 -0400

> I accept that argument completely.  The question is how quickly can
> we make types.py go away, and how do we treat it until then.  I
> would be disappointed, but not extremely inconvenienced if it went
> away totally in 2.3.  In spite of that, I feel strongly that the
> right thing to do is to maintain types.py consciously.

There's no way it can go away completely in 2.3.  The PEP rules about
deprecation are clear: they require at least a year (i.e. two releases
or more) from the announcement of the deprecation; in cases of heavily
used modules like types.py I think we should go slower.

But a general rule is that no new features should be added to
deprecated modules, since they are only kept around so that old code
using them doesn't break; new code should not use deprecated modules.

> I think we should keep adding to it, because users expect core types
> to be in there.  So far there has been no counter-argument to this
> point *at all*.  All of the proposed counter-arguments have really
> been addressing the entirely different (and valid) reasons why
> types.py should be depricated.

OK, so let me explain why I'm against adding new stuff to types.py.
I'm against adding new features to anything that's (about to) being
deprecated.   The addition of new features sends the wrong message:
it suggests that the module is in active use, recommended for use,
supported, maintained, etc.  When someone finds that types.py has no
name for the Boolean type, maybe this will cause them to realize that
it's being deprecated and that in the long run (with emphasis on long)
it's going away.

> In the costs of maintaining types.py weren't so insignificant, then
> I'd be all for letting it rot.  We even have volunteers who are
> willing to do the work!  So why are we still raining on the parade?

See my note explaining that having all types bundled together was not
an optimal idea.  I don't want to break old code, but I do want to
nudge people into the right direction, away from types.py.

--Guido van Rossum (home page: http://www.python.org/~guido/)