Skip to content

Add support for Python 3.x #1

Description

@mrry

Currently we only support Python 2.7, but we should support Python 3.

Activity

  1. girving commented on Nov 9, 2015

    @girving
    Contributor

    Main things this involves: print -> print(), handle __floordiv__ / __truediv__ / __div__ correctly.

  2. cdnsteve commented on Nov 9, 2015

    @cdnsteve

    👍 to this issue

  3. dvbuntu commented on Nov 9, 2015

    @dvbuntu
    Contributor

    👍

  4. ashwin31 commented on Nov 9, 2015

    @ashwin31

    👍

  5. self-assigned this
    on Nov 9, 2015
  6. joestepp commented on Nov 9, 2015

    @joestepp

    👍

  7. girving commented on Nov 9, 2015

    @girving
    Contributor

    We're working on it.

  8. kevinaloys commented on Nov 9, 2015

    @kevinaloys

    Python 3 is a must have. 👍

  9. mgcdanny commented on Nov 9, 2015

    @mgcdanny

    How do we contribute towards python3 support? Are there any specific tickets open? Is there a python3 development branch?

  10. cdnsteve commented on Nov 9, 2015

    @cdnsteve

    @mgcdanny seems they require contributors to sign an agreement first.
    https://github.com/tensorflow/tensorflow/blob/master/CONTRIBUTING.md

  11. MikalaiDrabovich commented on Nov 9, 2015

    @MikalaiDrabovich
    Contributor

    👍

  12. girving commented on Nov 10, 2015

    @girving
    Contributor

    I'm running futurize on the code at the moment; once that's done it'll be easier to parallelize the remaining work. So far futurize --stage1 is checked in and I'm working through futurize --stage2 now (checking each of our divisions very carefully :)).

    Unfortunately our contribution process needs a bit of improvement (we're working on streamlining it), but I'll see if there are natural chunks of work to break off and ask for help in fixing once the initial futurize push is done. Before that it's tricky to parallelize.

    The only non-obvious questions (so far) are what to do with unicode and where. Cc'ing @mrry since he was taking a look at that. Most of the "names" for things, such as names for ops and names for tensors in a graph, are already restricted to be roughly alphanumeric, so hopefully we should be able to leave them as C++ string while still accepting unicode input from Python.

  13. girving commented on Nov 10, 2015

    @girving
    Contributor

    Also, question for people that have done such conversions before / recently: is six still the recommended way to make code transparently support both? In particular, we need stuff like xrange and iteritems as symbols that exist in both 2.7 and 3.x.

  14. madisonmay commented on Nov 10, 2015

    @madisonmay

    @girving I would follow the guide written by python3 core dev Brett Cannon: https://docs.python.org/3.5/howto/pyporting.html. He's been heavily involved with the push to move existing libs to python3.

  15. 190 remaining items

  16. added 3 commits that reference this issue on May 22, 2026
  17. added 12 commits that reference this issue on Aug 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions