On Reddit I often see a variation of a conversation like this:

Newbie: I want to write games in Python!

Random person: Python is no good for games. You should use C++ or C#.

The claim that Python is not a good language to write games is not true. It's more accurate to say "Python is not a good language to write games alone."

It is well known that Python trades raw performance for productivity. But if you use it glue together powerful libraries written in faster languages then you can do better - you can have performance and productivity.

Pyweek 25 has been announced for the 15th-21st April this year!

Pyweek is a week-long game jam, in which you must write a game from scratch, in Python, in just one week.

It's online, so you can participate from the comfort of your own home (or bed, if you're extra lazy). Games are rated by other entrants, which means you're guaranteed to get useful feedback on your game, even if you don't win.

Wow, 25 Pyweeks, over 13 years! So far, 972 complete Python games have been submitted. It's something of a tradition in the Python community. It's a very social event. Other entrants are encouraged to write "diaries" about their progress so you can see their games evolve and see how they solve the problems they encounter.

Pygame, Pyglet, Cocos2D - even Godot: there are many libraries in Python for creating games. If you're a beginner, I would recommend Pygame Zero, my easy game framework for beginners. You can also use your own library, but it needs to be published and well-documented 30 days before the contest starts, so roughly in a week from now. Get documenting and uploading!

Why participate in Pyweek? There are many reasons:

• Practice your Python programming
• Try programming something different
• Unleash your creativity
• Finish a real project
• Maybe, just maybe, you could win and get all the kudos

So, why not give it a go? Here's what happens next:

1. Register an account on https://pyweek.org/
2. Submit an entry using the drop-down at the top right under your username.
3. At 00:00 UTC on 2018-04-08, visit the website to find the 5 potential themes. You have a week to think about the themes and decide which you like best.
4. Submit your votes for the themes in order of preference.
5. At 00:00 UTC on 2018-04-15, we find out which theme has won, and coding begins! You now have exactly 168 hours to write a game on the theme that was selected!
6. At 00:00 UTC on 2018-04-22, everyone must stop coding. You now have 24 hours to upload your game.
7. Then you can relax, and start playing the other games. You can rate the other games on three criteria: fun, production, and innovation.
8. At 00:00 UTC on 2018-05-06, the winners are announced. If you don't win first time, don't worry! Hopefully you'll learn loads of things and come back with better ideas next time.

Good luck! Hope to see you there!

The following is the skeleton of a keynote I gave at Pycon Poland in August 2017.

Fun is powerful.

Fun motivates us. I play video games, because it’s fun. I program Python because it’s fun. I do not program PHP, because it’s not fun.

I think that probably Python exists, at some level, because Guido thought it would be a fun thing to create.

I’m going to tell a story about fun - something of the history of programming video games in Python.

Programming games in Python? Isn’t Python an objectively terrible language for programming computer games? It’s so slow! Well, I think you know that that isn’t the whole story. Python is used for crunching some of the biggest sets of data in the world, in applications where clearly performance matters.

How is it possible that such a slow language can be appropriate for big data crunching… and games programming? To find the answers we have to look back 20 years, to the age of Python 1.x.

For big data crunching, that story began in 1995 with a library called Numeric, written by Jim Hugunin, which was later rolled into something called “numpy” by Travis Oliphant.

Jim Hugunin was also one of the people who was responsible for Python’s first OpenGL library, PyOpenGL, with Thomas Schwaller and David Ascher, which dates from around 1997.

OpenGL is an API for writing 3D graphics applications, including games.

However, OpenGL is not sufficient on its own for writing games; it lacks support for things like sound, and creating windows and handling their input.

In March 2000, Mark Baker started working on bindings for LibSDL - the Simple DirectMedia Layer. SDL provides capabilities to render graphics, but also support for creating windows, handling input devices, and playing sound and music.

Later that year, Peter Shinners refactored this into a library called Pygame, which was released in October 2000, the very same month that Python 2.0 was released. It was now possible to write graphical games in Python!

We’ll take a look at some Pygame code a bit later.

So this is the answer to how we can write fast, graphical games in Python. We can do it because we use Python to drive fast, lower-level libraries.

It was in about 2003 that I encountered Python for the first time. I had already taught myself to program games. I learned Java at university. I’d written a few Java games, and I experimented with writing games in C++ with DirectX, OpenGL and SDL.

But programming in those languages was slow and painful. Python was a fun language to program in! I was working as a web developer/sysadmin person, so I was primarily using Python for that at first. But of course, I eventually tried writing some games with this “Pygame” thing. And I was amazed! I had written half of a complicated puzzle game and drawn tons of graphics for it before I realised I hadn’t really considered how to make it fun.

