What about an EXPLICIT naming scheme for built-ins?

[Carlos Ribeiro]

Alex,

This discussion went so far as to entice a lot of different
interpretations. You're completely right about the inherent
contradiction in interpreting list() as both a typecast *and* an
imperative verb. And it doesn't help to note that neither
interpretation does full justice to what list() does in Python. Also,
as I only write in english when communicating by email, there are
times when I fail to find the words for what I want to express. So I
knew that there was something different about the word "sum" in the
context given but could not explain it -- and you're again right, it's
a case where verb and noun share the same spelling.

As for the current documentation, I have one specific suggestion that
may improve things a little bit. In the current version of the Python
documentation, list() is classified a *builtin function*. Calling
list() the *list constructor* would probably help to distinguish it
from other functions such as abs(), for example.

My proposal is to create a new category in the documentation for all
*builtin constructors*:

bool(), complex(), dict(), float(), int(), list(), object(), str(), tuple()

All built-in constructors share common behavior -- they return a new
object of the given type, using the argument as an initializer.
Reading about how constructors work in general will help one to
develop a broader, and better, understanding of their real power.

*** BTW, once you consider these functions as constructors, and
considering current int(), float() and str()'s behavior, it may be
worth investigating a way to generalize constructors using an
extensible protocol, using a __my-class-name__ magic function. So I
went to check it using -- guess what? __list__. And I found a previous
thread, dated January 2002, including a few messages from you:

http://mail.python.org/pipermail/python-list/2002-January/080191.html
(original message)
http://mail.python.org/pipermail/python-list/2002-January/080212.html
(yout first reply)

I agree that the iterator interface is a good solution for the list
problem, but don't you think that in the long run an standard
interface for generic conversion between different classes would make
sense? For example, list() could try __list__() first; if it doesn't
exist, then the current iterator interface would be used. For all
other types -- including dicts -- the new standard interface could be
useful. What do you think? Is it worth the entire PEP-fight process?

*** A (possibly useful) side effect of the proposed mechanism is the
automatic __dict__ conversion without the need even to introduce magic
names to newbies. For example, the following snippet of code would
generate a dict from a module:

>>> import string
>>> d = dict(string)
>>> d.keys()
...

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro at gmail.com
mail: carribeiro at yahoo.com