Title

class: center, middle

# Python 3

Lumír Balhar (@lumirbalhar)

frenzy.madness@gmail.com

Python SW engineer at Red Hat
???
Python maintenance team. We have a vatious lenght of responsibilities from packaging
to maintaint Python stack in RHEL and Fedora to help upstream projects and tech Python
Main responsibility is to help various upstream projects with issues related to supporting Python 2 and 3
---
class: center, middle

# History of Python

### Implementation started in 1989
### First published version (0.9.0) in 1991

Same year of release as the **first Web page**,  
the **first Linux kernel** (0.01) or **Visual basic**

???
Actually same as year of my birth, which cannot be a coincidence :D
---
class: center,  middle

# Python 3.0

### First backward incompatibile release

### Released in 2008

In the same year **GitHub** was founded, first mobile phone with **Android** (HTC Dream) was released and Intel announced the **Intel Atom** family of processors.

???
Drop of backwards compatibility may looked unresonable but I want to talk about reasons for this step today and I'll show you why this was a good idea.
---
class: center, middle

# Why backward incompatibile?
    
### "There should be one- and preferably only one -obvious way to do it"
???
Python 3.0 was developed with the same philosophy as in prior versions. However, as Python had accumulated new and redundant ways to program the same task.
This is one of the most important rule in zen of python and a lot of changes in Python itself are driven by this rule. If you don't know zen of python and want to read the rest, just do `import this` in the python console.
---

# `print`
???
Lets start with some basics
--

## Python 2

```python
print "Hello world"
```
???
Like very simple usage of print
--

## Python 3

```python
print("Hello world")
```
???
Ok, you may argue: was it really necesary to change print from statement to funciton? Even when print is the first thing everybody lear in Python?

This may look unresonable but what about using more complex print?
---

# More complex `print`

## Python 2

```python
print >> sys.stderr, 'Hello world'
```
--

## Python 2 again

```python
print >> sys.stderr, 'Hello world',
```
???
If you want to print to standart error output and you don't want to add a line break at the end of the line, you end with something like this which looks horrible and it is really hard to understand what this construct does.
--

## Python 3

```python
print("Hello world", end="", file=sys.stderr)
```
???
But in Python 3 you have just function with keyword arguments. You may ask why print wasn't function from beggining - the reason is that in early stages of Python development functions didn't support variable lenght of arguments.
---

# Handling exceptions

#### Single exception

```python
try:
    a = 1/0
except ZeroDivisionError:
    print "You can't divide by zero! Only Chuck Norris can do!"
```
???
If I want to handle single exception without storing it in variable, it is quite simple.
--

#### Two exceptions

```python
try:
    a = 1/"test"
except ZeroDivisionError, TypeError:
    print "You can't divide by zero or by string!"
```
???
I can remember that there was comma to separate things in exceptions handling so it looks as a good idea to separate exceptions by comma. But does it work? No! It uses TypeError as a name of variable where exception will be stored.
--

#### Correct way

```python
try:
    a = 1/"test"
except (ZeroDivisionError, TypeError), e:
    print "You can't divide by zero or by string!"
```
???
This is a correct way how to handle more than one exception type in one except statement and I am pretty sure that sytax with commas only could be confusing for new python user.
---

# Python 3 syntax (backported to 2.6+)

```python
try:
    a = 1/"test"
except (ZeroDivisionError, TypeError) as e:
    print("You can't divide by zero or by string!")
```
???
Situation described on previous slide is a good reason for changing syntax to be more straightforward than just commas so Python 3 came with `as` keyword as separator between exception types and variable name to store exception in.
---

# Exception chains

```python
class ConfigNotFoundError(Exception):
    pass

def open_config_file():
    open('missing.conf')

def c():
    try:
        open_config_file()
    except IOError as e:
        raise ConfigNotFoundError(e)

c()
```
???
Imagine you have this simpel module created to load configuration from file. And you want to catch IOError exception and raise your own exception describing that configuration file wasn't found.
...

---

# Python 2 traceback

```python
Traceback (most recent call last):
  File "/tmp/pasted.py", line 13, in <module>
    c()
  File "/tmp/pasted.py", line 11, in c
    raise ConfigNotFoundError(e)
```
???
In Python 2 you have only this short traceback and it can be really hard to find bug in big codebase where one exceptions may occur during another exception handling.
---

# Python 3 traceback

```python
Traceback (most recent call last):
  File "/tmp/pasted.py", line 9, in c
    open_config_file()
  File "/tmp/pasted.py", line 5, in open_config_file
    open('missing.conf')
FileNotFoundError: [Errno 2] No such file or directory: 'missing.conf'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/tmp/pasted.py", line 13, in <module>
    c()
  File "/tmp/pasted.py", line 11, in c
    raise ConfigNotFoundError(e)
__main__.ConfigNotFoundError: [Errno 2] No such file or directory: 'missing.conf'
```
???
In Python 3 you have a complete traceback with all exceptions raised.
This behaviour is possible because in Python 3 exceptions is stored in one object copletely and this object contains name, type and complete traceback, so it is possible to create a chain of multiple exceptions which makes finding bug much easier.
---