When showing my half-finished game off, somebody recommended I should try my hand at a Python games programming contest called “Pyweek”.

PyWeek was started by Richard Jones in 2005. Richard is perhaps better known as the BDFL of PyPI - originally the “Cheese Shop”. He also wrote the Roundup issue tracker that powers bugs.python.org.

PyWeek challenges participants to write a game from scratch, in Python, in exactly a week. Games have to be written from scratch - which means that they may only make use of published, documented libraries created at least 30 days before the contest starts. You can enter as an individual or as a team; there will be a winner in each category.

The week before the competition, five possible themes are put up for consideration and votes are collected. At the moment the contest starts - always midnight UTC - a theme is picked using a run-off system, and coding begins!

During the contest, you’re able to write “diary entries” about your progress using the PyWeek website, and you can also follow along with the other amazing projects that are being created on the same theme. This is also a forum to discuss your approaches and problems and get feedback and tips.

After just 168 hours of coding, the contest is over! You upload your game, and probably take a well-deserved day or two’s rest. Then everyone who entered a game can spend two weeks playing and reviewing the entries. Entries are scored on three criteria: fun, production and innovation.

Fun is of course measured in how enjoyable the game is to play. The innovation score measures whether the game includes original ideas, in terms of mechanics, theme, plot, control system or whatever. The production score is given for the overall quality of the presentation: graphics, sound, and music, tutorials, title and game over screens… and you might lose production points if your game contains bugs.

Of course that PyWeek was a success, and has run roughly twice a year since then. The latest competition was the 23rd, and the 24th is happening in October.

My first Pyweek was Pyweek 10 in 2010. In that competition, the theme was “Wibbly-Wobbly”. I created a ninja fighting game set in a wibbly-wobbly bamboo forest, like that scene in Crouching Tiger Hidden Dragon.

I was working as a web designer at the time, and I designed the game like I’d design a website: start with mock-ups and concept art and then build the game from them. I programmed for a week, using Pyglet for the first time, and found it was just remarkably simple to use and be effective with.

I didn’t win - though I thoroughly enjoyed the experience. It was my most original and complicated game to date, and I’d written it in just a week. People thought my production values were good, but the game simply wasn’t that fun (2.9 out of 5).

Ah, fun, the elusive element, and the most important. Creating a game is a technical challenge, and innovation is also something that but creating something fun is something more difficult. You’re going to spend a week programming, making choices, and creating… will it actually be fun to play at the end?

Of all the literature I’ve read about the art of creating games that are fun to play, and I think the best way of thinking about Fun is maximising reward and minimising punishment.

Punishment is when the game causes negative feelings. That instant of frustration when Sonic collides with a spike and drops all his rings. When you’re in pole position in Mario Kart when the goddamn blue shell explodes. The boredom of a loading screen that takes 10 seconds, when you see it 20 times an hour, is punishing. Dying in a game, and having to repeat the last ten minutes of gameplay to get back to where you were, is very punishing.

Reward is when things in the game that cause positive feelings, however small. The surge of adrenaline when your bonus multiplier is 10x and you’re still alive and there are a thousand enemies on screen and you’re not sure how long you can keep this going. The discovery that you can combine an ice potion and an arrow to create an ice arrow, and that you can use an ice arrow to halt the waterfall so you can pass.

These can be the smallest things. The satisfying ‘ding’ when you collect a coin is rewarding - that’s why in Mario people keep jumping under that block until it spits out no more coins. The boredom of not being challenged by a puzzle is punishing. Having to repeat the same set of clicks to open your inventory and consume a potion is punishing.

Games are fun when they provide a constant stream of rewards and avoid being too punishing.

If you’ve every played any of the massively commercial mobile games, you’ll be familiar with this. Lots of the games will offer you a constant stream of rewards - “Here, have 2 free diamonds” - with practically no punishment (you can never lose). They dangle rewards in front of you, withholding them just long enough to tantalise you and make you want to pay to get them sooner.

I think this also explains why Pyweek is such fun. Python is a low-punishment language. It doesn’t bite often. When we mess up, it crashes with a clear traceback rather than a SIGSEGV. The libraries don’t come with mind-bending type systems. Python is also a high-reward language, famed for its productivity. But when we’re challenged to unleash creativity, make something quickly, and compete with and alongside others, the rewards are multiplied.

And occasionally, you might win.

In May 2012, my submission for Pyweek 14 - on the theme “Mad Science” - was a physics game called Doctor Korovic’s Flying Atomic Squid. And it won! I’m going to show you a little of it now.

Jumping back to the story of Pyweek -- Pyweek was also conceived as a way of energising a community to create useful tools and libraries. The rules of Pyweek start with a mission statement:

The PyWeek challenge:

1. …

2. …

3. Will hopefully increase the public body of python game tools, code

   and expertise,

4. Will let a lot of people actually finish a game, and

5. May inspire new projects (with ready made teams!)

Because of the “from scratch” rule, from the outset people would create and publish libraries from their Pyweek games to avoid having to write the libraries again.

The second Pyweek competition ran in March 2006. The individual competition was won by Alex Holkner, with a game called Nelly’s Rooftop Garden, and it is still the highest-scoring Pyweek game of all time.

Later that year, Alex started a Google Summer of Code project to create a clone of Pygame using the ctypes library, which having been available for a few years, was due for inclusion in the Python standard library in Python 2.5 that autumn. His mentor was Peter Shinners, the Pygame author.

He quickly got good at this. In a few short weeks he had a working implementation of Pygame with ctypes, as well as a lower-level SDL-ctypes. And then he started looking at PyOpenGL, which had some gaps in API coverage. He started ctypes bindings to fill those gaps - and quickly realised he could produce complete ctypes bindings for OpenGL relatively quickly. The project was named pyglet.

At this point the ever active Richard Jones pitched in and together Richard and Alex forged Pyglet into a full cross-platform, dependency-free games library. Alex pulled text rendering from Nelly’s Rooftop Garden. Then Pyglet gained a featureful sprite library, with support for rotation and scaling of sprites, as well as colours and transparency, and a native sound library called AVBin.

Pyglet is easy to use for beginners, while exposing the underlying OpenGL primitives to more experienced users. Its sprite and text libraries can be wrapped up with OpenGL state changes to achieve complex effects.

Pyglet is a great library, and it is what I used in the majority of my Pyweek entries, including Doctor Korovic’s Flying Atomic Squid. It has more graphics features than Pygame, and is probably as easy or easier for the basics - but Pyglet does offer the full power of OpenGL at the cost of complexity.

A year and a half after Pyglet was released, at PyCamp in Los Cocos, near Córdoba in Argentina, Ricardo Quesada and others started the “Los Cocos” Python game engine, a higher-level engine based on Pyglet. It was soon renamed Cocos2d. Ricardo later ported it to iPhone, where it became wildly popular. Many App Store number one games have been written with it. There are over 100 books about Cocos2D programming.

So Pyweek is a successful incubator for technology.

Let me pick up another thread of history now - this Education Track at Pycon UK. Pycon UK’s education track was set up by Nicholas Tollervey - who has keynoted here previously - and who is himself a former teacher.

The very first education track, in 2012, invited teachers to attend Pycon UK for the first time. The teachers were “shared out” between Python programmers, and each group was challenged to come up with course material. I was there that first time, fresh from my Pyweek win, and I was sorted into a group with a teacher named Ben Smith. Ben is a teacher, and was keen to see what I could come up with for teaching programming to kids through the medium of games.

I spent five minutes or so writing a basic Pygame game, which looks like this:

Looks simple, right? But Ben told me the first moment he saw it, “I can’t teach that.” The problem was that it was just too many lines of code. In a 40-minute Computing lesson, he would have some students race through it in five minutes, while others would be struggling to type the first “import pygame” line correctly. I was a bit taken aback, to be honest. It needs to be simpler than that!? But, as he explained, he needed to be able to feed them a sequence of tasks that were small enough that everyone could catch up, before moving on.

The education track has run every year since 2012, and I’ve attended it every time. As well as the teacher’s day, it now also has a “kids day” where kids can come and learn to do fun things with Python. A few years ago, I was working for Bank of America Merrill Lynch, and I helped arrange for the bank to sponsor the education track, which it has done since 2014. The sponsorship money helps, for example, to pay for supply teachers so that the regular teachers can come.

Teachers in the UK are facing an immense challenge in teaching a modern computing curriculum. Many teachers don’t have programming skills themselves. Most schools lack resources to train their teachers, procure hardware, or install and configure the software needed to teach programming skills.

Still, through Pycon UK I’ve met many amazing teachers who overcome all this with ingenuity and enthusiasm. They make programming fun.

In October 2014, after a few attempts to take the Pyweek team entry title had failed, I won the Pyweek solo competition again, with a game called Legend of Goblit. The theme was “One Room”, and Goblit is a LucasArts-style adventure game set in a single room. It’s actually a sort of “adventure stage play”, with lots of scripted sequences, pausing for interactive puzzles. Let me show it to you now.

Goblit was probably not the most innovative game that time - but it was the most fun. In fact it is the third most fun Pyweek game of all time, behind Nelly’s Rooftop Garden (second) and Mortimer the Lepidoptorist (first).

Legend of Goblit was my first Pyweek entry in a few years that was written with Pygame. As I wrote it, I had something at the back of my mind - I thought back to that education track, to what Ben Smith had said about Pygame being too complicated. Part of the code of Legend of Goblit was a small Pygame-based game engine that was intended to be accessible to complete beginners.

Well, as usual, that sat there for six months, until Pycon 2015, in Montreal, Canada. On the first day of the sprints, I was sitting with Richard Jones, and I told him that I was proposing to sprint on writing a Pygame-based game engine for education. Well, as you’ll understand by now, when Richard is into an idea he’s into it - and he joined me to sprint on the new library, which I named “Pygame Zero”. This is us working together on the first cut of Pygame Zero.

Pygame Zero is a zero-boilerplate game engine for Python. What do I mean by zero-boilerplate? An empty file is a working Pygame Zero program.

We don’t run this with the standard interpreter; we run it with pgzrun.

Next can add a draw() function.

You might use this to draw an Actor - in this case a rabbit sprite loaded from a file called ‘rabbit.png’.

Then we can write an on_key_down() function, to handle input.

And if we add a button parameter to the on_key_down() function, this value will be passed into the function.

At each stage, we’re adding just a couple of lines at a time, and getting immediate results. If you think back to Ben Smith’s criticism of Pygame, to the problem of feeding his class a bite-size piece of work that would let groups all catch up before moving on, Pygame Zero solves it.

We use a little bit of magic - some extra builtins, some metaprogramming - so that we don’t have to teach import statements before we teach how to define and call a function.

Let me show you something else. Another teacher I met at Pycon UK was writing his first Pygame Zero program, and he tweeted me “It doesn’t work when I define a mouse down function”. This is what he’d written.

So now when you run Pygame Zero with a similar bug, it prints this:

Pygame Zero was a bit of a hit - educators everywhere became very excited about it. It ships on every Raspberry Pi, for example, and the creator of the Raspberry Pi, Eben Upton told me “It’s pretty much perfect.” Mark Scott, who works for the Raspberry Pi Foundation, told me, “It has lowered the age at which we can teach text-based programming languages by a couple of years.” (Text-based as opposed to graphical tools like Scratch). And it spawned a bit of a spin-off movement - there are now “Zero” libraries for GPIO, for networking, for UI, and more.

Pygame Zero is fun, and I’ve only recently realised why. Pygame Zero lets you create games with a constant stream of reward - moments when you get something new working - and it minimises punishment, by warning about potential pitfalls.

I’d like to look into the future for a moment. At Europython this year, Leblond Emmanuel announced that he has completed Python bindings for the Godot game engine - a comprehensive, multi-platform, open-source game engine. Roberto De Ioris has created Python bindings for Unreal Engine 4 - one of the most well known game engines.

But you don’t need a huge, modern, 3D game engine. Slobodan Stevic recently published a game called Switchcars - written with Pygame - on Steam.

Let me try to summarise what I think this story teaches us.

Firstly, yes, you can program games in Python. You can do it today, and you can do it commercially. Or you could just do it for fun.

Secondly, if you’re starting a new library, try to make sure Richard Jones is there to help. But seriously - perhaps we should be a bit more like Richard? We should try to have that infinite enthusiasm, and be quick to help kick-start other people’s projects. If you’re starting a new project, particularly a game or a games library, I’d like to volunteer to help you.

Thirdly, make it fun. Whatever you’re creating, make it reward people as much as possible, and make sure it doesn’t punish people.

Finally, please sign up for the next Pyweek in October. I’m sure you will have fun - but you might just end up creating something amazing, something that will make Python better for for education, or for fun, or for all of us.

Thank you.

The 23rd Pyweek games programming competition will run from the 19th to 26th of February 2017, from midnight to midnight (UTC).

The Pyweek rules, in short, are:

• Develop a game
• In Python (mostly, at least!)
• As an individual or with a team
• In exactly one week (or less!)
• From "scratch" - no personal codebases, only public, documented libraries
• On a theme that is selected by vote, announced at the moment the contest starts.

Python has great libraries for programming games, both 2D and 3D, and the flexibility of the language means you can achieve a lot in just 7 days. Pyweek is open to programmers of all ages and experience levels, from anywhere in the world, and it's a great way to challenge yourself and improve your skills.

Games are scored by other entrants, on criteria of fun, production and innovation, and you'll have to think about all three to be in with a chance of winning! It's a free competition though, so your prize is recognition :-)

Here's what you need to do if you want to take part:

1. Sign up/login at http://www.pyweek.org/, and then "Register an entry" at the top-right.
2. Familiarise yourself with some of the libraries and resources you can use to make games.
3. Join the IRC Channel, #pyweek on Freenode, for discussion and advice.
4. Play some of the previous entries at the Pyweek.org site.
5. Why not post a diary entry (from your entry page), introducing yourself and your team?
6. Put a "save the date" in your calendar! Theme voting starts 2017-02-12, and the competition the week after, 2017-02-19 00:00 UTC.

Have fun, and good luck!

Google, Twitter and Facebook all famously use monorepos for the bulk of their development. A monorepo is a single version control repository shared by all of an organisation's code. That's not to say that a monorepo should be just an unstructured mess of code in a single repository; that would be chaos. It's usually a collection of components - apps, services, libraries etc - all stored alongside each other in a single conceptual codebase.

A monorepo obeys two rules:

• Whenever you build, test, run or release software, all the code used comes from the same version of the whole repo.
• Code can only be pushed to the repo if all tests it could possibly affect have passed. Conceptually the entire repo is always passing all tests and is ready to release at any time.

Crucially, a monorepo bans any flexibility to pick and choose versions of libraries code depends on. This is seen as the big advantage of monorepos - avoiding dependency hell.

A typical dependency hell situation is this:

• You depend on two libraries A and B.
• The latest A depends on C version 1.1.
• The latest B depends on C version 1.2.
• You therefore can't use the latest A and latest B.

There may be a solution - downgrade A, or B, or both - or there may not.

Dependency hell is a problem, and one that becomes much more problematic as the organisation scales - as the number of libraries increases. Monorepos avoid dependency hell by enforcing that A and B will always depend on the same version of C - the latest version.

Another advantage is that monorepos can help avoid using stale code. Once you get your code into the monorepo, any future release of any product will be using that code. Of course, it's the same amount of effort to port code to use newer versions of dependencies, but that work has to be done before the new version can be pushed.

However, it's not without huge downsides.

Even if you can calculate which tests could possibly be affected, you can find yourself rerunning huge swathes of the organisation's tests to guarantee the codebase is always ready to release. To respond to this, orgs disregard extravagancies such as integration tests and mandate fast running unit tests only.

Making breaking changes to an API in a monorepo is hard, because to push code into the repo it already has to be passing all (unit) tests. There are several responses that drop out, all sensible but undesirable:

• Only make backwards-compatible changes - bad, because we accrue debt and cruft, shims and hacks
• Introduce feature flags - bad because we introduce codepaths that may mean combinations of flags run in production that haven't been tested
• Take heroic steps to try to patch all the code in the organisation - bad, because this involves developers changing other team's code, which can lead to mistakes that may slip through code review

It can be extremely hard to utilise third-party libraries in a monorepo, because code that was developed with the assumption of versioned library releases is completely naïve of the breaking-changes issue.

Also, if things break that aren't cause by unit tests, finding what changed can be hard - everything is changing all the time.

Put simply, monorepos neglect how valuable it is to have fully tested, versioned releases of library code accompanied by CHANGELOGs describing what changed.

Versioned releases mean a developer using a library is decoupled from any breaking changes to a library. There can be multiple branches in development at once, say a 1.6 maintenance release and a 2.0, letting developers upgrade as time allows.

In my current role, we've been using Ansible for our orchestration and configuration management. Ansible is okay, but after several months wrestling with its extension API and being frustrated by YAML syntax ideas started popping into my head for something better.

Chopsticks (docs) represents my vision of Pythonic orchestration. It's not an orchestration framework in itself. It's more the transport layer for other orchestration systems. It's a remote procedure call (RPC) system that relies on no agent on the remote host: the agent is built dynamically on the remote host by feeding code over the SSH tunnel to the system Python.

For example, you can create an SSH Tunnel to a remote host:

from chopsticks.tunnel import Tunnel
tun = Tunnel('ns1.example.com')

Then you can pass a function (any pickleable Python function), to be called on the remote host. Here I'm just calling the standard time.time() function.

