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

[Kevin Jacobs]

> [Kevin Jacobs]
> > No, I won't just wait and see.  Do we want a development model where
> > everyone is satisfied to wait to see what gifts magically arrive in
> > the next release?  No thank you, Mr. Gates.
> 
> [Guido van Rossum]
> Did you get up on the wrong side of the bed today?  :-)

Yeah.  I'm pretty crabby today -- the air conditioning for our offices is
not working today and its about 10,000 degrees here.  I really should add
more smileys, or else people will take me too seriously.  ;)

> [Guido van Rossum]
> My point was that the argument based on "types.py is not deprecated"
> is flawed because it may well become deprecated.  (And I base that
> expectation upon the fact that most commonly used types now have
> built-in names, so the need to have types.py is largely going away.)

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.

> > [Kevin]
> > I have a hard time seeing how the types module can be replaced by
> > anything substantively different.  Its sole purpose is not complex:
> > to be a container of type names and type objects.
> 
> [Guido van Rossum]
> I don't think we specifically need a *container* for those names
> though; all we need is names.
> [...]
> IMO the idea of having a single module that exposes names for "all"
> types is flawed.
> [...]
> I don't expect types.py to go away before 3.0 (whenever that is :-), but I
> don't see why we should keep adding to it.

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.

> Note that 2.2 was inconsistent in its addition of names for new types
> to types.py: GeneratorType and DictProxyType were added, but
> classmethod, staticmethod, property, and the various internal
> descriptor types were not.

You may remember that I wanted to add some of those types into types.py for
2.2 (or 2.2.1?) and was told that they were implementation details and not
appropriate for inclusion.  The new boolean type is definitly not just an
implementation detail.

> If you don't want to touch old code, then don't touch it.  If you want
> to be compatible with Python-before-2.2, you have to live with some
> messiness.  That's life.  We're building a new intersection to improve
> traffic flow -- in the mean time, be prepared for backups. :-)

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?

Hot and bothered,
-Kevin


--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com