# Sorting

## using `cmp` (Python 2)

```python
def compare(a, b):
    """Comparison of last names"""
    return cmp(a.split()[-1], b.split()[-1])
names = ['Adam Smith', 'Donald Brown', 'John Silver']
print(sorted(names, cmp=compare))
```

???
CMP keyword argument for .sort() method or sorted() function is here to compare two items during sorting. CMP funtion has a visible disadvantage because it is called every time when comparison of two items is needed during sorting. This may cause a performace problem when function for comparison is complex or the dataset is big.
--

## using `key` (Python 2 and 3)

```python
def get_last_name(full_name):
    return full_name.split()[-1]
names = ['Adam Smith', 'Donald Brown', 'John Silver']
print(sorted(names, key=get_last_name))
```

???
So there is another posibility how to achieve this. Key keyword argument is here to return key for each element. Visible advantage is that the function returning key has to be executed only once for every item during sorting.
And because this two approaches do same task, cmp function and cmp keyword argument for .sort() method and sorted function has been removed in Python 3.
---

# Copmarison of objects

```python
class Orderable(object):

def __init__(self, firstname, lastname):
        self.first = firstname
        self.last = lastname

def __cmp__(self, other):
        return cmp((self.last, self.first),
                   (other.last, other.first))

sorted([Orderable('Donald', 'Duck'), Orderable('Paul', 'Anka')])
```

???
There is one more thing which has been removed from Python 3 related to comparison and sorting - special `__cmp__` method for implementing comparison for your own objects.
--

Usin `cmp`, we can only implement total ordering

---

# Old `cmp`-based comparison

* `__cmp__` for everything

# Rich comparison (since Python 2.1)

* `__lt__` for **`<`**
* `__le__` for **`<=`**
* `__eq__` for **`==`**
* `__ne__` for **`!=`**
* `__gt__` for **`>`**
* `__ge__` for **`>=`**
* `__cmp__` as a fallback

???
Because for special cases you may want to implement only some of comparions operators, rich comparison is in Python since version 2.1. And again we have more than one way how to implement comparion so the `__cmp__` method has been removed.

# Python 3

* `cmp` was removed

---
class: center

# Data formats

## Images

JPG, PNG, BMP

## Music

MP3, OGG, WAV

## Text?

UTF-8, ASCII, Shift-JIS

???
All of you know a lot of data formats for different file types. For example

Data format is just a way how to store data byte by byte on disk or how to send the data throw network.

But what about text? For a lot of developers text are only sequence of bytes but is that true?

---
class: center

# You can pretend that text is only sequence of ASCII chars and store it as bytes

# And then you meet Filip K<font color="red">łę</font>bczyk

## Also, you cannot ignore emoji 😎

### that would make your users 😢

---
class: center, middle

# Plain text is a myth

---
class: center, middle

## Python 3 contains:

### \- `str` type for text

### \- `bytes` type for binary data

???
Because Python upstream developers know that text is much more than only bytes, Python 3 contains two different types - unicde for text and bytes for raw data. This may be a most important part of porting codebase to Python 3 because you have to decide if you want to store data or text in variable. This is also a hard nut to crack during porting samba because you need to understand the code very well before you can decide which type is better.
---
class: middle

# Changes in the standard library

| Python 2 name          | Python 3 name |
|------------------------|---------------|
| `__builtin__`          |`builtins`     |
| `ConfigParser`         |`configparser` |
| `cStringIO.StringIO()` |`io.StringIO`  |
| `raw_input()`          | `input()`     |
| `xrange()`             |`range()`      |
| `reduce()`             |`functools.reduce()` |

???
There are also a lot of changes in standard library names. This table is just an example of a few changed names.

---
class: center, middle

# How to handle the changes?

---
class: center

# Porting strategies
???
Ok, now you know that you really want to support Python 3 and you probably cannot drop support for Python 2 in one day. So there are some strategies how to achieve this goal.
--

## Support only Python 3

## Maintain separated codebase (branches)

## Convert with 2to3 or 3to2

## Write compatible code

---
class: center, middle

# Conservative porting guide

## [portingguide.readthedocs.io](http://portingguide.readthedocs.io/en/latest/)

???
Conservative porting guide is online documentation projet contains a lot of interesting information about supporting codebase for Python 2 and Python 3 and also a guide how to use python-modernize tool to make you code more compatible.

---
class: center, middle

# `six` library

## [pythonhosted.org/six/](https://pythonhosted.org/six/)

### simple utilities for wrapping over differences between Python 2 and 3

#### (2 * 3 == 6)

???
When you want to write compatible code, sonner or later you will need Six. Six is a Python library which may help you a lot during writing compatible code. Six contains only one Python file with a lot of handy variables and wrappers.

---
class: center, middle

# Thank you!

# Questions?

## [portingguide.readthedocs.io](http://portingguide.readthedocs.io/en/latest/)