Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

deprecate iterkv? #4372

Closed
jseabold opened this issue Jul 26, 2013 · 15 comments
Closed

deprecate iterkv? #4372

jseabold opened this issue Jul 26, 2013 · 15 comments

Comments

@jseabold
Copy link
Contributor

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

@jreback
Copy link
Contributor

jreback commented Jul 26, 2013

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

@jseabold
Copy link
Contributor Author

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
Copy link
Contributor

jreback commented Jul 26, 2013

@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
Copy link
Member

cpcloud commented Jul 26, 2013

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
Copy link
Member

cpcloud commented Jul 26, 2013

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

@jtratner
Copy link
Contributor

@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
Copy link
Member

cpcloud commented Jul 26, 2013

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

@jreback
Copy link
Contributor

jreback commented Jul 26, 2013

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

@jreback
Copy link
Contributor

jreback commented Jul 26, 2013

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

@cpcloud
Copy link
Member

cpcloud commented Jul 26, 2013

sounds good

@cpcloud cpcloud closed this as completed Jul 26, 2013
@cpcloud cpcloud reopened this Jul 26, 2013
@cpcloud
Copy link
Member

cpcloud commented Jul 26, 2013

sorry i thought u meant "close it now"

@cpcloud
Copy link
Member

cpcloud commented Jul 26, 2013

you meant close as in "close to finished"

@jreback
Copy link
Contributor

jreback commented Jul 27, 2013

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

@cpcloud
Copy link
Member

cpcloud commented Jul 27, 2013

okie doke

@cpcloud cpcloud closed this as completed Jul 27, 2013
@cpcloud
Copy link
Member

cpcloud commented Jul 27, 2013

see #4375

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants