Multi-dimensional list initialization
andrew3 at r3dsolutions.com
Thu Nov 8 09:26:53 CET 2012
On 11/07/2012 11:09 PM, Ian Kelly wrote:
> On Wed, Nov 7, 2012 at 8:13 PM, Andrew Robinson
> <andrew3 at 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
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.
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
Yes, but you're very blind to history and code examples implementing the
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-list