Re: [Tutor] implied tuple in a list comprehension
On 02/08/13 08:32, Jim Mooney wrote: x = [idx, word for idx, word in S] #syntax error # Why can I imply a tuple after the for, but not before? How should Python interpret this? As x = [idx, (word for idx, word in S)] Or x = [(idx, word) for idx, word in S] It's ambiguous. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] implied tuple in a list comprehension
On 02/08/13 18:02, Jim Mooney wrote: I see what you mean, but I figured it can't be ambiguous if one interpretation makes no sense, and I can't see what x = [idx, (word for idx, word in S)] could possibly mean. Am I assuming too much foresight on the part of the parser or does that actually mean something? It makes perfect sense. You can try it yourself, if you pre-define some names that get used: idx = 42 S = [(0, "fe"), (1, "fi"), (2, "fo"), (3, "fum")] x = [idx, (word for idx, word in S)] print(x) => prints [42, at 0xb7b7098c>] Hmmm, that's interesting. What's a generator object? py> next(x[1]) 'fe' py> next(x[1]) 'fi' py> next(x[1]) 'fo' py> next(x[1]) 'fum' py> next(x[1]) Traceback (most recent call last): File "", line 1, in StopIteration -- Steven ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] implied tuple in a list comprehension
On Fri, Aug 2, 2013 at 10:02 AM, Jim Mooney wrote:
> On 2 August 2013 00:46, Alan Gauld wrote:
> > On 02/08/13 08:32, Jim Mooney wrote:
>
> > How should Python interpret this?
> >
> > As
> >
> > x = [idx, (word for idx, word in S)]
> >
> > Or
> >
> >
> > x = [(idx, word) for idx, word in S]
> >
> > It's ambiguous.
> >
> I see what you mean, but I figured it can't be ambiguous if one
> interpretation makes no sense, and I can't see what x = [idx, (word
> for idx, word in S)] could possibly mean. Am I assuming too much
> foresight on the part of the parser or does that actually mean
> something?
>
>
Yes, it means something very clear, try running it:
>>> s = zip(range(10), range(10, 0, -1))
>>> s
[(0, 10), (1, 9), (2, 8), (3, 7), (4, 6), (5, 5), (6, 4), (7, 3), (8, 2),
(9, 1)]
>>> idx = "hello"
>>> x = [idx, (word for idx, word in s)]
>>> x
['hello', at 0x7f54a21e0780>]
>>>
it means "make the name 'x' point to a list, with as its first element the
variable 'idx' and as its second variable a generator expression. The
generator expression takes s, assumes it is a sequence of 2-tuples (by
unpacking each item into two variables, 'idx' and 'word', and grabs the
second item ('word') from each tuple.
HTH,
Hugo
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] implied tuple in a list comprehension
On 02/08/13 19:13, Jim Mooney wrote: comma, then word in S, which made no sense, instead of unpacking - word for (idx, word) in S. Done in again by the implied tuple ;') Just to pick up a point that might be confusing you. A tuple does not need parentheses. >>> tup = 5,4 >>> tup (5, 4) >>> type(tup) tup is a tuple. Its not implied it is complete. The parentheses are only added to avoid ambiguity and aid readability. For example a single item tuple is more obvious with the parens: t = (6,) # t=6, works but is much harder to see. HTH, -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] implied tuple in a list comprehension
>> t = (6,) # t=6, works but is much harder to see. > > That could lead to awful bugs, since it really is hard to see, and > hitting the comma is a mistake I often make. I think I may stick with > always using parentheses for tuples. Some conveniences aren't that > convenient. And this from the man who hates extra typing! ;-) Alan g. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] apply() vs. the extended call syntax
Tim Johnson wrote: > * Tim Johnson [130802 15:41]: > <...> Is there a cleaner way to do this? using apply() >> looks so much simpler, but I understand it is not even available in >> py 3 > def apl(funcall): funcall[0](*funcall[1]) > k = "key2" > >>> apl(func_D[k]) > I don't have an argument! > ## ??? :) > See http://docs.python.org/2/library/functions.html#apply The apply approach has been replaced by * and ** arguments, the former for positional args, and the latter for keyword arguments. See http://docs.python.org/2/tutorial/controlflow.html#unpacking-argument-lists -- DaveA ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
