Pythonity Blog Pythonity Blog

What's New in Python 3.5 and 3.6

Python 3.4 was released on 16 March 2014, more than two years ago but I've been using it for a while, mainly because it's the latest Python 3 available in official Ubuntu 14.04 repositories, which is our choice for almost all of our servers and on my previous desktop OS elementary OS 0.3 Freya by extension. Sure, there are custom user made PPA's, but adding it by hand everywhere didn't seem like a fun thing to do, especially since we don't (yet?) use the features that Python 3.5 introduced, and that Python 3.6 will introduce.

But two years is a lot and as I explained in my previous post I recently switched to OS X, installed pyenv and suddenly every Python version released was at my fingertips. So let's go through the best features in Python 3.5 and Python 3.6 and see weather a change is something you should also consider, especially with new Ubuntu LTS (16.04).

Python 3.5

PEP 492 - Coroutines with async and await syntax

PEP 492 greatly improves support for asynchronous programming in Python by adding awaitable objects, coroutine functions, asynchronous iteration, and asynchronous context managers. Inside a coroutine function, the new await expression can be used to suspend coroutine execution until the result is available. Any object can be awaited, as long as it implements the awaitable protocol by defining the await() method.

This is the big one, proper asynchronous programming in Python. I never got around to actually using it in a project, but I recently dabbled in it a bit and liked it quite a lot. I also really liked this article by Brett Cannon - Python core developer - on how it works under the hood.

PEP 465 - A dedicated infix operator for matrix multiplication

Matrix multiplication is a notably common operation in many fields of mathematics, science, engineering, and the addition of @ allows writing cleaner code.

Never needed to use it, but from what I understand it is a very helpful feature, especially to all people that use Python in scientific environments.

PEP 484 - Type Hints

Function annotation syntax has been a Python feature since version 3.0 (PEP 3107), however the semantics of annotations has been left undefined. While these annotations are available at runtime through the usual annotations attribute, no automatic type checking happens at runtime. Instead, it is assumed that a separate off-line type checker (e.g. mypy) will be used for on-demand source code analysis.

Another feature that I didn't have the chance to use. I did see it extensively used in Errbot source code though, and was intrigued by it since then.

collections.OrderedDict is now implemented in C, which makes it 4 to 100 times faster.

A small change, but I happen to use OrderedDict quite a lot so this is very nice to see.

Python 3.6 (not yet released)

PEP 519: Adding a file system path protocol

File system paths have historically been represented as str or bytes objects. This has led to people who write code which operate on file system paths to assume that such objects are only one of those two types. (...) To fix this situation, a new interface represented by os.PathLike has been defined. By implementing the fspath() method, an object signals that it represents a path.

You can't really escape from dealing with paths, whether in CLI tools or in web applications, so I'm looking forward to playing with this.

PEP 498: Formatted string literals

Formatted string literals are a new kind of string literal, prefixed with 'f'. They are similar to the format strings accepted by str.format(). They contain replacement fields surrounded by curly braces. The replacement fields are expressions, which are evaluated at run time, and then formatted using the format() protocol.

As small of feature as it is, I had mixed feelings about this for a long time. On one hand there are already too many ways to format strings which I don't like, especially in language that uses There should be one-- and preferably only one --obvious way to do it. as one of its principles.
On the other hand - I love this, as I usually use the same variable names and f'He said his name is {name}.' is much cleaner then 'He said his name is {name}.'.format(name=name) or 'He said his name is {}.'.format(name).

Optimization!

'Nuff said.

Comments