Multi-dimensional list initialization

[Andrew Robinson]

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20121108/ace40e40/attachment.html>