#82: Let's make a clear Python 3 statement

Published Fri, Jun 15, 2018, recorded Wed, Jun 13, 2018

* GitHub coverage coming at the end! *

Brian #1: Building and Documenting Python REST APIs With Flask and Connexion

Michael #2: MyPy + PyCharm

Written by Ivan Levkivskyi
via Guido van Rossum
Ricky Teachey asks: “What advantages does using mypy bring to pycharm vs just using pycharm's native type checking- which is already pretty good?”
Response:
- mypy is a bit more stricter/precise
- it is more configurable, lots of options regulating type system "rules"
- it typechecks the whole program, so that you immediately see errors your change causes in _other_ files
- people run mypy in CI and want to see the result before push

Brian #3: Automatic code/doc conversion

pyupgrade
- “A tool (and pre-commit hook) to automatically upgrade syntax for newer versions of the language.”
- Can even convert to f-strings with --py36-plus option.
docs
- “Run black on python code blocks in documentation files.”
- blacken-docs provides a single executable (blacken-docs) which will modify .rst / .md files in place.

Michael #4: python3statement

via Bruno Alla
Matthias Bussonnier (Talk Python, episode 44)
- “We now have 44 projects that pledged to drop #python2 in less than 30 months. Some already did ! To see which one, and how to migrate with as few disruption as possible for both Python 2 and 3 users head to http://python3statement.org/ ”
Supporting legacy Python: **it is a small but constant friction in the development of a lot of code.
We are keen to use Python 3 to its full potential, and we currently accept the cost of writing cross-compatible code to allow a smooth transition, but we don’t intend to maintain this compatibility indefinitely.
Nice “Why switch to Python 3?” section and resources
Nice list of participating projects
- Can we get some that are not data science? :)

Microsoft buys GitHub:

Our news and extras:

Full transcript