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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4