Python 3

Jack JenningsJack Jennings Posts: 152
edited July 2013 in Type Design Software
Seeing that Python 3 was released four years ago, and 2.7 will only be supported for ~2 more years, I'm curious which type-centric python libraries need to be ported over. I assume at this point that none of them have, but I could be wrong. The biggest hurdles that I can see are Robofab and Vanilla. PyObjC, which Robofont and parts of Glyphs depends on, would also be a huge component of Python 3 compliance, but it seems to be making the jump (can anyone verify this?). Are there other big python libraries that would need attention to move your scripts from 2.x to 3?

The other question I have is: how concerned are type designers with using an unsupported and/or outdated scripting language? My hunch is that there's not a lot of excitement about updating old scripts that are working fine, but I can see the day when Python 2.x might no longer be the default install on new hardware. If that's the case, it's going to start to feel funny installing an old version of Python to handle modern type design workflows…

Comments

  • People will probably start using it when python 3 comes preinstalled on there system.
  • Chris LozosChris Lozos Posts: 1,135
    Meaning "cart and horse"? What would be compelling reasons to switch or stay?
  • But if the developers of these projects, or the type design community, waits until Python 3 is the default install, we're going to be in a bit of a bind. Either everything will have to be updated at once at that point (lame), or individuals will have to downgrade their Python install (also lame). The latter seems like what most people will take as the path of least resistance, and we'll effectively be stuck at 2.7…

    @Chris, the reasons to switch are mostly just to keep up with the development of the language. Usually major point releases are moments where inconsistencies and warts in the language can be cleaned up. The language becomes a bit nicer to work with. The differences between 2.7 and 3 aren't actually that large, but in the long term Python 3 will continue to be improved, but development on 2.x will cease.

    The reasons to stay is the inertia of a large library of 2.x scripts. There are programs that can convert 2.x to 3, but the libraries that we all use would have to be updated first.
  • James PuckettJames Puckett Posts: 1,623
    …but the libraries that we all use would have to be updated first.
    So then a very important issue is the Robofab developers actually having the time and money to update their code.
  • Agreed re: Robofab development. Sounds like a kickstarter type of thing is necessary
  • Luckily, RoboFab seems to have a pretty good test suite. There are tools to convert 2.7 scripts to 3, and as long as all the tests pass it may be a pretty easy update. If it's possible to make this into a community project it might not have to have as extensive of a Kickstarter budget…

    Still curious if there are other libraries that would also need similar treatment that I am unaware of.
  • FontTools as well…
  • I'm not sure to what extent Defcon would need to be updated.
  • i wouldn't rely too much on 2to3 as a fix, perhaps as a recommendation for new patterns or renamed modules.

    the truth is that migrating code from 2 to 3 is not nearly as traumatizing as it would appear and given the massive amount of code that is presently being written for 2.7 and will need to be supported in the future, i expect it would be a while until the pycopalypse manifested itself as a problem given that people still routinely support python 2.5 which came out in 2006 (boy does time fly).

    migrating to 3 though is entirely something that can happen iteratively and it can happen a handful of files at a time, too, without totally breaking a codebase. Tests do really help, though, for this sort of project.

    The biggest change i have encountered in trying to make code portable between the two is the use of byte strings, slightly different exception handling and the new division behavior. catching importerrors for renamed modules in the stdlib is straightforward.

    again, most patches could be submitted by anyone who currently writes python and is willing to write a unit test and run it against both 2.7 and 3.3 / 3.2. test writing is the easiest way to contribute to a project and it serves as living documentation since it shows functions being (successfully) used in very specific ways.

    I'm not convinced that the amount of work would warrant a kickstarter, but i think getting the community corralled and setting visible goals to write tests and upgrade submodules iteratively would be fantastic.
  • Ben KielBen Kiel Posts: 31
    The RoboFab developers have recently moved the codebase to GitHub (https://github.com/robofab-developers/robofab). Work is happening for UFO3 in the UFO3k branch, a reworking of the documentation is happening in the documentation branch. If someone wanted to start exploring Python3 support please feel free to fork or ask for a new branch to be created. Know that the UFO3k branch, when finished, will be merged into the main branch.
  • Endlessly curious why this coversation is posted here and not in "Software".
  • James PuckettJames Puckett Posts: 1,623
    Fixed.
  • Hmm… I don't even remember choosing a category… my apologies that it went to the wrong place.

    Ben: What parts of robofab need the most help at this point? Are there outstanding bugs? Better test coverage? I'd like to get involved but not sure what would be helpful.
  • Ben KielBen Kiel Posts: 31
    Jack: I'm not sure what is most helpful at this point. Things are fairly stable currently. There's the ticketing any bugs you've run into. I should say that discussion of development and questions happens mostly on the mailing list, http://groups.google.com/group/robofab, rather than any forum. If you ask there, others may have ideas for things that need doing that I'm forgetting/unaware of.
Sign In or Register to comment.