Multi-dimensional list initialization
ian.g.kelly at gmail.com
Thu Nov 8 08:09:35 CET 2012
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
> 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)]
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)"
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.
More information about the Python-list