Showing posts with label porting. Show all posts
Showing posts with label porting. Show all posts

Saturday, September 29, 2012

Python 3.3 is my Favorite Python Release

Today, Python 3.3 was released. During the 4.5 years I've been a CPython core developer, 6 major Python releases (2.6, 2.7, 3.0, 3.1, 3.2, and 3.3) have past by me. In this post, I will explain why 3.3 is the most exciting Python release to me. I will be cherrypicking, consult "What's New in Python 3.3" and the Misc/NEWS file for complete details.

Unicode

PEP 393 completely changed the internal format of Python's Unicode implementation. It does away with the concept of wide and narrow unicode builds. The encoding of a string now depends on its maximum codepoint; there are 1-byte, 2-byte, or 4-byte strings internally. This means, for example, that strings with only ASCII characters can be represented in their most compact format. Partially as a consequence, Unicode standard compilance has improved. Indexing strings always gives code points not surrogates like on < 3.3 narrow builds. str.lower(), str.upper(), and str.title() have been fixed to use full Unicode case-mappings instead of the simple 1-1 ones. The str.casefold method implements the Unicode casefolding algorithm.
If the gods of PyCon talk selection smile on me, I will be giving a talk about this and the history of Unicode in Python.

Glorious Return of the "u" Prefix

Python 3.3 allows the u in front of strings again. Since the b prefix is supported from Python 2.6, code which wants to support 2.x and 3.3 shouldn't need to use unpleasant kludges like six's u() and b() functions. I don't think it would be unreasonable for libraries to only support 2.7 and 3.3+ now just to have the more natural string syntaxes.

Many Nice Things

One of the annoyances in previous Python 3 versions was it was impossible to turn off PEP 3134's implicit exception chaining. The raise exc from None syntax introduced in 3.3 prevents the __context__ of an exception from being printed.
There were improvements in exceptions themselves. PEP 3151 merged IOError, OSError, WindowsError, and various error types in the standard library. It also created a hierarchy of specialized exception subclasses. This means that most code dealing with IO errors won't have to dig into the errno module. For example, this standard pattern
try:
    fp = open("data", "rb")
except OSError as e:
    if e.errno != errno.ENOENT:
        raise
    # Create file
can become
try:
    fp = open("data", "rb")
except FileNotFoundError:
    # Create file
. (Of course, for this sort of thing you can also use the new "x" mode in open().) The errors from incorrect call signatures have improved:
Python 3.3.0+ (3.3:7e83c8ccb1ba, Sep 29 2012, 10:34:54) 
[GCC 4.5.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> def f(a, b, c=5, *, kw1, kw2): pass
... 
>>> f(1, kw2=42)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() missing 1 required positional argument: 'b'
>>> f(1, 2, kw2=42)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() missing 1 required keyword-only argument: 'kw1'
In the future, I think there should be a ArgumentsError subclass of TypeError which provides programmatic access to the signature mismatch, but this is a start. The new standard library modules, ipaddress, lzma, a dn unittest.mock are certainly worth a look.
The Windows installer has an option to set up PATH for you.







Saturday, November 20, 2010

New version of six, lean and mean

I just released a new version a of six, my Python 2/3 compatibility library. The main feature in this release has that six has been flattened into one source file on the philosophy of "flat is better than nested" and for ease of distributing in projects. I've also switched from Bazaar to Mercurial, since the latter seems more popular and it's all the same to me. The issue tracker and source code is no on BitBucket.

I'm calling this version, 1.0.0 beta 1. Assuming no one complains, I think I'd like to release a final version in the next month or so.

Your feedback is appreciated.

Tuesday, June 29, 2010

Six: Python 2/3 compatibility helpers

Increasingly, I've seen a movement towards supporting Python 2 and Python 3 in the same code base. Having ported a few projects myself, I decided to collect the code I've duplicated between them into a library. The result is six. It includes fake byte and unicode literals, b() and u() and has wrappers for syntax changes such as print and exec. You can check out the documentation on PyPi.The license is MIT, so I hope it can see wide use in projects planning to support Python 2 and 3 simultaneously.

Thursday, December 11, 2008

Get help porting your package!

To help the community with porting their packages to Python 3, we have created the python-porting mailing list. Many core developers are subscribed to the list, so you should be able to get excellent advice on 2to3, the bytes/unicode split, C-API, or other incompatibilities.