Brett Cannon

Python core developer. Tall, snarky Canadian.

Read this first

Moving my blog to Silvrback

I have been using Svbtle since it opened up to the public and in general I have enjoyed it. It’s has a very clean design and you get to blog in Markdown which is great when you typically talk about code.

But I have been wanting to set up a custom domain for my blog which typically requires paying for blog hosting (which I’m fine with). And if I’m going to be putting money into something I want to make sure it’s the best I can get for the money I’m spending. And that’s when I found Silvrback.

Basically Silvrback does everything that Svbtle does in terms of features from custom domain to letting people subscribe by email. I still do prefer Svbtle’s overall look, Silvrback isn’t far off. And then there is the fact that Silvrback is USD 30/year while Svtble works out to USD 72/year. Look quibbles aside, I just couldn’t ignore the difference, especially when I have Damian of Silvrback so

Continue reading →


Python 3 support on PyPI

At (and since) PyCon 2015, there has been interest in trying to get quantified numbers in relation to Python 3 adoption (see PyPI download numbers and uptake in the astronomy community). One number I am personally interested in is per-project adoption of Python 3. While the Python 3 Wall of Superpowers shows wide support for Python 3 with the top projects by download, I wanted to take a larger look at PyPI as a whole to measure project adoption. So I wrote a script that downloads the JSON data for every project on PyPI and then analyzes the data in various ways.

 Methodology

