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

[holger krekel]

Guido van Rossum wrote:
> [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.

It follows: *every* argument is flawed because the basis of the
argument might change or be deprecated :-) I agree to
Kevin that deprecating the 'cold way' is not nice. 

Moreover, I don't think that 'use the builtins' is
a brilliant idea. Even in the standard lib more than *80* modules use
the name 'list' for their own purposes. People just don't
associate 'list', 'dict', 'str' etc.  with types but use it in every 
day live as a convenient name. Much like the infamous 'int i;'
they want to have a canonical 'working-horse' name which 
binds an object of a certain type (but not the type itself!).
('int' is not used like this because 'i' is world-wide-known
to an int or unsigned int anyway :-) 

To me 'types.*' and even easier type(..) are still the consistent 
and explicit ways to reference type objects. the builtins
substitute the functionality but force into conflicting, un-intuitive 
and implicit naming. 

many-builtins-are-the-path-to-all-evil-ly yours, holger