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

[Guido van Rossum]

[me]
> > Why don't you wait and see what shows up in Python 2.3 when it is
> > released.

[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.

Did you get up on the wrong side of the bed today?  :-)

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.)

> > It's good that we're arguing about this now -- we should offer
> > something to replace all features of the the types module in 2.3.
> 
> 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.

I don't think we specifically need a *container* for those names
though; all we need is names.  Most people use "from types import *"
and then use 1 or 2 of the imported names.  In the distant past there
was no way to spell those names except by using type(0) etc.; adding
types.py was an improvement because it added names for the types, and
at the time this was easier done that making them all builtins.  But
now we have a better way: use int, str, bool etc. directly.

> Clearly, it is not the best API for many tasks, but it is a standard
> one that is widely used.  So if there is something better to be
> done, we should create a new module and be clever there.

IMO the idea of having a single module that exposes names for "all"
types is flawed.  In general, the name for a type should be exposed by
the module or package that defines it.  For example, types related to
weak references are exposed by the weakref module.  The types for
built-in data types are of course exposed as built-in names.  What
remains in types.py is various types related to how Python represents
programs and executes them: for example modules, classes, functions,
methods, instances, code, frames, tracebacks.  I'm not sure there's
much of a need to name those types, and if there is, they should
probably be imported from a more specialized module.  Perhaps they
should go into sys?  But I'd like to see a demonstrated need for
naming these types first.

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.

I don't expect that "import types" will issue a warning in 2.3, but
the documentation will point out its bleak destiny and in 2.4 a
warning might indeed be issued.  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.  If you want naming consistency, use 'int', 'bool' etc.
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. :-)

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