The methodology I used was to classify a project as supporting Python 3 if its trove classifier said it did (in other words, putting a project in the “Python 3” bin means it at least supports Python 3 and may support Python 2 as well), the same goes for Python 2 classifying (although if the project supports Python 3

Continue reading →


Looking at Python 3 usage in the astronomy community

Thomas Robitaille ran a survey on Python usage in the astronomy community and wrote up a great blog post on the results (a big thanks from me to Thomas for taking the time do to this!). The highlights of the survey results are:

  • 17% - 20% of respondents are using Python 3 depending on how you want to count
  • No one really uses any version other than Python 2.7 and 3.4
  • Windows users are better about using Python 3 than Linux and OS X users
  • Seasoned Python programmers are using Python 3 more than new users
  • The biggest reason people give for not using Python 3 is lack of incentives

Now this data is very much skewed towards astronomers using Python, but I still think it’s worth looking at the results as a microcosm of the general community.

 The amount of Python 3 adoption

I have seen PyPI numbers that provide a lower bound of 5% adoption across the community, while I have seen other

Continue reading →


Porting to Python 3 is like “eating your vegetables”

While at PyCon this year, someone pointed out that the hope/goal/expectation when Python 3 was released was to have over 50% of new projects using Python 3 within five years, and that had not come to fruition (while I have not personally crunched the numbers and this was told to me anecdotally, I will just assume they are right). Immediately after pointing this out they said that Python 3 is thus a failure at this point and we need to start figuring out when we call it quits on Python 3. I obviously disagree with this view.

 We can’t predict the future

Just because some prediction didn’t come true does not mean we have lost hope in Python 3. All it means is that the community’s uptake of Python 3 has been slower than we initially thought, and honestly that’s fine. The extension of Python 2.7’s end-of-life to 2020 is an acknowledgment of this slower pace. There are plenty of companies

Continue reading →


Going all-in on the mobile web

In this world of Android vs. iOS – with a smattering of Windows Mobile and Blackberry – I find native apps somewhat annoying. In the beginning, iOS was actually not going have any third-party apps on the phone and everything would run through Safari on your iPhone. Developer backlash due to worries about performance, though, helped lead to Apple changing its position on native apps on iOS.

I think this is a shame. I appreciate that web apps embody SLICE (Secure, Linkable, Indexable, Composable, Ephemeral, and I have heard it suggested that Updatable get tossed in). I also appreciate that the web embodies a common denominator platform that is cross-platform (I’m not naïve enough to think the entire web platform is cross-platform thanks to differences in what APIs are implemented at any given time by the various browsers). Why do developers need to choose whether to launch on iOS or

Continue reading →


Alternative voting systems for Canada

With 2015 bringing a federal election where current polling suggests that either the Liberals or Conservatives could have a minority government based on how people vote, I’m rather interested in how election systems could influence the outcome. Last month there was an article about two alternative voting systems and how they would influence the elections. While reading into these systems I also found out that voting system reform is not a new thing in Canada and that both the NDP and Liberals have actually discussed changing how federal elections work after the 2015 election. With the importance of this election being so high – the Conservatives have been the ruling party since 2006 with a majority since 2011 and so it is expected they will at minimum lose their majority stance – I decided to try and learn what alternative voting systems are being proposed and how they would influence

Continue reading →


Why WhatsApp made its web app use your phone as a server

Ever since WhatsApp announced their web app, I have seen various people complain about having to keep your phone on to send messages. But in all of these posts people seem to be overlooking two key points about the design of WhatsApp which either necessitate this design or at least facilitate WhatsApp in keeping their service lean and fast.

 Encryption

In case you didn’t hear, WhatsApp (supposedly) does end-to-end encryption. That means WhatsApp can’t read what people say in their messages. What this also means, though, is that if someone sends you a message and you have your phone and web app, there is no way to read that message independently of both devices without sharing the decryption key, which is not good security practice. You could have separate keys for your phone and web browser, but then you would then need to make sure to share keys between your phone, your browser, and

Continue reading →


How to get your parents off of Skype using WebRTC

My mother-in-law has a cousin she likes to talk to. Because I like to simplify my tech support requirements by standardizing my entire family on a single platform when possible, all of my immediate family uses Google Hangouts (promoting saving money through free phone calls to the US and Canada also helps). Unfortunately my mother-in-law’s cousin is on Yahoo and Skype and is not that tech-savvy. That means I want a video chat solution that is dead-simple and doesn’t require a common account (if she had a Google account then my mother-in-law could just email a link to a hangout and just reuse that hangout every time).

Luckily it turns out that you can overcome these obstacles thanks to WebRTC. If you don’t happen to know what WebRTC is, think of it as providing real-time voice and video in the browser without plug-ins. On a more technical level, think of it as browser-supported session

Continue reading →


Commentary on getting your code to run on Python 2/3

Today I committed a heavily updated version of the Python 2/3 porting HOWTO. Basically the doc has shifted from suggesting you use 2to3 for gaining Python 3 compatibility for your Python 2 code and instead you aim for a Python 2/3 source-compatible code base using various tools. Read the HOWTO for the details.

This blog post is about how the shift in approach for Python 3 support came about, general timelines on what will (not) be coming in the future to help with porting, and to emphasize that you should start porting your code today no matter what your dependencies say.

 The story behind the shift in direction for the HOWTO

When Python 3 was being developed, python-dev thought a transpiler from Python 2 code to Python 3 code would be the best solution. So we created 2to3 to transpile Python 2 code to Python 3 and structured it so that distutils would do the transpiling at

Continue reading →


The long-term view of Python 2.7

When Python 2.7.9rc1 was released, I shared the news through the +Python Google+ account. Comments on the post ranged from “thanks for keeping Python 2.7 alive!” to “why haven’t you just killed off Python 2.7?” To help frame these discussions, realize that Python 2.7.9 has two big themes:

  1. Getting HTTPS/SSL support and security more in line with Python 3
  2. Adding ensurepip so that pip will be installed alongside Python 2.7.9

If you don’t know the reasoning behind these changes it might seem like we are suddenly adding features to Python 2.7 to help extend its life and keep it relevant. The truth, though, is more nuanced.

We as the Python development team have decided to support Python 2.7 until 2020 (that was announced at PyCon 2014 so hopefully this isn’t news to you). As with other releases of Python, “support” means bugfixes and not new features. So why the heck have we backported

Continue reading →

ssl yes