Path: csiph.com!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <509B2355.60407@r3dsolutions.com>
References: <mailman.3267.1352096879.27098.python-list@python.org> <50978323$0$6908$e4fe514c@news2.news.xs4all.nl> <CAHVvXxQR2J2tyFcQZd7bNYTAeetwM+LfoV4UcYrkRfeNVOj+pg@mail.gmail.com> <CAPTjJmqzQi2TEjme_we-KfmG7vxOfRWoKG=zL=SGHYGqiFf9_Q@mail.gmail.com> <CAHVvXxQNCxpACM=tkKir0f3iVqui4oVGnyS-GywO+dtGacKAdQ@mail.gmail.com> <mailman.3311.1352181444.27098.python-list@python.org> <5098d2ac$0$29980$c3e8da3$5496439d@news.astraweb.com> <mailman.3343.1352242047.27098.python-list@python.org> <5099bf7d$0$29980$c3e8da3$5496439d@news.astraweb.com> <509ADA6E.10403@r3dsolutions.com> <CALwzidmkGMH0qXCAa=24-=Nej+CJ0asDMFKZbFxuXfcpzC=emA@mail.gmail.com> <509B2355.60407@r3dsolutions.com>
From: Ian Kelly <ian.g.kelly@gmail.com>
Date: Thu, 8 Nov 2012 00:09:35 -0700
Subject: Re: Multi-dimensional list initialization
To: Python <python-list@python.org>
Content-Type: text/plain; charset=ISO-8859-1
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.3422.1352358609.27098.python-list@python.org>
Lines: 97
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:32933

On Wed, Nov 7, 2012 at 8:13 PM, Andrew Robinson
<andrew3@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.