BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Reports from the Field: Python 3 with Hardcoded Software

Reports from the Field: Python 3 with Hardcoded Software

This item in japanese

Bookmarks

The production version of Python 3 has been available for about two and a half years. Since it breaks backwards compatibility with the Python 2.x series there has been a lot of mixed reactions to it. To get a developer’s perspective on Python 3 we decided to interview Virgil Dupras.

InfoQ: Can you tell us a little about yourself and how you use Python in your job?

Virgil Dupras: I develop open source cross platform desktop apps with PyObjC and PyQt and I publish them on my website at http://www.hardcoded.net/. I used to work with Delphi, but I switched to Python in 2005 and never looked back.

InfoQ: What was the major reason you switched to Python 3 a year ago?

Virgil Dupras: I love Python and I always wanted to contribute back to it. I'd love to be more involved with core development, but I think I'm just not smart enough. Sure, I can submit patches (and I did submit a few) but the fact of the matter is I seldom encounter bugs in Python, so I seldom have a patch to submit.

So, with all that in mind, I figured that the best way for me to help Python was to be an early Python 3 adopter, and I think I do help. I didn't encounter bugs in Python itself, but I encountered plenty of them in libraries I use. I also did a fair amount of py3k porting for libraries.

InfoQ: Did any of the breaking changes that caused you significant problems when you migrated your code?

Virgil Dupras: The only big problem you'll encounter with Python 3 migration is the str/bytes thing. Don't worry about anything else, it is all easily ported by a adding all appropriate __future__ imports before porting. Well, ok, maybe divisions can be a problem, but cmon! weren't you using "from __future__ import division" already?

But the str/bytes thing, it's real tricky. You really have to think about how you use your strings before you port. One nasty gotcha: the "re" library only works with strings, not bytes. So if you were using regular expressions to parse "semi-binary" data, you're in trouble.

But unless you're in one of those "gotcha" situations, taking care of str/bytes is relatively straightforward: Take care of your literals, and then review all your "open()" calls and see if they should be opened in binary or text mode.

InfoQ: Are they Python 2 features that you like that didn’t make it into Python 3?

Virgil Dupras: No, it's the same language, with less kinks.

For more on cross platform development UI development see Virgil’s article Cross-Toolkit Software.

Rate this Article

Adoption
Style

BT