What about an EXPLICIT naming scheme for built-ins?

Alex Martelli aleaxit at yahoo.com
Wed Sep 8 08:31:34 CEST 2004


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

> But a generator can't be "typecast"
> in my mental model -- it`s not a variable. It is a "program" that
> returns a sequence of values that have to be processed somehow. On the

It's an expression, it's not a variable -- "foo()=23" is incorrect, of
course.  But so is, say, "2+2=23" because 2+2 is also an expression, not
a variable, yet of course something like str(2+2) is fine.  That
erroneous focus on variable rather than expression must matter, then.

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

 
> Now I'll admit my ignorance and say that I didn't had the slightest
> idea about what do generator expressions meant until now. I just read
> the PEP, and it`s neat -- but I havent time to figure out the impact
> (remember, I was out of the list over the past year and half :-)

Well, as long as list comprehensions remain side by side with the new
generator comprehensions, the drive to use list comprehensions rather
than other constructs will presumably remain intact.


Alex



More information about the Python-list mailing list