deprecate iterkv?

[jseabold]

Is there any reason to keep around the iterkv shadow for iteritems?

[jreback]

the reason it exists IIRC, iteritems is not available in py3 because of 2to3 (and items is axis 0 name).

[jseabold]

Hmm, I see. That's brutal. I suppose it's possible to write a custom fixer to avoid iteritems -> items? I don't know I've never looked beyond the available ones. Also might be possible to remove once there's a single codebase Python >= 2.7.

[jreback]

@cpcloud know anything about 2to3

do we have an open item for making code base 3 compat?

it's prob pretty close I think

[cpcloud]

a quick glance at a github search for "python 3" suggests no...i remember @hayd had a few print fixes...

i think pandas is fairly close...

biggest issue might be the use of all the non iterator-functions like map, filter, and zip to produce lists.

six is a nice lib for this.

it would be great to not have to use 2to3...would make life much easier for testing and would speed up the travis builds

[cpcloud]

Semi OT: how is it decided when an older python version shouldn't be supported anymore?

[jtratner]

@cpcloud Actually, Python 2.6 will stop being supported in October 2013, so it might be a good time to revisit support for it then.

For 2to3 compat, could use from __future__ import unicode_literals to get a bit closer, right?

[cpcloud]

@jtratner hmm i don't know enough to even guesstimate what that could possibly break...maybe nothing, maybe lots of things 😄

[jreback]

prob won't stop supporting py2.6 anyone soon though (though if specif issues are problematic then can just raise on those)

[jreback]

@cpcloud maybe need a make codebase py3 compat without 2to3
prob close now

[cpcloud]

sounds good

[cpcloud]

sorry i thought u meant "close it now"

[cpcloud]

you meant close as in "close to finished"

[jreback]

yes but might as well close anyhow (and put in a todo in the py3 issue) this