Tuple comprehension
Magnus Lie Hetland
posts about it (about a year old). The question is: Could we have
tuple comprehensions?
The argument I saw used earlier was based on the author's
preconceptions about tuples being primarily "records" and not
"containers". The only defining quality I see to tuples as opposed to
lists is that they are immutable. (Yes, I see the "recordness", but I
don't think it's an argument against tuple comprehension.)
Tuple comprehension could be useful when creating a tuple based on
another sequence, where you'd iterate over the values, doing something
to each of them. Of course you can do tuple([x for x in ...]). If
adding tuple comprehensions is too costly, then this is perfectly
viable. (I guess a tuple comprehension would have to create a list or
something similar internally anyway...)
As far as I can see, the PEP on dict comprehension is still open... I
think both dictionary comprehension and tuple comprehension seem like
natural parallels to list comprehension. But then I would, wouldn't I?
<wink>
--
Magnus Lie Hetland The Anygui Project
http://hetland.org http://anygui.org
Emile van Sebille
> As far as I can see, the PEP on dict comprehension is still open... I
> think both dictionary comprehension and tuple comprehension seem like
> natural parallels to list comprehension. But then I would, wouldn't I?
> <wink>
>
Why not just tuple([my list comp]) ?
--
Emile van Sebille
em...@fenx.com
---------
Sean 'Shaleh' Perry
On 11-Apr-2002 Emile van Sebille wrote:
> Magnus Lie Hetland
>> As far as I can see, the PEP on dict comprehension is still open... I
>> think both dictionary comprehension and tuple comprehension seem like
>> natural parallels to list comprehension. But then I would, wouldn't I?
>> <wink>
>>
>
> Why not just tuple([my list comp]) ?
>
because it feels wrong to create a (possibly large) list and then duplicate it
into a tuple. My mind sees that and thinks 'overhead'.
Max M
The natural way to implement it in practice is almost certainly just do
it behind your back.
Append takes a mutable sequence.
The most effcient mutable sequence in Python is the List, so why should
they make a "better" mutable sequence to support tuple comprehensions?
And if they did make a better mutable sequence should there really be
two of them? That would be redundant code that would need to be
refactored. Probably into the list class.
Then they would use the list class to implement tuple comprehensions...
From here on my arguments gets a wee bit circular ...
regards Max M
bru...@tbye.com
> It seems this has been brought up before, but I could only find two
> posts about it (about a year old). The question is: Could we have
> tuple comprehensions?
>
> The argument I saw used earlier was based on the author's
> preconceptions about tuples being primarily "records" and not
> "containers". The only defining quality I see to tuples as opposed to
> lists is that they are immutable. (Yes, I see the "recordness", but I
> don't think it's an argument against tuple comprehension.)
Maybe not directly, but it might argue against them simply because tuple
comprehensions wouldn't be used as much. They'd be useful when you're
using tuples as containers and not records, or when all the record members
are the same "type" to your application, e.g.:
coord = (x,y,z)
scaled = (f/2 for f in coord)
I use list comprehensions all the time, but I have trouble coming up with
too many cases where tuple comprehensions would be useful. Maybe I'm
missing a large set of potential uses?
> As far as I can see, the PEP on dict comprehension is still open... I
> think both dictionary comprehension and tuple comprehension seem like
> natural parallels to list comprehension. But then I would, wouldn't I?
I'd *love* to have dictionary comprehensions!
I guess the reason list and dictionary comprehensions make sense to me and
tuple comprehensions do not is because for lists and dictionaries they are
direct replacements for the initialize-to-empty-then-loop-to-populate
task, for which there is no tuple equivalent:
d = empty list or dict
for item in someInputSet:
do something to item and add it to d
-Dave
Tim Peters
> ...
> I'd *love* to have dictionary comprehensions!
Try this on for size:
>>> dict([(i, i**2) for i in range(10)])
{0: 0, 1: 1, 2: 4, 3: 9, 4: 16, 5: 25, 6: 36, 7: 49, 8: 64, 9: 81}
>>>
That is, 2.2 dict() accepts an iterable object producing iterable objects
each producing two values. A list of 2-tuples is one instance of that, and
one particularly easy to create with a listcomp. More possibilities open if
you ponder other kinds of iterable objects; e.g.,
>>> def squarepairs(n):
... for i in range(n):
... yield i, i**2
...
>>> dict(squarepairs(10))
{0: 0, 1: 1, 2: 4, 3: 9, 4: 16, 5: 25, 6: 36, 7: 49, 8: 64, 9: 81}
>>>
is one way to get the same end result without building a list in one gulp
first.
Sean 'Shaleh' Perry
> I guess the reason list and dictionary comprehensions make sense to me and
> tuple comprehensions do not is because for lists and dictionaries they are
> direct replacements for the initialize-to-empty-then-loop-to-populate
> task, for which there is no tuple equivalent:
>
> d = empty list or dict
> for item in someInputSet:
> do something to item and add it to d
>
since tuples are immutable there is no
initialize-to-empty-then-loop-to-populate idiom, you are correct. Because of
this when a tuple would work we have to use lists. Numerous times while coding
I have started using a tuple and had to fall back to lists because I eventually
needed a way to give all of the values in my list a value based on a function.
I personally like tuples because they say "this list is immutable, it won't
grow or shrink and try not to touch its contents". Just like using 'const' and
'private' in other languages.
If there was a way to create a tuple whose contents were programmatically
created and avoid the list -> tuple conversion I suspect tuples would get more
use.
bru...@tbye.com
> > d = empty list or dict
> > for item in someInputSet:
> > do something to item and add it to d
> >
>
> since tuples are immutable there is no
> initialize-to-empty-then-loop-to-populate idiom, you are correct.
> Because of this when a tuple would work we have to use lists.
> Numerous times while coding I have started using a tuple and had to
> fall back to lists because I eventually needed a way to give all of
> the values in my list a value based on a function.
>
> I personally like tuples because they say "this list is immutable, it
> won't grow or shrink and try not to touch its contents". Just like
> using 'const' and 'private' in other languages.
Ah...I think I understand your perspective a little better now. I never
think of a tuple as a list that's immutable, so I don't encounter very
often the same population problem. To me, lists become immutable when I
give them names in all caps, just like my variables become constants when
I name them that way.
-Dave
bru...@tbye.com
Woo-hoo! "Upgrader's delight" is Python's antithesis of "buyer's remorse";
you upgrade to get some new feature only to go back later and discover
additional gems as well.
Thanks for the tip!
-Dave
Sean 'Shaleh' Perry
> Ah...I think I understand your perspective a little better now. I never
> think of a tuple as a list that's immutable, so I don't encounter very
> often the same population problem. To me, lists become immutable when I
> give them names in all caps, just like my variables become constants when
> I name them that way.
>
I do similar things, but using the language to help prevent mistakes is handy
when I give people modules to use in their own code.
Alex Martelli
...
> ... for i in range(n):
...
Actually, range DOES "build a list in one gulp" (but I guess you might
use xrange instead:-).
Alex
Huaiyu Zhu
One ancillary question: why xrange(n) is not iterator?
Huaiyu
Alex Martelli
...
> One ancillary question: why xrange(n) is not iterator?
The Time Machine must have malfunctioned, I guess, so that, strangely
enough, they were unable go back and design xrange as an iterator years
before iterators were in the language...?
Alex
Magnus Lie Hetland
Sebille wrote:
>Magnus Lie Hetland
>> As far as I can see, the PEP on dict comprehension is still open... I
>> think both dictionary comprehension and tuple comprehension seem like
>> natural parallels to list comprehension. But then I would, wouldn't I?
>> <wink>
>>
>
>Why not just tuple([my list comp]) ?
I thought I mentioned that in my post. Oh, well.
Of course you can do that. Just like you can use a for-loop instead of
list comprehensions -- they're not essential at all either. Just
compact and readable.
Magnus Lie Hetland
Of course, until we get some sort of "freezing", that is what would
have to happen behind the scenes, I imagine.
Magnus Lie Hetland
bru...@tbye.com wrote:
[snip]
>I use list comprehensions all the time, but I have trouble coming up with
>too many cases where tuple comprehensions would be useful. Maybe I'm
>missing a large set of potential uses?
Well, at the moment I'm working with coordinates and various
aggregates (related to Anygui), and would like to have tuples as the
"base case" for those, e.g.
foo.geometry == 10, 10, 100, 100
I might want to calculate that based on a rule where I have something
like
names == ['x', 'y', 'width', 'height']
state = {'x': 10, 'y': 10, ...}
In this case, a tuple comprehension would be useful to me. Not
essential, of course, but then again, neither would a list
comprehension. It just seems natural to do
geometry = (state[name] for name in names)
(I'm assuming that the added parentheses would signal the tuple
comprehension, just like the added brackets will signal generator
comprehension.)
> -Dave
Magnus Lie Hetland
I think the only _real_ reason to have tuples at all is that they are
immutable (and therefore usable as dictionary keys). And a slight
efficiency advantage over lists, maybe...
David Eppstein
m...@vier.idi.ntnu.no (Magnus Lie Hetland) wrote:
> I think the only _real_ reason to have tuples at all is that they are
> immutable (and therefore usable as dictionary keys). And a slight
> efficiency advantage over lists, maybe...
I'm guessing (without looking at the source) that tuples use less memory
because they don't need the extra room for growth that lists do.
But my mental model of them is just "immutable list".
Which as you say is important for use in dictionaries...
--
David Eppstein UC Irvine Dept. of Information & Computer Science
epps...@ics.uci.edu http://www.ics.uci.edu/~eppstein/
bru...@tbye.com
> In article <slrnabchg...@vier.idi.ntnu.no>,
> m...@vier.idi.ntnu.no (Magnus Lie Hetland) wrote:
>
> > I think the only _real_ reason to have tuples at all is that they are
> > immutable (and therefore usable as dictionary keys). And a slight
> > efficiency advantage over lists, maybe...
>
> I'm guessing (without looking at the source) that tuples use less memory
> because they don't need the extra room for growth that lists do.
> But my mental model of them is just "immutable list".
Yes, this is where the difference in opinion lies: as immutable lists,
tuple comprehensions can make sense. I like the mental model of tuples
put forth by the Python tutorial:
[5.3] "Tuples have many uses, e.g. (x, y) coordinate pairs, employee
records from a database, etc."
The implication is that tuples group bits of often dissimilar but related
information that, grouped together, represent a unique entity - sort of a
poor man's object instance.
In this sense tuple comprehensions are less valuable because they'd really
only be useful in cases where all the members are homogeneous, where it'd
make sense to apply the same sort of operation to each item. There's a few
obvious cases where this happens (coordinates, open/high/low/close prices
for a stock), but they don't seem all that common.
-Dave
bru...@tbye.com
> On 4/12/02 8:20 AM -0700, bru...@tbye.com wrote:
> > The implication is that tuples group bits of often dissimilar but related
> > information that, grouped together, represent a unique entity - sort of a
> > poor man's object instance.
>
> But there's nothing preventing a list from holding inhomogeneous items,
> either.
Yes (and, once again, in that case the usefulness of comprehensions break
down), but in the general sense they are most powerful when there *is*
some common feature to the items in the list. Obviously the common ground
can range from quite specific (a list of integers) to quite broad (a list
of whatevers that this function is capable of processing). If the items
don't have this sort of relation, why do you have them in a list anyway?
> So I don't see how this is a difference between tuples and lists,
> unless it's just one of standardized style.
The essence of this discussion is that it *is* more than a difference of
just standardized style - tuples were built for one thing and lists
another, albeit with a certain amount of overlap. Tuples work well in the
record-like or dictionary key scenario, while lists are more general
purpose, for use when you need to apply similar processing to a lot of
"stuff".
If tuples don't seem to do all you want it *might* indicate that an
enhancement to the language is in order, but maybe it means that a
different data type would be more appropriate.
Spoons and forks solve similar problems, and in many cases it doesn't
matter which you choose to use even though they were designed to solve
slightly different problems. If your ice cream refuses to cooperate with
your fork it *might* mean you need a better fork, but maybe it means you
should use a spoon (or a spork[1]).
-Dave
Jeff Shannon
m...@vier.idi.ntnu.no says...
> [...] It just seems natural to do
>
> geometry = (state[name] for name in names)
>
> (I'm assuming that the added parentheses would signal the tuple
> comprehension, just like the added brackets will signal generator
> comprehension.)
This wouldn't work -- the parser already recognizes parentheses
as expression grouping. Even if we *could* make the parser smart
enough to recognize a tuple-comp, it would be confusing to read,
at least IMO.
I also agree with Dave Brueck, that the cases in which tuples
hold uniform values (so that tuple comprehensions might make
sense) are relatively rare, compared to cases in which tuples
hold heterogeneous values. (This is exactly the opposite case of
lists, which may be heterogeneous but are usually homogenous.)
So ISTM that tuple comprehensions would be of limited utility.
--
Jeff Shannon
Technician/Programmer
Credit International
Quinn Dunkan
wrote:
>On Thu, 11 Apr 2002, David Eppstein wrote:
>
>> In article <slrnabchg...@vier.idi.ntnu.no>,
>> m...@vier.idi.ntnu.no (Magnus Lie Hetland) wrote:
>>
>> > I think the only _real_ reason to have tuples at all is that they are
>> > immutable (and therefore usable as dictionary keys). And a slight
>> > efficiency advantage over lists, maybe...
>>
>> I'm guessing (without looking at the source) that tuples use less memory
>> because they don't need the extra room for growth that lists do.
>> But my mental model of them is just "immutable list".
>
>Yes, this is where the difference in opinion lies: as immutable lists,
>tuple comprehensions can make sense. I like the mental model of tuples
>put forth by the Python tutorial:
>
>[5.3] "Tuples have many uses, e.g. (x, y) coordinate pairs, employee
>records from a database, etc."
>
>The implication is that tuples group bits of often dissimilar but related
>information that, grouped together, represent a unique entity - sort of a
>poor man's object instance.
This is how I think of them too. One test is that if you create them with
literal constructors (which you must, since (without tuple constructors) you
have no choice) and destruct them with pattern patching (as in 'x, y = coords')
and their length is part of their 'type', then they are tuples.
If you create them piecemeal (by appending) and tend to index them or iterate
over them (this including mapping), and they can be any length, then they are
lists.
I suspect I think of things in these terms because of previous languages where
the difference is part of the language (e.g. lists must be homogenous and
tuples cannot be indexed).
Where one person might write:
def move(coord, vector):
return tuple(map(operator.add, coord, vector))
I might write:
def move((x1, y1), (x2, y2)):
return (x1 + x2, y1 + y2)
Of course, the second version is less generic since it only works for pairs,
but if I had a system with n-dimensionsal coords maybe I'd use lists since
they can be various lengths. This would be a hint to think of additional
cases such as "what happens when you move a 3d point by a 2d vector?".