On 11/07/2012 11:09 PM, Ian Kelly wrote:
On Wed, Nov 7, 2012 at 8:13 PM, Andrew Robinson
<andr...@r3dsolutions.com> wrote:
OK, and is this a main use case? (I'm not saying it isn't I'm asking.)
I have no idea what is a "main" use case.
Well, then we can't evaluate if it's worth keeping a list multiplier
around at all.
You don't even know how it is routinely used.
FYI, the Python devs are not very fond of adding new keywords. Any
time a new keyword is added, existing code that uses that word as a
name is broken. 'ini' is particularly bad, because 1) it's not a
word, and 2) it's the name of a common type of configuration file and
is probably frequently used as a variable name in relation to such
files.
Fine; Its a keyword TBD then; I should have said 'foo'.
in is worse than ini, ini is worse than something else -- at the end of
the rainbow, maybe there is something....
values = zip( samples, [ lambda:times, ini xrange(num_groups) ] )
if len(values)< len(times) * num_groups
How is this any better than the ordinary list comprehension I already
suggested as a replacement? For that matter, how is this any better
than list multiplication?
You _asked it to implement_ a list multiplication of the traditional
kind; By doing copies by *REFERENCE*; so of course it's not better.
My intentions were for copying issues, not-non copying ones.
Your basic complaint about list
multiplication as I understand it is that the non-copying semantics
are unintuitive.
No.
1) My basic complaint is that people (I think from watching) primarily
use it to make initializer lists, and independent mutable place holders;
List multiplication doesn't do that well.
2) If it is indeed very rare (as D'Aprano commented) then -- it has a
second defect in looking to casual inspection to be the same as vector
multiplication; which opacifies which operation is being done when
matrix packages are potentially being used.
Well, the above is even less intuitive. It is
excessively complicated and almost completely opaque. If I were to
come across it outside the context of this thread, I would have no
idea what it is meant to be doing.
Nor would I *know* what this list multiplier look alike does
[1,2,3]*aValue without checking to see if someone imported a vector
library and the variable aValue has a special multiplication operator.
As an aside, how would you do the lambda inside a list comprehension?
As a general rule, I wouldn't. I would use map instead.
OK: Then copy by reference using map....:
values = zip( map( lambda:times, xrange(num_groups) ) )
if len(values) < len(times) * num_groups ...
Done. It's clearer than a list comprehension and you still really don't
need a list multiply.
I''m not going to bother explaining what the construction I offered
would be really good at.
It's pointless to explain to the disinterested.
Thak constructs a list of 10 functions and never calls them. If you
want to actually call the lambda, then:
Yep, I was very tired.
slice.indices() has nothing to do with it. Indexing a sequence and
calling the .indices() method on a slice are entirely different
operations.
Yes, but you're very blind to history and code examples implementing the
slice operation.
slice usually depends on index; index does not depend on slice.
Slice is suggested to be implemented by multiple calls to single indexes
in traditional usage and documentation.
The xrange(,,)[:] implementation breaks the tradition, because it
doesn't call index multiple times; nor does it return a result
equivalent identical to doing that.
It's different. period. You're not convincing in the slightest by
splitting hairs.
--
http://mail.python.org/mailman/listinfo/python-list
