On 8/9/2012 5:21 PM, Tim Chase wrote:
On 08/09/12 15:41, Roman Vashkevich wrote:
10.08.2012, в 0:35, Tim Chase написал(а):
On 08/09/12 15:22, Roman Vashkevich wrote:
{(4, 5): 1, (5, 4): 1, (4, 4): 2, (2, 3): 1, (4, 3): 2}
and i want to print to a file without the brackets comas and semicolon in order
to obtain something like this?
4 5 1
5 4 1
4 4 2
2 3 1
4 3 2
for key in dict:
print key[0], key[1], dict[key]
This might read more cleanly with tuple unpacking:
for (edge1, edge2), cost in d.iteritems(): # or .items()
print edge1, edge2, cost
(I'm making the assumption that this is a edge/cost graph...use
appropriate names according to what they actually mean)
dict.items() is a list - linear access time whereas with 'for
key in dict:' access time is constant:
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#use-in-where-possible-1
That link doesn't actually discuss dict.{iter}items()
Both are O(N) because you have to touch each item in the dict--you
can't iterate over N entries in less than O(N) time. For small
data-sets, building the list and then iterating over it may be
faster faster; for larger data-sets, the cost of building the list
overshadows the (minor) overhead of a generator. Either way, the
iterate-and-fetch-the-associated-value of .items() & .iteritems()
can (should?) be optimized in Python's internals to the point I
wouldn't think twice about using the more readable version.
In 3.x, .keys, .values, and .items are set-like read-only views
specifically designed for iteration. So in 3.x they are THE way to do so
for whichever alternative is appropriate. Iterating by keys and then
looking up values instead of yielding the values at the same time is
extra work.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
