[pypy-svn] rev 1089 - pypy/trunk/doc
lac at codespeak.net
lac at codespeak.net
Sun Jul 6 20:37:34 CEST 2003
Author: lac
Date: Sun Jul 6 20:37:33 2003
New Revision: 1089
Modified:
pypy/trunk/doc/oscon2003-paper.txt
Log:
Converted the paper to use ReST, got nearly all of the markup correct.
Now to make sunstantive changes to the text to reflect what has changed
since LLN. I give this talk Wednesday, so comments and suggestions, while
welcome at any time, are especially welcome soonest. :-)
Modified: pypy/trunk/doc/oscon2003-paper.txt
==============================================================================
--- pypy/trunk/doc/oscon2003-paper.txt (original)
+++ pypy/trunk/doc/oscon2003-paper.txt Sun Jul 6 20:37:33 2003
@@ -1,58 +1,65 @@
-Implementing Python in Python -- A report from the PyPy project
-
-The PyPython project aims at producing a simple runtime-system for the
-Python language, written in Python itself. Sooner or later, this
-happens to most interesting computer languages. The temptation is
-great. Each significant computer language has a certain
-expressiveness and power, and it is frustrating to not be able to use
-that expressiveness and power when writing the language itself. Thus
-we have Scheme, Lisp-written-in-Lisp, and Squeak,
-Smalltalk-written-in-Smalltalk. So why not Python-written-in-Python?
-
-Besides using the expressiveness of Python to write Python, we also
-aim to produce a minimal core which is Simple and Flexible, and no
-longer dependent on CPython. We will take care that PyPy will integrate
-easily with PSYCO and Stackless -- goals that are attainable with both
-Armin Rigo (author of PSYCO) and Christian Tismer (author of Stackless)
-on the team. Samuele Pedroni, catches us when we unwittingly make
-C-ish assumptions. By keeping things Simple and Flexible we can
-produce code that has attractions for both industry and academia.
-Academics will find that this Python is even easier to teach concepts
-of language design with. And ending the dependence on CPython means
-that we can produce a Python with a smaller footprint. Eventually,
-we would like to produce a faster Python. We are very far from that
-now, since we have spent no effort on speed and have only worked on
-Simple and Flexible.
-
-1. How have we set about it.
-
-Most of you know what happens if you type
-
-'import this'
-
-at your favourite Python prompt. You get 'The Zen of Python',
-by Tim Peters. It starts
-
- Beautiful is better than ugly.
- Explicit is better than implicit.
- Simple is better than complex.
-
-and ends with:
-
- Namespaces are one honking great idea -- let's do more of those!
-
-What would 'doing more of those' mean? Here is one approach.
-
- In a Python-like language, a running interpreter has three main parts:
-
- * the main loop, which suffles data around and calls the operations
- defined in the object library according to the bytecode.
-
- * the compiler, which represents the static optimization of the
- source code into an intermediate format, the bytecode;
-
- * the object library, implementing the various types of objects
- and their semantics;
+==============================
+Implementing Python in Python
+==============================
+A report from the PyPy project
+------------------------------
+
+The PyPy_ [#]_ project aims at producing a simple runtime-system for
+the Python_ language, written in Python_ itself. **C** and **Lisp**
+are elder examples of languages which are self-hosting. More
+recently, we have seen implementations of **Scheme** in Scheme_, [#]_
+and **Squeak**, [#]_ [#]_ a Smalltalk_ implementation of Smalltalk_.
+The desire to implement your favourite language *in* your
+favourite language is quite understandable. Every significant
+computer language has a certain expressiveness and power, and it is
+frustrating to not be able to use that expressiveness and power when
+writing the language itself.
+
+Thus we aim to produce a minimal core which is *simple* and
+*flexible*, and no longer dependent on CPython [#]_. This should make
+PyPy_ easier than CPython to analyze, change and debug. We will take
+care that PyPy will integrate easily with Psyco_ [#]_ and Stackless_, [#]_
+while trying to avoid unwitting C dependencies in our thinking.
+We should be able to produce different versions of PyPy which run
+on different architectures, for instance one that runs on the
+Java Virtual Machine, much as **Jython** [#]_ does today. By keeping
+things *simple* and *flexible* we can produce code that has
+attractions for both industry and academia. Academics will find that
+this Python_ is even easier to teach concepts of language design with.
+Industry will be pleased to know that ending the dependence on CPython
+means that we can produce a Python_ with a smaller footprint.
+Eventually, we would like to produce a faster Python_ , which should
+please all. We are very far from that now, because speed is a distant
+goal. So far we have only worked on making PyPy_ *simple* and
+*flexible*.
+
+How have we set about it
+------------------------
+
+Most of you know what happens if you type::
+
+ import this
+
+at your favourite Python_ prompt. You get *The Zen of Python*, [#]_
+written by Tim Peters. It starts::
+
+ Beautiful is better than ugly.
+ Explicit is better than implicit.
+
+and ends with::
+
+ Namespaces are one honking great idea -- let's do more of those!
+
+This raises an interesting question. What would *doing more of those*
+mean? The PyPy_ project takes one approach.
+
+Background
+----------
+
+In a Python-like language, a running interpreter has three main parts:
+ * the main loop, which suffles data around and calls the operations defined in the object library according to the bytecode.
+ * the compiler, which represents the static optimization of the source code into an intermediate format, the bytecode;
+ * the object library, implementing the various types of objects and their semantics;
In PyPy, the three parts are clearly separated and can be replaced
independently. The main loop generally assumes little about the semantics
@@ -63,8 +70,8 @@
loop into explicit concepts (yet), because we have been concentrating
on making separable object libraries.
-We call the separable object library, an Object Space.
-We call Wrapped Objects the black boxes of an Object Space.
+We call the separable object library, an *Object Space*.
+We call *Wrapped Objects* the black boxes of an Object Space.
But the exciting thing is that while existing languages implement _one_
Object Space, by separating things we have produced an architecture
@@ -73,9 +80,8 @@
So let us dream for a bit.
-First dream: How do you get computer science concepts in language design
-more effectively into student brains?
-
+First dream: How do you get computer science concepts in language design more effectively into student brains?
+**************************************************************************************************************
Traditionally, academics come up with interesting new ideas and
concepts, but, to the extent that they are truly new end up creating
another language to express these ideas in. Unfortunately, many
@@ -89,15 +95,15 @@
Space which obeys the new rules we have thought up, and drop it into
an existing language. Comparisons between other ways of doing things
would also be a lot simpler. Finally, we could reasonably ask our
-students to implement these ideas in Python and let them drop them in,
+students to implement these ideas in Python_ and let them drop them in,
leaving all the other bits, irrelevant for our educational purposes as
they already are written. There is no better way to learn about
compiler writing, than writing compilers, but a lot of todays
education in compiler writing leaves a huge gap between 'the theory
that is in the book which the student is expected to learn' and 'what
is reasonable for a student to implement as coursework'. Students can
-spend all semester overcoming difficulties in _actually getting the IO
-to work_, and _interfacing with the runtime libraries_, while only
+spend all semester overcoming difficulties in *actually getting the IO
+to work*, and *interfacing with the runtime libraries*, while only
spending a fraction of the time on the concepts which you are trying
to teach.
@@ -105,13 +111,15 @@
concepts we wish to teach and the code written to implement just that.
Dream number Two: A Slimmer Python
+**********************************
People who write code for handhelds and other embedded devices often wish
that they could have a much smaller footprint. Now they can ask for a
Tiny Object Space which only implements the behaviour which they need,
and skips the parts that they do not.
-Dream number Three -- What is the best way to implement a dict?
+Dream number Three -- Multiple, Dynamically changing Implementations of a single type
+*************************************************************************************
This depends on how much data you intend to store in your dict. If you
never expect your dict to have more than a half dozen items, a really
@@ -121,10 +129,10 @@
nothing to stop your interpreter from keeping statistics on how it is
being used, and to move from strategy to strategy at runtime.
-Dream number Four -- How would you like your operators to work today?
-
+Dream number Four -- You might want to change how operators work, as well
+*************************************************************************
Consider y = int(x). How would you like this to work when x is 4.2,
-4.5, -4.2 and -4.5? Currently Python says 4, 4, -4 and -4, truncating
+4.5, -4.2 and -4.5? Currently Python_ says 4, 4, -4 and -4, truncating
towards zero. But for certain applications, this is not what is desired.
You would prefer round behaviour 4, 5, -4 -5 -- rounding away from zero.
Or you would like to always return the larger integer 5 5 -4 -4. Sometimes
@@ -134,10 +142,12 @@
Changing the behaviour and seeing how the results change ought to be
straight-forward, simple, and easy.
-Dream number Five -- Running different Object Spaces on different processors
-of the same machine.
+Dream number Five -- Running different Object Spaces on different processors of the same machine.
+*************************************************************************************************
+Put text in here.
Dream number Six -- Running different Object Spaces on different machines.
+**************************************************************************
This is one of the unrealised dreams of distributed computing. It would
often be convenient to allow the various machines on a network to share
@@ -147,16 +157,17 @@
forward the computation to a machine with more computational power.
Dream number Seven -- A Smarter, more Dynamic Interpreter
+*********************************************************
-There is no reason why your Python interpreter could not keep statistics
+There is no reason why your Python_ interpreter could not keep statistics
of how it is being used, and automatically select from a collection of
algorithms the one which is best suited for the data at hand.
-Dream number Eight -- How to avoid painful conversion of your code base
-to new versions of the language.
+Dream number Eight -- How to avoid painful conversion of your code base to new versions of the language.
+********************************************************************************************************
This dream is a bit far-fetched, but it is worth investigating. Right
-now, whenever a new release of Python comes out, existing Python
+now, whenever a new release of Python_ comes out, existing Python_
programs have to be modified whenever there are conflicts. Thus there
is a trade off between getting the new features which contribute to
increased productivity in program design, and having to fix piles of
@@ -169,15 +180,17 @@
and leave the old ones alone.
Dream number Nine: faster Python
+*********************************
While we are writing an adaptive, smarter compiler, we ought to be able
-to make it faster. We think faster than C Python is a realistic goal,
+to make it faster. We think faster than CPython is a realistic goal,
eventually. When faster algorithms are discovered, we will be able to
quickly place them in the interpreter, because the components are
more or less independent. This is something that Armin Rigo
and Christian Tismer know a lot about, and I know very little.
-Dream number Ten: world domination and ....
+Dream number Ten: world domination and all that ...
+****************************************************
(Well, if we can pull off Dreams 1-9, this should just drop out of the
design...)
@@ -186,19 +199,19 @@
But away from the dreams and back to what do we currently have?
-We currently implement (or partially implement) two Object Spaces, and
-have plans to implement a third in short order.
+We currently have three object spaces partially implemented.
-1. The Trivial Object Space
+The Trivial Object Space
+++++++++++++++++++++++++
A PyPy interpreter using the TrivialObjectSpace is an interpreter with
-its own main loop (written in Python), and nothing else. This main
-loop manipulates real Python objects and all operations are done
-directly on the Python objects. For example, "1" really means "1" and
+its own main loop (written in Python_), and nothing else. This main
+loop manipulates real Python_ objects and all operations are done
+directly on the Python_ objects. For example, "1" really means "1" and
when the interpreter encounters the BINARY_ADD bytecode instructions
-the TrivialObjectSpace will just add two real Python objects together
-using Python's "+". The same for lists, dictionaries, classes... We
-just use Python's own.
+the TrivialObjectSpace will just add two real Python_ objects together
+using Python_'s "+". The same for lists, dictionaries, classes... We
+just use Python_'s own.
This Object Space is only useful for testing the concept of Object Spaces,
and our interpreter, or even interpreting different kinds of bytecodes.
@@ -209,10 +222,11 @@
It demonstrated that our Object Space Concept was viable, and that our
interpreter worked.
-2. The Standard Object Space
+The Standard Object Space
+++++++++++++++++++++++++++
The Standard Object Space is the object space that works just like
-Python's, that is, the object space whose black boxes are real Python
+Python_'s, that is, the object space whose black boxes are real Python_
objects that work as expected. This is where the bulk of the work in
PyPy has been done to date. Getting the Standard Object Space to
work was a goal of the Gothenburg Sprint May 24 - 31.
@@ -225,104 +239,63 @@
to run. We needed types and builtins to work. This ran, slowly.
Then we added strings. Getting this code to work was the second
-goal.
+goal.::
-### a trivial program to test strings, lists, functions and methods ###
+ ### a trivial program to test strings, lists, functions and methods ###
-def addstr(s1,s2):
+ def addstr(s1,s2):
return s1 + s2
-str = "an interesting string"
-str2 = 'another::string::xxx::y:aa'
-str3 = addstr(str,str2)
-arr = []
-for word in str.split():
+ str = "an interesting string"
+ str2 = 'another::string::xxx::y:aa'
+ str3 = addstr(str,str2)
+ arr = []oscon2003-paper.txt
+ for word in str.split():
if word in str2.split('::'):
arr.append(word)
-print ''.join(arr)
-print "str + str2 = ", str3
+ print ''.join(arr)
+ print "str + str2 = ", str3
This we accomplished by mid-week.
-By the end of the Sprint we produced our first Python program that
+By the end of the Sprint we produced our first Python_ program that
ran under PyPy which simply 'did something we wanted to do' and wasn't
an artificial goal. Specifically, it calculated the share in foodbill
for each of the 9 Sprint participants.
+::
+### the first use of PyPy as a tool to do something else ###
slips=[(1, 'Kals MatMarkn', 6150, 'Chutney for Curry', 'dinner Saturday'),
(2, 'Kals MatMarkn', 32000, 'Spaghetti, Beer', 'dinner Monday'),
(2, 'Kals MatMarkn', -810, 'Deposit on Beer Bottles', 'various'),
(3, 'Fram', 7700, 'Rice and Curry Spice', 'dinner Saturday'),
- (4, 'Kals MatMarkn', 25000, 'Alcohol-Free Beer, sundries', 'various'),
- (4, 'Kals MatMarkn', -1570, "Michael's toothpaste", 'none'),
- (4, 'Kals MatMarkn', -1690, "Laura's toothpaste", 'none'),
- (4, 'Kals MatMarkn', -720, 'Deposit on Beer Bottles', 'various'),
- (4, 'Kals MatMarkn', -60, 'Deposit on another Beer Bottle', 'various'),
- (5, 'Kals MatMarkn', 26750, 'lunch bread meat cheese', 'lunch Monday'),
- (6, 'Kals MatMarkn', 15950, 'various', 'dinner Tuesday and Thursday'),
- (7, 'Kals MatMarkn', 3650, 'Drottningsylt, etc.', 'dinner Thursday'),
- (8, 'Kals MatMarkn', 26150, 'Chicken and Mushroom Sauce', 'dinner Wed'),
- (8, 'Kals MatMarkn', -2490, 'Jacob and Laura -- juice', 'dinner Wed'),
- (8, 'Kals MatMarkn', -2990, "Chicken we didn't cook", 'dinner Wednesday'),
- (9, 'Kals MatMarkn', 1380, 'fruit for Curry', 'dinner Saturday'),
- (9, 'Kals MatMarkn', 1380, 'fruit for Curry', 'dinner Saturday'),
- (10, 'Kals MatMarkn', 26900, 'Jansons Frestelse', 'dinner Sunday'),
- (10, 'Kals MatMarkn', -540, 'Deposit on Beer Bottles', 'dinner Sunday'),
- (11, 'Kals MatMarkn', 22650, 'lunch bread meat cheese', 'lunch Thursday'),
- (11, 'Kals MatMarkn', -2190, 'Jacob and Laura -- juice', 'lunch Thursday'),
- (11, 'Kals MatMarkn', -2790, 'Jacob and Laura -- cereal', 'lunch Thurs'),
- (11, 'Kals MatMarkn', -760, 'Jacob and Laura -- milk', 'lunch Thursday'),
- (12, 'Kals MatMarkn', 18850, 'lunch bread meat cheese', 'lunch Friday'),
- (13, 'Kals MatMarkn', 18850, 'lunch bread meat cheese', 'guestimate Sun'),
- (14, 'Kals MatMarkn', 18850, 'lunch bread meat cheese', 'guestimate Tues'),
- (15, 'Kals MatMarkn', 20000, 'lunch bread meat cheese', 'guestimate Wed'),
- (16, 'Kals MatMarkn', 42050, 'grillfest', 'dinner Friday'),
- (16, 'Kals MatMarkn', -1350, 'Deposit on Beer Bottles', 'dinner Friday'),
- (17, 'System Bolaget', 15500, 'Cederlunds Caloric', 'dinner Thursday'),
- (17, 'System Bolaget', 22400, '4 x Farnese Sangiovese 56SEK', 'various'),
- (17, 'System Bolaget', 22400, '4 x Farnese Sangiovese 56SEK', 'various'),
- (17, 'System Bolaget', 13800, '2 x Jacobs Creek 69SEK', 'various'),
- (18, 'J and Ls winecabinet', 10800, '2 x Parrotes 54SEK', 'various'),
- (18, 'J and Ls winecabinet', 14700, '3 x Saint Paulin 49SEK', 'various'),
- (18, 'J and Ls winecabinet', 10400, '2 x Farnese Sangioves 52SEK','cheaper when we bought it'),
- (18, 'J and Ls winecabinet', 17800, '2 x Le Poiane 89SEK', 'various'),
- (18, 'J and Ls winecabinet', 9800, '2 x Something Else 49SEK', 'various'),
- (19, 'Konsum', 26000, 'Saturday Bread and Fruit', 'Slip MISSING'),
- (20, 'Konsum', 15245, 'Mooseburgers', 'found slip'),
- (21, 'Kals MatMarkn', 20650, 'Grilling', 'Friday dinner'),
- (22, 'J and Ls freezer', 21000, 'Meat for Curry, grilling', ''),
- (22, 'J and Ls cupboard', 3000, 'Rice', ''),
- (22, 'J and Ls cupboard', 4000, 'Charcoal', ''),
(23, 'Fram', 2975, 'Potatoes', '3.5 kg @ 8.50SEK'),
(23, 'Fram', 1421, 'Peas', 'Thursday dinner'),
- (24, 'Kals MatMarkn', 20650, 'Grilling', 'Friday dinner'),
- (24, 'Kals MatMarkn', -2990, 'TP', 'None'),
- (24, 'Kals MatMarkn', -2320, 'T-Gul', 'None')
+ ...
]
-print [t[2] for t in slips]
-print (reduce(lambda x, y: x+y, [t[2] for t in slips], 0))/900
+print (reduce(lambda x, y: x+y, [t[2] for t in slips], 0))/900 [#]_
Pypy said: 603. Dinner for a week cost 603 Swedish Krona -- or approximately
50$ US. So if we can't have world domination, or get our Object Space
to work, a new career in Sprint cost control beckons. :-)
-3. The Translate Object Space
+3. The Annotate Object Space
-The Translate Object Space is the next goal. It is an example of an
+The Annotate Object Space is the next goal. It is an example of an
ObjectSpace that differs a lot from StandardObjectSpace. We have to
-translate the Python code we have into C code. This is the sine qua
+translate the Python_ code we have into C code. This is the sine qua
non condition for our work to be actually usable. Quite unexpectedly,
the major piece of the translator is itself an object space, the
-TranslateObjectSpace. Its goal is to run any Python code and produce C
+AnnotateObjectSpace. Its goal is to run any Python_ code and produce C
code in the background as it does so.
-Specifically, we take our PyPy interpreter with the Translate Object
+Specifically, we take our PyPy interpreter with the Annotate Object
Space instead of the Standard Object Space, and run that, asking it to
interpret our generated bytecode. A wrapped object is now the name of
a variable in the C program we are emitting, for example:
- The add method in the Translate Object Space takes two variable
+The add method in the Annotate Object Space takes two variable
names, x and y, and emits the C code z = x + y; where z is a new variable
name which is returned as the result of add. (We will actually need to
make the wrapped objects a bit more elaborate so that we can also record,
@@ -372,7 +345,7 @@
implementations. The convertion can give a result of a different type
(e.g. int -> float) or of the same type (e.g. W_VeryLongString ->
str). There is a global table of delegators. We should not rely on the
-delegators to be tried in any particular order, or at all (e.g. the int
+delegators to be tried in any particlar order, or at all (e.g. the int
-> float delegator could be ignored when we know that no registered
function will accept a float anyway).
@@ -463,4 +436,116 @@
Some multimethods can also be sliced along their second argument,
e.g. for __radd__().
-
\ No newline at end of file
+
+.. [#] The PyPy homespage: http://www.codespeak.net/pypy/
+.. [#] See for instance, *lunacy* http://www.nightmare.com/~rushing/lunacy/
+.. [#] The Squeak homespage: http://www.squeak.org/
+.. [#] See *Back to the Future The Story of Squeak, A Practical
+ Smalltalk Written in Itself* ftp://st.cs.uiuc.edu/Smalltalk/Squeak/docs/OOPSLA.Squeak.html
+.. [#] CPython is what we call the commonly available Python_ which you
+ can download from http://www.python.org . This is to distinguish it
+ from other implementations of the Python_ language, such as
+ Jython_, which is written for the Java virtual machine.
+.. [#] The Psyco homespage: http://psyco.sourceforge.net/
+.. [#] The Stackless homespage: http://www.stackless.com/
+.. [#] The Jython homespage: http://www.jython.org/
+.. [#] The complete text is as follows:
+
+.. line-block::
+
+ *The Zen of Python*
+
+ by Tim Peters
+
+.. line-block::
+
+ *Beautiful is better than ugly.
+ Explicit is better than implicit.
+ Simple is better than complex.
+ Complex is better than complicated.
+ Flat is better than nested.
+ Sparse is better than dense.
+ Readability counts.
+ Special cases aren't special enough to break the rules.
+ Although practicality beats purity.
+ Errors should never pass silently.
+ Unless explicitly silenced.
+ In the face of ambiguity, refuse the temptation to guess.
+ There should be one-- and preferably only one --obvious way to do it.
+ Although that way may not be obvious at first unless you're Dutch.
+ Now is better than never.
+ Although never is often better than **right** now.
+ If the implementation is hard to explain, it's a bad idea.
+ If the implementation is easy to explain, it may be a good idea.
+ Namespaces are one honking great idea -- let's do more of those!*
+
+.. [#] The full text for historians and other curious people is:
+
+.. line-block::
+
+ slips=[
+ (1, 'Kals MatMarkn', 6150, 'Chutney for Curry', 'dinner Saturday'),
+ (2, 'Kals MatMarkn', 32000, 'Spaghetti, Beer', 'dinner Monday'),
+ (2, 'Kals MatMarkn', -810, 'Deposit on Beer Bottles', 'various'),
+ (3, 'Fram', 7700, 'Rice and Curry Spice', 'dinner Saturday'),
+ (4, 'Kals MatMarkn', 25000, 'Alcohol-Free Beer, sundries', 'various'),
+ (4, 'Kals MatMarkn', -1570, "Michael's toothpaste", 'none'),
+ (4, 'Kals MatMarkn', -1690, "Laura's toothpaste", 'none'),
+ (4, 'Kals MatMarkn', -720, 'Deposit on Beer Bottles', 'various'),
+ (4, 'Kals MatMarkn', -60, 'Deposit on another Beer Bottle', 'various'),
+ (5, 'Kals MatMarkn', 26750, 'lunch bread meat cheese', 'lunch Monday'),
+ (6, 'Kals MatMarkn', 15950, 'various', 'dinner Tuesday and Thursday'),
+ (7, 'Kals MatMarkn', 3650, 'Drottningsylt, etc.', 'dinner Thursday'),
+ (8, 'Kals MatMarkn', 26150, 'Chicken and Mushroom Sauce', 'dinner Wed'),
+ (8, 'Kals MatMarkn', -2490, 'Jacob and Laura -- juice', 'dinner Wed'),
+ (8, 'Kals MatMarkn', -2990, "Chicken we didn't cook", 'dinner Wednesday'),
+ (9, 'Kals MatMarkn', 1380, 'fruit for Curry', 'dinner Saturday'),
+ (9, 'Kals MatMarkn', 1380, 'fruit for Curry', 'dinner Saturday'),
+ (10, 'Kals MatMarkn', 26900, 'Jansons Frestelse', 'dinner Sunday'),
+ (10, 'Kals MatMarkn', -540, 'Deposit on Beer Bottles', 'dinner Sunday'),
+ (11, 'Kals MatMarkn', 22650, 'lunch bread meat cheese', 'lunch Thursday'),
+ (11, 'Kals MatMarkn', -2190, 'Jacob and Laura -- juice', 'lunch Thursday'),
+ (11, 'Kals MatMarkn', -2790, 'Jacob and Laura -- cereal', 'lunch Thurs'),
+ (11, 'Kals MatMarkn', -760, 'Jacob and Laura -- milk', 'lunch Thursday'),
+ (12, 'Kals MatMarkn', 18850, 'lunch bread meat cheese', 'lunch Friday'),
+ (13, 'Kals MatMarkn', 18850, 'lunch bread meat cheese', 'guestimate Sun'),
+ (14, 'Kals MatMarkn', 18850, 'lunch bread meat cheese', 'guestimate Tues'),
+ (15, 'Kals MatMarkn', 20000, 'lunch bread meat cheese', 'guestimate Wed'),
+ (16, 'Kals MatMarkn', 42050, 'grillfest', 'dinner Friday'),
+ (16, 'Kals MatMarkn', -1350, 'Deposit on Beer Bottles', 'dinner Friday'),
+ (17, 'System Bolaget', 15500, 'Cederlunds Caloric', 'dinner Thursday'),
+ (17, 'System Bolaget', 22400, '4 x Farnese Sangiovese 56SEK', 'various'),
+ (17, 'System Bolaget', 22400, '4 x Farnese Sangiovese 56SEK', 'various'),
+ (17, 'System Bolaget', 13800, '2 x Jacobs Creek 69SEK', 'various'),
+ (18, 'J and Ls winecabinet', 10800, '2 x Parrotes 54SEK', 'various'),
+ (18, 'J and Ls winecabinet', 14700, '3 x Saint Paulin 49SEK', 'various'),
+ (18, 'J and Ls winecabinet', 10400, '2 x Farnese Sangioves 52SEK','cheaper when we bought it'),
+ (18, 'J and Ls winecabinet', 17800, '2 x Le Poiane 89SEK', 'various'),
+ (18, 'J and Ls winecabinet', 9800, '2 x Something Else 49SEK', 'various'),
+ (19, 'Konsum', 26000, 'Saturday Bread and Fruit', 'Slip MISSING'),
+ (20, 'Konsum', 15245, 'Mooseburgers', 'found slip'),
+ (21, 'Kals MatMarkn', 20650, 'Grilling', 'Friday dinner'),
+ (22, 'J and Ls freezer', 21000, 'Meat for Curry, grilling', ''),
+ (22, 'J and Ls cupboard', 3000, 'Rice', ''),
+ (22, 'J and Ls cupboard', 4000, 'Charcoal', ''),
+ (23, 'Fram', 2975, 'Potatoes', '3.5 kg @ 8.50SEK'),
+ (23, 'Fram', 1421, 'Peas', 'Thursday dinner'),
+ (24, 'Kals MatMarkn', 20650, 'Grilling', 'Friday dinner'),
+ (24, 'Kals MatMarkn', -2990, 'TP', 'None'),
+ (24, 'Kals MatMarkn', -2320, 'T-Gul', 'None')
+ ]
+
+ print [t[2] for t in slips]
+ print (reduce(lambda x, y: x+y, [t[2] for t in slips], 0))/900
+
+.. [#] and the reason I used reduce instead of just a list comprehension
+ is that I had just finished writing unit tests for reduce -- Laura
+
+.. _Python: http://www.python.org/..
+.. _Squeak: http://www.squeak.org
+.. _Smalltalk: http://www.smalltalk.org/
+.. _Scheme: http://www.swiss.ai.mit.edu/projects/scheme/
+.. _PyPy: http://www.codespeak.net/pypy/
+.. _Jython: http://www.jython.org/
+.. _Psyco: http://psyco.sourceforge.net/
+.. _Stackless: http://www.stackless.com/
\ No newline at end of file
More information about the Pypy-commit
mailing list