DTU Course 02820: Python Programming
Tentative schedule for autumn 2012
- Introduction to the course, installation and introduction to Python
to the course PDF of slides
PDF of slides
- Introduction to Python
- Numerical Python: "Python as Matlab".
Numpy, Scipy, matplotlib, ...
- Databasing, text and Web mining and Python
and web mining
- GUI and Web serving
- Project work for the rest of the time.
- Project presentations (monday before autumn vacation)
- Exam: December 2011 Building 321, floor 100 Thursday 13th
December 2012 starting from
- Report hand-in deadline: Thursday 13th December 2012 23:59.
There are no fixed course material for the project, but we
recommend a number of books and other material:
- The Python Tutorial.
- Mark Pilgrim
into Python. A good and free introduction to
Python. Basic Python, Unit testing, XML, regular
- Allen Downey (2002-2008)
Python: How to Think Like a Computer Scientist. GFDL
license. Covers the basics of the Python language and Tkinter GUI.
- Hans Petter Langtangen (2008)
Scripting for Computational Science.
Available as a e-book through the DTU library.
Covers basic Python, numerical (NumPy and SciPy),
combining Python and C, CGI and GUI programming.
- Vidar Bronken Gundersen (2006) MATLAB commands in
numerical Python (NumPy). Indispensable if you are trained
in the Matlab or R languages as this short note provides a
concise Rosetta stone between Python, Matlab and R. Probably
good even if you do not have knowledge of Matlab and R.
- Internet search engine,
- Toby Segaran (2007), Programming Collective Intelligence.
A commercial book with Python examples in machine learning for
Web 2.0 applications, e.g., naïve Bayes classifier and
non-negative matrix factorization.
Polyteknisk Boghandel: 279 kroner (2012)
- Steven Bird et
al. (2009), Natural
Language Processing with Python. Describes the NLTK Python
package and written by the developers of this nice language
processing toolkit. Also available under a Creative
Commons licence from https://sites.google.com/site/naturallanguagetoolkit/book. Polyteknisk
L. Model, Bioinformatics
Programming Using Python: Practical Programming for Biological Data.
Probably recommendable for people interested in
bioinformatics. Covers basic Python presented with problems from
bioinformatics. Also web and database programming.
Boghandel: 469 kroner (2012).
- Toby Segaran, Colin Evans og Jamie Taylor (2009),
Programming the Semantic Web.
Specialized book about the Semantic Web and how Python can be
used in that context.
Boghandel: 275 kroner (2012).
- Alex Martelli (2005), Python Cookbook. Shows good code
examples. Not so good as an introductory book.
- Ivan Idris
1.5 Beginner's Guide. As the name implies: A beginner's
guides to NumPy.
You are evaluated on the written report, the printed poster and
the oral poster presentation.
The grade will be based on an overall combined assessment.
So do not expect to get a grade or "points" after the poster presentation.
You will first get the grade after we have evaluated the reports
together with the poster presentation.
The report should contain:
There are length requirements for the report:
- Use a template: this latex template
(IEEE style with 10 point font size)
or similar in style. Please do not squizze the font size or
layout beyond the style file.
- Information on first page: name, study number, title.
- Your programming code in an appendix.
You may exclude code that contains excessive GUI-setup, long
- You are allowed to use code that you found on the Internet
(provider that the author distributes it under a suitable
license such as BSD or GPL), but remember to give full and
clear attribution to the author. Any text citations should
also be fully referenced and in quotation marks. Paraphrased
citations should also be fully referenced.
This limit does not apply for the appendix, which can be
any page length. The appendix may contain code and automated
generated content, e.g.,
from Epydoc, pylint
results or other.
- One-person report: 2 pages
- Two-persons report: 3 pages
- Three-persons report: 4 pages
The text and the code should be included as text, rather than
as images, so the plagiarization detection system can read it.
The report could contain, e.g.:
When looking into the code in the report apart from the actual
functionality we may possibly examine the below items:
- Discussion of the design of the program
- Description of the implementation.
- Table or graphical overviews of modules and/or classes
- Database schema description
- Description of central parts of the code
- Screenshots of the program
- Plots of results
- Plots of code performance
- How well-structured it is (modules/classes/functions)?
- Is it effective? Does it use the Python language
For example sometimes you can avoid a standard "for" loop writing
it the code a single line.
Vectorized NumPy operations might be faster than standard
Python, see, e.g., my
- Is it secure? In a web application you should sanitize
input and escape during output. If your program receives
strange input does it crash?
- Is the code documented? A structured way would use the
__doc__ variable and, e.g., pydoc. See the "documentation" part
the introduction slides
- Is the code tested? Are errors and exceptions handled
well. You have likely run the program and seen that it works. A
more structured approach would also utilize some of the testing
functionality in Python. See "Testing" part of the
- Is the coding "nice looking" and consistent? For inspiration
Guide for Python Code.
The poster shows the design of the program and "results" e.g.,
screen shots or plots and it must be self-contained.
On the top, the poster must contain title, names of students,
course title and date.
Examples on posters can be seen in building 321, 1. floor
(Note that some of the posters are not from the Python course).
The external examiner will attend the presentation of the posters
and will receive the final report.
We are able to print posters in up to A0 landscape format (w=1189mm,
h=841mm) as the largest. If you opt for this possibility, please email a PDF file
in sufficient resolution to Finn
Kuno Christensen (or
Erik Poulsen) - with the email: print (a) imm. dtu. dk. 12:00 the day before the exam.
Specify whether you want the poster in A1 or A0.
Note that if you all queue up on that hour there might be a
The printer room is in the cellar of building 305 and Kuno and
Erik are in the
library in room 053 (the cellar between building 305 and 321).
As an alternative you can print the poster on multiple A4 sheets on glue it
on a post board or hang them next to each other on the pin board we have.
There are no rules about the size of the poster, but A3 will
probably be too small. A1 is preferable and the default.
A standard issue with presenting material on a poster is
that one tends to put too much text on the poster. Better it is
to have good drawings, diagrams or plots.
For the poster presentation the two- and three-men teams should each give a five
minute presentation, while a one-man "teams"
should prepare a presentation between 5 and 10 minutes. After the
presentation we (teachers and censor) will ask questions.
In a group each participant should present a part of the
project/poster, i.e., each participant should not present
the entire project/poster.
Note that each participants presentation and answers to questions
need to be individual. This is not a group exam and we may
direct individual questions to one of you in the group,
- and the others should not answer.
It will be a good idea to rehearse exactly what you are going to
say at the poster presentation.
You can demonstrate the program on the computer. It might give
us a nice impression.
The risk is that you cannot make the computer work or that it
will take too much time to setup and draw attention away.
If you choose to also demonstrate the program on a computer, be
sure to rehearse that along with the oral presentation.
You should expect that other students follow around and listen
while you a given a presentation.
You are welcome to follow around and listen to the other
students while the they present.