allow python 3 use

[sashahart]

Benefits: The reason for this small change is just to prevent seeing an error at every ColorV load when using +python3, which seems to be a logical continuation of how ColorV has started to support +python3 for users who use that or switch back and forth. Also, this would close issue #22.

Costs: I don't think this change should have any major tradeoff, or harm +python (2) support in any way. The possible reason to use iteritems() here instead of items() is to get an iterator, which is useful if we have a large number of items that we need to process lazily only a few at a time. But I found that there were 12 items in my 'fmt.' Also, they are all hardcoded, and I cannot think of any reason why more than a few more would ever be added. So it is not likely that this patch will ever have a noticeable effect on Python 2, and the iterator behavior will be used in Python 3 anyway. I have also been using this patch for a while and have not noticed any difference except that it loads instead of throwing the error.

[gu-fan]

so this change will not have side effects for python2 users??

[gu-fan]

seems ok

[sashahart]

Thanks for looking!

I am confident that nobody using :python instead of :python3 will notice any difference due to this change. But I don't want anyone to worry, so I will explain further.

During module import, the dict named fmt is created and 12 items are added to it. It takes roughly 2k of memory according to sys.getsizeof(). There is nothing adding items to fmt, so we know it won't take any more memory than that.

When Python 2 items() runs, it eagerly constructs a list of tuples before returning. This list has about the same memory cost, about 2k. And there is just one.

When Python 2 iteritems() or Python 3 items() run, they return an iterator which yields items one at a time. This also creates an object which takes a small amount of memory. In both cases, you have just one temporary object, with a similar memory cost, and similar garbage collection cost, and the cost is low by Python standards.

The reason for the API difference was that sometimes it is useful to have the iterator instead of the list because you have a very large dictionary (e.g. megabytes+) and can't afford the cost of making an additional copy. But with 12 items taking about 2k, it is hard to notice.

If anything, using items() for small dicts in python 2 might be very slightly faster, but I don't care enough to time that.

[gu-fan]

Thansk for your explore