<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 11/07/2012 03:39 PM, Ian Kelly wrote:
<blockquote
cite="mid:CALwzidmkGMH0qXCAa=24-=Nej+CJ0asDMFKZbFxuXfcpzC=emA@mail.gmail.com"
type="cite">
Why? Just to get rid of an FAQ?
</blockquote>
<span class="moz-smiley-s1"><span> :-) </span></span><br>
<br>
<blockquote
cite="mid:CALwzidmkGMH0qXCAa=24-=Nej+CJ0asDMFKZbFxuXfcpzC=emA@mail.gmail.com"
type="cite">Here's one of the more interesting uses from my own
code:</blockquote>
OK, and is this a main use case? (I'm not saying it isn't I'm
asking.)<br>
<br>
<blockquote
cite="mid:CALwzidmkGMH0qXCAa=24-=Nej+CJ0asDMFKZbFxuXfcpzC=emA@mail.gmail.com"
type="cite">Replacing the list multiplication in that function
with a list
comprehension would be awkward, as the obvious replacement of
[iter(iterable) for _ in range(n)] would produce different
results.</blockquote>
<br>
Yes. I have a thought on that.<br>
<blockquote
cite="mid:CALwzidmkGMH0qXCAa=24-=Nej+CJ0asDMFKZbFxuXfcpzC=emA@mail.gmail.com"
type="cite">
How exactly do you propose to indicate to the compiler which parts
of
the expressions are meant to be cached, and which are not?</blockquote>
<br>
Exactly?<br>
OK; Here's what I would consider a safe implementation -- but it
could be improved later.<br>
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.<br>
<br>
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).<br>
<br>
The interpreter then caches all functions/initialiser methods it
comes into contact with.<br>
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.<br>
<br>
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.<br>
This cached execution would be repeated as many times as is needed.<br>
<br>
Now, for your example:<br>
<blockquote type="cite">
<pre wrap="">values = zip(samples, times * num_groups)
if len(values) < len(times) * num_groups:
# raise an error</pre>
</blockquote>
Might be done with:<br>
<br>
values = zip( samples, [ lambda:times, ini xrange(num_groups) ]
)<br>
if len(values) < len(times) * num_groups<br>
<br>
The comma after the lambda is questionable, and this construction
would be slower since lambda automatically invokes the interpreter;
but it's correct.<br>
<br>
If you could provide a built in which returns a reference to the
parameter passed to it; that would run at max system speed; by
default, all built-in object initializers are maximally fast.<br>
<br>
The key difference is that the ini syntax evaluates the parameter
lists only once; and the ini's purpose is for repeating an
initialization of the same kind of object in multiple different
places.<br>
<br>
As an aside, how would you do the lambda inside a list
comprehension?<br>
[lambda:6 for i in xrange(10) ] # Nope.<br>
Generic lists allow a spurrious comma, so that [ 3,3,3, ] = [3,3,3]
dropped;<br>
[lambda:6, for i in xrange(10) ] # but this is no good.<br>
<br>
I have to do:<br>
def ref(): return 6<br>
[ref(x) for i in xrange(10) ]<br>
<br>
<blockquote
cite="mid:CALwzidmkGMH0qXCAa=24-=Nej+CJ0asDMFKZbFxuXfcpzC=emA@mail.gmail.com"
type="cite">
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.</blockquote>
<br>
Because it's an arbitrary rule which operates differently than the
traditional idea shown in python docs?<br>
<br>
slice.indices() is *for* (QUOTE)"representing the <u>set of
indices</u> specified by
<tt class="docutils literal"><span class="pre"><u>range</u>(start,</span>
<span class="pre">stop,</span> <span class="pre">step)</span></tt>"<br>
<a class="moz-txt-link-freetext" href="http://docs.python.org/2/library/functions.html#slice">http://docs.python.org/2/library/functions.html#slice</a><br>
<br>
There are examples of python doing this; use Google... They use
slice indices() to convert negative indexes into positive ones <u>compatible
with range()</u>.<br>
<br>
some_getitem_method_in_a_subclass_foo( self, range ):<br>
ret=[]<br>
for i in xrange( range.indices( len(self) ) ):<br>
ret.append( self.thing[i] )<br>
return ret<br>
<br>
The return is equivalent to a range object in the sense that it is
an iterator object, but it's not the same iterator object. It will
still work with legacy code.... since different iterators can be
interchanged so long as they return the same values.<br>
<br>
<blockquote
cite="mid:CALwzidmkGMH0qXCAa=24-=Nej+CJ0asDMFKZbFxuXfcpzC=emA@mail.gmail.com"
type="cite">
No, he wasn't. He was talking about multiplying lists of dicts,
and
whether the dicts are then copied or not, just like every other
Q&A
item in that dialogue was concerning whether item X in a list
should
expect to be copied when the containing list is multiplied.</blockquote>
<br>
I already told him several times before that what the answer was; <br>
It doesn't copy anything except the list itself.<br>
<br>
Then he asks, "does it multiply dicts" and no mention of it being
inside a list. <br>
He's browbeating a dead horse.<br>
<br>
<blockquote
cite="mid:CALwzidmkGMH0qXCAa=24-=Nej+CJ0asDMFKZbFxuXfcpzC=emA@mail.gmail.com"
type="cite">
Perhaps you're not aware that on the Internet, TYPING IN ALL CAPS
is
commonly construed as SHOUTING.
</blockquote>
Sure, and people say:<br>
<br>
THIS IS YELLING, AND I AM DOING IT HERE AS AN EXAMPLE.<br>
This is STRESS.<br>
This is SHOCK!<br>
<br>
I don't recall typing any <u>full sentence</u> in all caps, if I
did, I'm awfully sorry. I didn't mean it.<br>
Yes, he is beginning to get condescendingly exasperating. Everyone
else seems to understand 85+% of what I say, correctly. He doesn't;
and now replying to him appears to confuse everyone else.<br>
<br>
<br>
</body>
</html>