Chris Angelico wrote:
> Rick Johnson wrote:
> > Chris Angelico wrote:
> > > Rick Johnson wrote:
> > > > 
> > > > Ruby:
> > > >     farray = [1.5, 1.9, 2.0, 1.0]
> > > >     uniqueIntegers = farray.map{|f| f.to_i()}.uniq.length
> > > >
> > > > Python:
> > > >     flist = [1.5, 1.9, 2.0, 1.0]
> > > >     uniqueIntegers = len(set(map(lambda f:int(f), flist)))
> > >
> > > Python:
> > >
> > > floats = [1.5, 1.9, 2.0, 1.0]
> > > unique_integers = len(set(int(f) for f in floats))
> > >
> > > or:
> > >
> > > unique_integers = len(set(map(int, floats))
> > >
> > > If you're going to use Python, at least use it right.
> >
> > Okay, you've replaced my map function with an implicit
> > list comprehension (aka: generator expression)... so how
> > is either more "right" than the other? What is your
> > justification that your example is "right", and mine is
> > not?
> 
> You had:
> 
> uniqueIntegers = len(set(map(lambda f:int(f), flist)))
> 
> I replaced it with:
> 
> unique_integers = len(set(map(int, floats))
> 
> Aside from the variable names, the significant difference
> here is that I pass int to map directly, where you wrap it
> up in a useless lambda function:
> 
> lambda f: int(f)

Oops! Yes, i did put a superfluous anonymous function in
there, my bad O:-) Although, to my defense, (and although i
never use this style in real code, but i'm trying to save
face here #_o, so bear with me...) the lambda does make the
call to map a "little" more clearer. For instance, when we
juxtapose:

    map(int, flist)
    
with:

    map(lambda f:int(f), flist)
    
We get a little more insight into the internal workings of
map in the second example, specifically, that each `f` in
`flist` is being cast to integer. Which, incidentally, is
why some folks prefer the explicit generator expressions and
list comprehensions over the implicit nature of map. But
along with your correction of my superfluous lambda, you
offered this additional generator expression form:

    unique_integers = len(set(int(f) for f in floats))
    
And this was the form for which my four questions were
directed (ignoring my superfluous lambda, of course). So i
resubmit my map form as:
    
    flist = [1.5, 1.9, 2.0, 1.0]
    uniqueIntegers = len(set(map(int, flist)))
    
and then we juxtapose your generator expression (with
variable names normalized free of charge ;-):

    flist = [1.5, 1.9, 2.0, 1.0]
    unique_integers = len(set(int(f) for f in flist))
    
So, what are your answers to my four questions:

    (1) Is it a speed issue? Then prove it.
    
    (2) Is it a readability issue? If so, then that's an
    opinion _you_ get to have.
    
    (3) Is it a matter of "python purity"?  If so, then map
    should be removed from the language, and don't forget to
    remove reduce and filter while you're at it, and then,
    you may want to grab a shield because the functional
    fanboys will be all over you like white on rice! (psst:
    here comes Rustom Mody now!!!)
    
    (4) Something else...?

> Of course Python is going to look worse if you add stuff
> like that to your code.

The lambda was an accident, perhaps even a happy accident,
but my four questions and my original intent stands valid
even in light of my simple mistake. Now dammit, answer the
questions! :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Reply via email to