Multi-dimensional list initialization

[Ian Kelly]

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.

> There is a special keyword which signals the new type of comprehension;  A
> normal comprehension would say eg: '[ foo for i in xrange ]'; but when the
> 'for i in' is reduced to a specific keyword such as 'ini' (instead of
> problematic 'in') the caching form of list comprehension would start.

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.

> So, then, just like a comprehension -- the interpreter will begin to
> evaluate the code from the opening bracket '['; But anything other than a
> function/method will raise a type error (people might want to change that,
> but it's safe).
>
> The interpreter then caches all functions/initialiser methods it comes into
> contact with.
> Since every function/method has a parameter list (even if empty);  The
> interpreter would evaluate the parameter list on the first pass through the
> comprehension, and cache each parameter list with it's respective function.
>
> When the 'ini' keyword is parsed a second time, Python would then evaluate
> each cached function on its cached parameter list; and the result would be
> stored in the created list.
> This cached execution would be repeated as many times as is needed.
>
> Now, for your example:
>
> values = zip(samples, times * num_groups)
>     if len(values) < len(times) * num_groups:
>         # raise an error
>
> Might be done with:
>
> values = zip(   samples, [ lambda:times, ini xrange(num_groups) ]   )
>
>     if len(values) < len(times) * num_groups
>
> The comma after the lambda is questionable, and this construction would be
> slower since lambda automatically invokes the interpreter; but it's correct.

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?  Your basic complaint about list
multiplication as I understand it is that the non-copying semantics
are unintuitive.  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.

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

> [lambda:6 for i in xrange(10) ] # Nope.

Thak constructs a list of 10 functions and never calls them.  If you
want to actually call the lambda, then:

[(lambda: 6)() for i in range(10)]

or:

map(lambda i: 6, range(10))

But note that the former creates equivalent 10 functions and calls
each of them once, whereas the latter creates one function and calls
it ten times.

>> Of course you got an integer. You took an index of the range object, not a
>> slice. The rule is that taking an index of a sequence returns an element;
>> taking a slice of a sequence returns a sub-sequence. You still have not
>> shown any inconsistency here.
>
>
> Because it's an arbitrary rule which operates differently than the
> traditional idea shown in python docs?
>
> slice.indices()  is *for* (QUOTE)"representing the set of indices specified
> by range(start, stop, step)"
> http://docs.python.org/2/library/functions.html#slice

slice.indices() has nothing to do with it.  Indexing a sequence and
calling the .indices() method on a slice are entirely different
operations.  The slice.indices method is a utility method meant to be
called by __getitem__ implementations when doing slicing, not an
implementation of indexing.  When a sequence is indexed, there is no
slice.  That method is not related in any way to the semantics of
indexing a sequence.