Python

From OLPC
Revision as of 23:35, 17 November 2007 by 24.110.145.202 (talk) (The page didn't even say what Python was! Maybe a reptile? :-))
Jump to navigation Jump to search
  english | español | português HowTo [ID# 78348]  +/-  

Introduction

Python is a programming language. You can find out more about Python by going to the web site or reading the wikipedia article.

Much of the software for Sugar is written to use the OLPC Python Environment.

Python is a typical interpreted language. (It tokenizes the code at program start-up. It does not JIT.) Python is thus adequately fast for simple things, but poorly suited to number crunching and similar. The biggest advantage for the project is that source code is naturally supplied to the user, making Open Source software licenses easy to satisfy and making code available for children to modify. The biggest advantage for activity developers is that Python libraries are supplied which hide the sugar API.

Obtaining and learning Python

Python is commonly provided by default on Linux and BSD systems. OLPC is currently using version 2.5 on the XO.

You can download nicely packaged Python called ActivePython. They proclaim themselves as the All-in-one Python distribution for AIX, HP-UX, Linux, Mac OS X, Solaris, and Windows.

PyGTK is the Python interface to the GTK GUI library used in the OLPC. This library is notable for a component named Pango which simplifies the use of multiple scripts and languages. In addition, it's basic drawing library, Cairo, has some of the best support of SVG rendering which is also a major component of the OLPC.

The Livewires Python Course may be useful to create some curriculum material to teach the kids how to write their own Python applications. It would need some adaptation to fit the OLPC environment.

The author of Python wrote a long tutorial.

Development Advise

Some things to consider in Python development:

  • PEP 8 is the Python style guide. On many issues the style guide suggests but does not require a particular style. Generally you should stick to the style guide, unless there is good reason not to. For instance, if you are interacting with a library (internal or external) that uses a different convention, don't try to translate the convention.