import time
print('Time on %s:' % tun.host, tun.call(time.time))

Of course, you might want to do this in parallel on a number of hosts, and this is also built-in to Chopsticks:

from chopsticks.group import Group
from chopsticks.facts import ip

group = Group([
    'web1.example.com',
    'web2.example.com',
    'web3.example.com',
])
for host, t in group.call(time.time).items():
    print('%s time:' % host, t)
for host, addr in group.call(ip).items():
    print('%s ip:' % host, addr)

Note that the code for chopsticks.facts does not need to be installed on the remote hosts. They will load it on demand from the orchestration host.

Effectively, Chopsticks gives you the ability to write Python programs that straddle a number of machines, all sharing a single codebase.

See the README for a summary of how this works.

SSH tunnels are not the only connection type Chopsticks supports. It communicates over stdin/stdout pipes, so can work with any system that supports these without inteference. Such as Docker (this is on Github, but not PyPI yet):

from chopsticks.tunnel import Docker
from chopsticks.group import Group
from chopsticks.facts import python_version

group = Group([
    Docker('worker-1', image='python:3.4'),
    Docker('worker-2', image='python:3.5'),
    Docker('worker-3', image='python:3.6'),
])

for host, python_version in group.call(python_version).items():
    print('%s Python version:' % host, python_version)

The next Pyweek competition will run from 00:00 UTC on Sunday 28th February to 00:00 UTC on Sunday 6th March. That's next week!

Pyweek is a week-long games programming competition in which participants are challenged to write a game, from scratch, in a week, in Python.

This week, we vote on themes! The possible themes can be interpreted however you like:

• Jump in line - you could do a Dance Dance Revolution-style game with cute animals
• Showtime! - perhaps a business sim in which you run a TV network?
• The aftermath - clean up the mess from a house party before your parents get home.
• The incantation - players enter a TV talent show to prove they are the best spell-caster. Each week one is voted off! Featuring Will.i.am.
• In the model - this naturally lends itself to a totally awesome game in which you have to develop a Python script with sklearn to solve exciting big data problems! With cute animals!

But seriously, if these theme ideas get your creative juices flowing, and you have spare time to write a game next week, why not register an entry and give it a go?

I continue to be staggered at the effectiveness, as a process management technique, of simply sticking cards representing tasks onto a whiteboard. Whatever your industry or project management methodology, the ability it offers to visualise the flow of work is immensely powerful. It lets us plan the current work and the near future to maximise our productivity.

It's valuable whether you're working on your own or working as a team. When working as a team, it can be used to schedule work among team members. When on your own, it merely helps with clarity of thought (we'll look at why a little later).

Yet this is largely unknown outside of software development. All sorts of industries would benefit from this approach, from farming to law.

Pygame Zero 1.1 is released today! Pygame Zero is a zero-boilerplate games programming framework for education.

This release brings a number of bug fixes and usability enhancements, as well as one or two new features. The full changelog is available in the documentation, but here are a couple of the highlights for me:

• A new spell checker will point out hook or parameter names that have been misspelled when the program starts. This goes towards helping beginner programmers understand what they have done wrong in cases where normally no feedback would be given.
• We fixed a really bad bug on Mac OS X where Pygame Zero's window can't be focused when it is installed in a virtualenv.
• Various contributors have contributed open-source implementations of classic retro games using Pygame Zero. This is an ongoing project, but there are now implementations of Snake, Pong, Lunar Lander and Minesweeper included in the examples/ directory. These can be used as a reference or turned into course material for teaching with Pygame Zero.

Pygame Zero was well-received at Europython. Carrie-Anne Philbin covered Pygame Zero in her keynote; I gave a lightning talk introducing the library and its new spellchecker features; and the sprints introduced several new collaborators to the project, who worked to deliver several of the features and bugfixes that are being released today.

A big thank you to everyone who helped make this release happen!

The next Pyweek competition has been announced, and will run from 00:00 UTC on Sunday 9th August to 00:00 UTC on Sunday 16th August.

Pyweek is a week-long games programming competition in which participants are challenged to write a game, from scratch, in a week. You can enter as a team or as an individual, and it's a great way to improve your experience with Python and express your creativity at the same time.

If writing a game seems like a daunting challenge, check out Pygame Zero, a zero-boilerplate game framework that can help you get up and running more quickly.

Due to various circumstances this has been delayed somewhat, and is now being announced at somewhat short notice. Be aware that this means that theme voting begins this Sunday, 2nd August.