Python in 2017 - Whats next?

2017 is approaching slowly and before it comes a new version with Python. The winter holidays give you the opportunity to take a look at the new release. In this article I introduce some new functionality which can come in handy with the new version: Python 3.6 with the planned release on 16th December 2016.

3.6

Early adopters can already try the beta version or switch directly to the new release when available. For the examples in this section I will use the currently available version: 3.6.0rc1

Python 3.6.0rc1 (v3.6.0rc1:29a273eee9a5, Dec  7 2016, 05:07:52) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.

Although it is a minor version it will bring interesting changes. Let me mention some I think will be useful for all of you.

Underscores in numeric literals

This is a great feature in my eyes. I liked it in Java and I think it’s great for Python too. Using underscores in numeric literals improves readability.

I bet you have read code or output with large numbers, and you have had to count how many numbers there are to see what number it is. Now underscores help you to make things clearer:

>>> 0x_CF_D7_07_8C_F2
892665826546
>>> 111_111_111_111_111
111111111111111

As you can see, you can define numbers with underscores. The good (or bad?) thing is, if you misplace an underscore it works too: you get a valid number and no error is raised:

>>> 1_111_111_11_111
111111111111

This is good because you can represent hexadecimal numbers (like the one example above) which not necessarily require 3 digits every time, for example when writing RGB colors. However you can easily get an error in your execution logic if you miss a number.

Well, it is really seldom to write code with such large numbers. But I mentioned that it works while formatting strings and this is what can be adopted in the future too:

>>> '{:_}'.format(1111111111111111111111111)
'1_111_111_111_111_111_111_111_111'
>>> '{:_x}'.format(892665826546)
'cf_d707_8cf2'

As you can see in the example above, to format a number you have to specify :_ in the format placeholder to have a normal decimal number formatted with underscores. To format into a hexadecimal representation you have to add :_x, where the x part denotes that we want a heXadecimal.

In my opinion this makes big numbers formatted more readable.

New implementation of dict

Although you won't notice anything out of this I wanted to mention that not only new functionality is added to the core Python modules but old constructs are updated too if the need arises and something can be gained from it.

Here the idea came from PyPy, and the new implementation reduces the memory usage of dictionaries by 20-25% compared to Python 3.5.

Keyword argument order

With the new version of Python the keyword arguments are passed along in the same order as you have added them to the dictionary.

Let's see an example to make this clear:

>>> def a_function(a, **kwargs):
...     for k in kwargs:
...         print(k, kwargs[k])
...
>>> a_function('ni', spam=0, eggs=3, sausage=1, bacon=2)
eggs 3
bacon 2
spam 0
sausage 1

Currently it works like the code snippet above. As you can see, the order of the provided keyword arguments is not preserved. Naturally there are ways to solve this problem in the current version too:

>>> def a_function(a, kwargs):
...     for k in kwargs:
...         print(k, kwargs[k])
...
>>>

Note, that in this example we removed the two asterisks from the kwargs arguments. This means that we accept only one argument which contains the optional arguments. The type of this argument could be an ordered dictionary for example:

>>> from collections import OrderedDict
>>> kwargs = OrderedDict()
>>> kwargs['spam']=0
>>> kwargs['eggs']=3
>>> kwargs['sausage']=0
>>> kwargs['bacon']=2
>>>
>>> a_function('ni', kwargs)
spam 0
eggs 3
sausage 0
bacon 2

This preserves the order of arguments provided.

Now back to the original example and Python 3.6:

>>> def a_function(a, **kwargs):
...     for k in kwargs:
...         print(k, kwargs[k])
...
>>> a_function('ni', spam=0, eggs=3, sausage=1, bacon=2)
spam 0
eggs 3
sausage 1
bacon 2

As you can see, there is no need for an ordered dictionary because the provided arguments are in the order you called the function.

UTF-8 on Windows

In previous versions of Python the encoding did not default to UTF-8 on Windows platforms. You can verify this with the following command on a Python 3.5 or earlier:

>>> import sys
>>> sys.getfilesystemencoding()
'mbcs'
>>> sys.stdout.encoding
'cp850'

'mbcs' refers to Multibyte Character Set which is used on Windows systems and should not be used in new projects because it is legacy.

To conform every operatind system's default, Python introduces UTF-8 as the new default encoding in Windows too:

>>> import sys
>>> sys.getfilesystemencoding()
'utf-8'
>>> sys.stdout.encoding
'utf-8'

This change is not only for the file system but for the console too.

But what is the fuzz about it? Well, this change allows us to print and input the full range of unicode characters on the Windows console and files -- so you do not lose important information. In the background there were some changes made to the parsing of the tokenizer to handle the new encoding.

Let's see an example to clarify all this (note that you have to change to the font Lucida Console to make Windows display the letters right): we will use the String 'árvíztűrőtükörfúrógép' which contains some UTF-8 characters.

With Python 3.5 it looks like this:

>>> print('árvíztűrőtükörfúrógép')
árvízturotükörfúrógép

As you can see, some characters got converted to a simple one and we have lost information.

>>> print('árvíztűrőtükörfúrógép')
árvíztűrőtükörfúrógép

With Python 3.6 the console maintained the special characters and we did not lose information.

>>> open('tetű.txt', 'wb').close()
>>> import glob
>>> glob.glob('tet*')

The example above tests the file-encoding change. This is same for both versions, the result however differs:

Python 3.5: [tetu.txt']

Python 3.6: ['tetű.txt']

As you can see, with the new version the unicode character is maintained in the filename too.

By the way 'tetű' is the Hungarian word for louse.

3.7

Besides all this Python 3.7 is already in the alpha phase. There is no release schedule available yet but if the developers can keep up the pace they could release this version at the end of 2017 but I think it will be only maximal a beta release, not a complete one.

Conclusion

We have seen that even if 2017 is coming the Python developer team does not stop working on new features and enhancements. We have taken a brief look on new things coming with Python 3.6 which can be used in the future to make code better.

Naturally this is only a brief excerpt of the new features which will be introduced in the new version. Beside them there are modifications to give better support in asynchronous applications too.