The concept of a Supernav is used heavily on the site. These are the larger bits of text and markup included in the main navigation drop downs. These are implemented as specially named Boxes. They are by convention named supernav-*, for example templates/downloads/supernav.html.

Here is an example of what that looks like on the site.

Example Supernav image

The sub-nav items on the left are simply nested Navigation links in SiteTree relative to the ‘Download’ item in the tree. The larger Download for macOS box however is what we refer to as the supernav.

Most supernavs are updated automatically based on the underlying Django application content using signals. By convention the application will have a template named supernav.html. For example, upon saving any published Release a Django signal is fired to update the supernav-python-downloads box with the most current Python2 and Python3 releases. In this case the markup is structured in a way to allow for the automatic OS detection Javascript to show the user the appropriate download links for the OS they are browsing with.


Pages are individual entire pages of markup content. They are require Title, Path, and Content to be acceptable in the system. Note that Pages are implemented using a fall through system of URL routing so a user cannot override an existing defined Django URL on accident with a Page.

Fields and Descriptions


Title of the Page. Will also be used as the <title></title> attribute in the markup.


HTML META keywords for search engines


HTML META description for search engines


Relative URL path where the page will reside, excluding the initial slash. Example: about/psf/somepage/


The actual content of the page.

Markup Type:

Type of markup contained in the Content field. Options are: HTML, plain text, ReStructured Text, and Markdown

Is Published:

Controls whether or not the page is visible on the site.

Template Name:

By default Pages use the template templates/pages/default.html to use a different template enter the template path here.


Pages are automatically purge from upon save.


Boxes are re-usable bits of HTML markup that are used throughout the site. Things like sidebar info and specific areas of areas of pages with a richer design (i.e. landing pages) that would be cumbersome to edit as one large content textarea.


There are special boxes that are automatically rebuilt using templates, see Supernavs.

Downloads and Releases

The downloads app stores all of the structured data regarding Python releases. Each Release object has associated ReleaseFile objects that contain information on the various download formats supports.

If the version you are creating should be considered the “latest” release for the major version in question (Python 2.x.x, 3.x.x, etc) then check the ‘Is this the latest release’ checkbox. When the Release is saved, the previous version will be automatically demoted for you and the new version will be used prominently on the site. For example the download buttons and supernav links.


If you make a mistake here, no worries you can just check the box and save on ANY version and promote it to being the latest release.

To create a release you simply need to fill in the appropriate information. Currently if a Release has an associated Release Page the system redirects to that to accommodate legacy content, but if the Content field is filled they are taken to the Release Detail page which shows the content and lists all of the associated downloadable files.

Release Files have a checkbox named ‘Download button’ that determines which binary/source package download link to display for a given OS. This information is used by the OS detection JS on the site so pick the package in most widespread use. On Source distributions be sure to check the ‘Download button’ for the .tgz version for widest compatibility.


The jobs application is using to display Python jobs on the site. The data items should be fairly self explanatory. There are a couple of things to keep in mind. Logged in users of the site can submit jobs for review.


Jobs enter the system in ‘review’ status after the submitter has entered them. Only jobs in the ‘approved’ state are displayed on the site.


Featured jobs are displayed more prominently on the landing page.


Users who have submitted a job and admin reviewers can make comments on a job. Emails will be sent to the other party in order to foster communication about job description and data.


The Sponsors app is a place to store PSF Sponsors and Sponsorships. This is the most complex app in the project due to the multiple possibilities on how to configure a sponsorship and, to support this, the app has a lot of models that are grouped by context. Here’s a list of the group of models and what do they represent:

The Sponsorship model and all the related information to configure a new sponsorship application like programs, packages and benefits;

List models that are used to configure benefits. Here you’ll find models that forces a benefit to have an asset or controls it maximum quantity;

Models that are used to configure the type of assets that a benefit can have;

Has the Sponsor model and all related information such as their contacts and benefits;

Any type of sponsor notification that’s configurable via admin;

The Contract model which is used to generate the final contract document and other support models;





Success Stories