What an IronPython user should know about Python 3

No conflicts between different platoons

By Cameron Laird  2 comments

The audience asked questions about "Python 3" when I talked last week about "IronPython and .NET" for the HDLUG. Here's an amplified version of what I said then:

Programming in Python 3 much like previous Pythons

Python 3 represents Guido's liberation. Guido van Rossum, Python's inventor and continuing lead, has been scrupulous about backward compatibility for twenty years. Finally, with Python 3 (also called "Python 3.0" or, in older and more playful documents, "Python 3000"), he is free to change parts of Python that he now regards as blemishes. For us application programmers--or at least for me--Python 3 feels little different from previous releases. Many of the most profound changes have to do with "internal" clean-up that'll make a better basis for future development of Python as a language. "Clean" has always been an important qualification in Python's history; there's far more emphasis on getting the right features, than more features.

While Python 3 does offer new functionality, it doesn't change the daily routine of working in Python. Beside that, there's been an extraordinary effort to port new features back to the 2.x series of releases, so that 2.6, 2.7 and 2.8 can boast nearly all of the important syntax of 3.0 and 3.1.

IronPython separate-but-nearly-equal

Van Rossum works in CPython. That is, while in principle he defines the abstract Python language, in practice everyone know that means something like, "the core C-coded implementation". IronPython is maintained separately, and has no necessary relationship with van Rossum's work in schedule or source code. The two development crews are certainly friendly, though, and generally are able to track changes rather closely.

To this point, IronPython has emphasized 2.x as a target. As Jimmy Schementi, a Program Manager with Microsoft, e-mailed me last week, "IronPython's roadmap over the next year includes compatibility with Python 3. Also, we're planning on a release ... before our first 3.2-compatible release which will target 2.7 compatibility."

What does all this mean for you? Should you use Python 3.x or 2.x in your next project? I asked several experts that question a half-year ago; their predictable answer was, "it depends". Briefly, if you rely on an extension to standard Python, you're probably stuck back in 2.x. Otherwise, though, there's no reason not to jump to the latest 3.1 or even 3.2.

2 comments

    Anonymous 1 year ago
    One of the 'Big Problems' people have in transitioning from Python 2 to Python 3, is the jump from string literals being in ASCII, to string literals being in unicode. In CPython 2.x, ASCII string data objects are sometimes used as generic buffers for communication with outside data sources. Python 3 requires the use of a "byte" object for that purpose. In IronPython, string literals are in unicode, and the "byte" class is fully implemented, so IronPython code is fully compatible with Python 3 code in this important area. If an IronPython programmer simply inserts"from __future__ import print_function"at the beginning of each program, she can write perfectly good Python 3 programs today.
    claird
    claird 1 year ago
    We're now maintaining a Wiki page on the subject of 2-vs.-3 at http://wiki.python.org/moin/Python2orPython3. I recommend it.

      Add a comment

      Post a comment using one of these accounts
      Or join now
      At least 6 characters

      Note: Comment will appear soon after you have activated your account.
      Obscene/spam comments will be removed and accounts suspended.
      The information you submit is subject to our Privacy Policy and Terms of Service.

      ITworld LIVE

      DevelopmentWhite Papers & Webcasts

      White Paper

      HP NonStop SQL Fundamentals whitepaper

      This whitepaper offers a detailed look into the fundamentals of HP NonStop SQL solutions. See how this system delivers unprecedented levels of application availability with fail-safe data integrity and meets the needs of enterprises with large-scale business critical applications.

      White Paper

      Nebraska Medical Center case study

      See how the Nebraska Medical Center implemented a SQL solution to make information more readily available to streamline operations, improve patient care and facilitate medical research with an enterprise solution running on HP NonStop servers.

      White Paper

      Concepts of NonStop SQL/MX

      For DBAs and developers who are familiar with Oracle solutions and want to learn about NonStop SQL/MX, this whitepaper provides an overview of the similarities and differences between the two products-with a specific focus on implementation.

      White Paper

      6 Things Your CIO Needs to Know About Requirements

      If your organization is not predictably successful on technology projects, there is likely an issue in requirements. CIOs must take action and own requirements maturity improvement. There are 6 main things a CIO must know about requirements.

      Webcast On Demand

      User Experience Monitoring

      In this webinar, you will learn hints & tips for improving end-user response times from Forrester Research analyst, Jean-Pierre Garbani.

      Sponsor: Nimsoft

      See more White Papers | Webcasts

      Ask a question

      Ask a Question