What about an EXPLICIT naming scheme for built-ins?

[Carlos Ribeiro]

On Wed, 8 Sep 2004 08:31:34 +0200, Alex Martelli <aleaxit at yahoo.com> wrote:
> Carlos Ribeiro <carribeiro at gmail.com> wrote:
> 
> > On Tue, 07 Sep 2004 20:04:57 GMT, Anna Martelli Ravenscroft
> > <anna at aleax.it> wrote:
> > > I *guess* I had thought of it, if at all, as something similar to
> > > int('2') or float(2). They're useful, but only in very limited specific
> > > cases. I would have expected list('cat') to force a list out of the
> > > string. Just like int() or float() and, well, that's it. That's as far
> > > as I would have thought of it as being useful...
> >
> > Extending your reasoning a little bit, list(anything) smells a
> > typecast -- something that's used to convert a variable of one type
> > into a variable of another type.
> 
> I know of no language in which such casts are limited to variables nor
> any in which they produce variables: it's always about _expressions_ (in
> C terminology, "rvalues" -- can be on the R-ight of the = in an
> assignment -- not "lvalues"... can't be on the L-eft ditto).

Sorry. I didn't express myself very well. This part of the discussion
is a bit confusing to me and I just can't find the words to say what
I'm thinking. Let me put it out this way: how can one "typecast" a
generator? It seems to be conceptually different from "typecasting" an
expression, a function, or variable, or a constant value.

After some pondering, I think I can rephrase my statement as:

"Extending your reasoning a little bit, list(anything) smells a
typecast -- something that's used to convert a VALUE of one type into
a VALUE of another type".

I prefer value in this context because the typecast really converts
the value returned by the expression to another type. Did it sound
right now?
 
> > other hand, [x for x in generator()] reads as a description of what is
> > getting done -- an algorithm of sorts -- and then it comes up as a
> > natural solution for the problem.
> 
> Yes, it does read as a loop.  The funny thing is, I haven't seen the
> same issues regarding sum(somenumbers()) -- which reads as a function
> call, syntactically the same as list(somenumbers()), not as a loop.

Your example made me realize that the underlying problem is (again)
the functional versus the imperative programming model. Let us think
about it from "outside the box", looking at the words as someone who
don't know Python yet:

-- sum(values()) is read as "sum all these values". It's a clear
interpretation, both in functional and imperative terms.

-- list(values()) is read as "list all these values". The functional
interpretation is easy -- it should return a list of all values. But
the traditional definition of the word "list" in imperative
programming is different -- it is associated with the action of
printing out a list of values. Our problem should be stated in
imperative terms as "put all these values into a list".

Many programmers were trained all their lives to think in the
imperative way, not the functional one, and that's probably the real
underlying problem. In a sense, *if* the list() builtin was named
makelist() -- an imperative spelling of the same concept -- I think
nobody would think twice before using it instead of the list
comprehension version. (Please, I'm far from advocating to change the
list() name -- the current name is fine and really ellegant -- I'm
just trying to point out a difference in mental models).


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