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

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • I was wrong about bytes and regexp

    by Virgil Dupras,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I'm a bit embarrassed because it's not true that you can't do regexp on bytes. I mentioned it because that was my problem of the moment and I didn't do proper research first.

    You can perform regexp operations on bytes, but you have to use byte patterns. That also cause its own share of problems because many regexp-based libraries assume strings for patterns.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT