#76 Goodbye zero-versioning

Sponsored by Datadog: pythonbytes.fm/datadog

Brian #1: Unlearning toxic behaviors in a code review culture

• unhelpful behaviors:
  • passing off opinion as fact
  • overwhelming with an avalanche of comments
  • asking people to fix problems they didn’t cause “while they’re at it”.
  • asking judgmental questions
  • being sarcastic
  • using emojis
  • not replying to comments
  • ignoring (not calling out) toxic behavior from high performers
• helpful:
  • use questions or recommendations to drive dialog
  • collaborate, don’t back-seat drive
  • respond to every comment
  • know when to take a discussion offline
  • use opportunities to teach, and don’t show off
  • don’t show surprise of lack of knowledge by others
  • automate what can be
  • refuse to normalize toxic behavior
  • managers: hire carefully, listen to your team, and enforce
  • set the standard as your team is small and growing
  • understand you might be part of the problem

Michael #2: Flask 1.0 Released

• Dropped support for Python 2.6 and 3.3.
• The CLI is more flexible. FLASK_APP can point to an app factory, optionally with arguments. It understands import names in more cases where filenames were previously used. It automatically detects common filenames, app names, and factory names. FLASK_ENV describes the environment the app is running in, like development, and replaces FLASK_DEBUG in most cases. See the docs to learn more.
• If python-dotenv is installed, the flask CLI will load environment variables from .flaskenv and .env files rather than having to export them in each new terminal.
• The development server is multi-threaded by default to handle concurrent requests during development.
• flask.ext, which was previously deprecated, is completely removed. Import extensions by their actual package names.
• Accessing missing keys from request.form shows a more helpful error message in debug mode, addressing a very common source of confusion for developers.
• Error handlers are looked up by code then exception class, on the blueprint then application. This gives more predictable control over handlers, including being able to handle HTTPException.
• The behavior of app.logger has been greatly simplified and should be much easier to customize. The logger is always named flask.app, it only adds a handler if none are registered, and it never removes existing handlers. See the docs to learn more.
• The test_client gained a json argument for posting JSON data, and the Response object gained a get_json method to decode the data as JSON in tests.
• A new test_cli_runner is added for testing an app's CLI commands.
• Many documentation sections have been rewritten to improve clarity and relevance. This is an ongoing effort.
• The tutorial and corresponding example have been rewritten. They use a structured layout and go into more detail about each aspect in order to help new users avoid common issues and become comfortable with Flask.
  • There are many more changes throughout the framework. Read the full

Brian #3: So, I still don’t quite get pipenv, ….

• Best discussion of why pipenv is useful for applications I’ve come across so far is Pipenv: A Guide to the New Python Packaging Tool
• Starts with a discussion of situations where pip, pip freeze, and requirements.txt fall apart.
  • requirements.txt often just have an applications direct dependencies, not sub-dependencies.
  • pip freeze > requirements.txt will pin your versions to specific versions, but then you’ve got to keep track of dependencies and sub-dependencies.
  • Pipfile intends to replace requirements.txt, with a simple-ish human readable format. Also includes extra things like dev environment support.
  • Pipfile.lock intends to replace pinned requirements.txt files. Also includes hashes to validate versions haven’t been corrupted.
  • pipenv also includes cool tools like dependency graphing, checking for updates, etc.
• pipenv should be used for applications, but not packages intended to be included in other applications. But you can use it during package development, just probably not include the Pipfile and Pipfile.lock in the repo or package distribution. - Brian’s comment

Bonus extra:

• cookiecutter-pipenv: Cookiecutter Python Package Template with Pipenv

Michael #4: GraalVM: Run Programs Faster Anywhere

• Why?
  • Current production virtual machines (VMs) provide high performance execution of programs only for a specific language or a very small set of languages.
  • Compilation, memory management, and tooling are maintained separately for different languages, violating the ‘don’t repeat yourself’ (DRY) principle.
  • high performance VMs are heavyweight processes with high memory footprint and difficult to embed.
• Oracle Labs started a new research project for exploring a novel architecture for virtual machines. Our vision was to create a single VM that would provide high performance for all programming languages, therefore facilitating communication between programs.
• Released: GraalVM, a universal virtual machine designed for a polyglot world.
• GraalVM provides high performance for individual languages and interoperability with zero performance overhead for creating polyglot applications.
• GraalVM 1.0 allows you to run:
  • JVM-based languages like Java, Scala, Groovy, or Kotlin
  • JavaScript (including Node.js)
  • LLVM bitcode (created from programs written in e.g. C, C++, or Rust)
  • Experimental versions of Ruby, R, and Python
• Future: This first release is only the beginning. We are working on improving all aspects of GraalVM; in particular the support for Python

Brian #5: Testing a Flask Application using pytest

• Small demo project, and article, that teaches the use of pytest in Flask.
• unit testing and functional testing
• Article covers testing models, with an example of a new user.
• project also has examples of using a test client to check the login page, password authentication, and a lot more.
• Very cool project.

Bonus: A cool new pytest plugin: pytest-caprng

• Tests that use random or np.random may fail, but when you re-run them, they don’t fail, which makes them hard to debug.
• This plugin adds pytest flags --caprng-global-stdlib and --caprng-global-np, which saves the random state before each test so that if you re-run the test, the random-ness is not so random, and you can reproduce your failure.
• Also, thanks John for reminding me what “stochastic” means.

Michael #6: How to have a great first PyCon

• Spending your time: which talks should I go to? The talks at PyCon are typically uploaded to YouTube within 24 hours after the talk ends. I am suggesting that you don’t need to worry about attending every talk.
• Open spaces: attend them and consider hosting your own!
• There are a few reasons I often pick open spaces over talks:
  • Often the open spaces are more niche and topical than the talks: there are some subjects that exist in open spaces every year but which I’ve never seen a talk on
  • Open spaces are all about interaction and discussion whereas talks are a monologue that often evolves into subsequent dialogues
  • Open spaces aren’t recorded whereas the talks are, meaning you can’t really catch up on them later
• Tips for starting conversation, breakfast and lunch time…
• The hallway track