Contents

1 Introduction

Python is a wonderful language that manages to guide you to correct expression of complex algorithms through little code. Python has a great standard library, convenient fundamental datatypes, clean and pleasant syntax, and an import mechanism with just it time compilation (to bytecode), which proves one can have complex systems without makefiles or a complicated build process. But it’s slow. On average, 50-100 times slower than C, for numerical code 100-400 times slower.

We felt that in principle there was no reason for Python to be this slow, and that by giving up very little of what makes Python great, one could make most of this speed penalty go away. Greg Ewing proved 95% of this point by writing Pyrex. However, in some ways Pyrex did not feel very pythonic, there was a lot of overhead to writing in Pyrex that was absent in Python. In order to write a complex system in Pyrex, one has to spend a lot of time on header files and Makefiles, much like with a C project. One likely also has to write a significant amount of custom code to enable objects to be serialized to disk, to print and to compare them. In our experience with complex projects, this boilerplate soaks up a large fraction of the effort, all the more painful since none of it has anything to do with the essence of the project. Pex generates all of this boilerplate for you, and then also augments Pyrex to allow you to write C fast numerics with a standard array datatype that is fully supported in Python – numpy’s ndarray (see 8).

1.1 What You Are Assumed to Know

This document is not meant to be standalone: some knowledge of Python is assumed. A great deal of functionality of Pex attempts to match Python semantics. Pex is mostly Pyrex, so if you are not familiar with it, look through Appendix B and refer to Pyrex documentation as needed. It may also be useful to skim Cython documentation, though it does not have much at the moment (recall that Cython is a fork of the Pyrex project that Pex actually uses). We will also refer to numpy, which is a substantial numerical library for python.

1.2 A Word of Caution

You should be aware that Pex is not yet a full language. This early stage of Pex was always intended as a thin preprocessor layer for Pyrex. While immediately useful, this is our first, learning, attempt at capturing a blend of Python elegance and C performance. You’ll no doubt encounter difficult to chase down compilation errors and strange limitations, many stemming from the fact that Pex does not employ a parser, but rather gets by on regular expressions. Throughout this document we will attempt to give you a flavor of these gotchas.

1.3 Heroic Example

The reason to put up with Pex’s and Pyrex’s various quirks is that you can get massive performance improvements for not much difference in code. The sweep algorithm implemented in Pex is about 75 times faster than the Python implementation for a 10x10 matrix, about 400 times faster for matrices of size 100x100 and above; as you can see in the diff of the two codes, the differences are minimal. This example, while heroic, is not contrived, for numerics code you can expect to see two orders of magnitude improvement in running time.

2 Notation

Code snippets are given like so:

and unless otherwise specified are assumed to live in the file main.px (.px means a Pex file). Shell commands are prefixed with a “$”, thus to run the above snippet, we say:

Usually we will just show the resulting output

On occasion it is convenient to specify an entire directory tree, which we will do like so:

Here we have a main.px file in the current directory, and a directory pkg with an empty file __init__.py and a Python module file mod.py. The resulting output when main.px is ran, is:

Unless otherwise specified, if there is a main.px or main.py, it’s what is ran.

3 Getting Started

3.1 Simple Example

The venerable “hello world” program in Pex:

 
1def main(): 
2        print "hello␣world"

We ran it with “pex main.px” (see 2). Here is what happens behind the scenes:

1. Pex creates files main.pyx and main.pxd from main.px
2. Pyrex produces main.c from main.pyx and main.pxd
3. from here the C toolchain takes over:
   1. gcc makes main.o from main.c
   2. gcc makes main.so from main.o. The file main.so is an importable Python module.
4. now that main.so is made, Pex does the exact equivalent of the following Python code
    
   1#!/usr/bin/python 
   2import main 
   3main.main()

Essentially, after generating the Pyrex .pyx, .pxd files from the .px file, Pex ran the following sequence of commands:

3.2 Slightly Less Simple Example

Here, in accordance with software engineering best practices, we split the functionality of hello world into two modules:

 
1mod.px 
2        def func(): 
3                return "hello␣world" 
4 
5main.px 
6        %pimport mod 
7 
8        def main(): 
9                print mod.func()

The main module, uses %pimport to bring in another module, called mod and call its function (see 7 about pimports). To see what happened behind the scenes, in excruciating detail, run pex -vall -F main.px (the -vall flag sets verbosity to all, -F forces a rebuild of everything).

4 Conventions

Throughout the manual, we will be referring to code sections running at “C speed” or “Python speed”. Take x=x+3 for example. If x is a C int, this is effectively a C expression – it runs at C speed, but if x is a python object, this code runs at Python speed, getting translated into Python library calls along the lines of PyNumber_Add(x,PyInt_FromLong(3)). As a rough estimate, Python speed is 1-2 orders of magnitude slower than C, usually closer to 2.

We will also refer to compile time and runtime. Compile time is everything that happens to turn a .px file into a .so. Runtime is when the .so is loaded by Python, and your code is actually executing.

5 Interacting with Python

In Pex, you can import Python modules, and use them just as you would in Python. In particular here is an example that shows you how to access the command line:

 
1import sys 
2 
3def main(): 
4 
5        if sys.argv[1]==’Marco’: 
6                print ’Polo’ 
7 
8        elif sys.argv[1]==’Polo’: 
9                print ’Marco’

6 The main() function

The main() function has the same semantics as Python’s if __name__==’__main__’: clause. If your module has a main() function, and is executed from the command line, your main() is called. If your module is imported by something, main() is not called; for example if you have

 
1mod.px 
2        def main(): 
3                print "hello␣world" 
4 
5main.px 
6        %pimport mod

Code in the topmost scope is executed at import time, just like in Python, so in the following example, we do get output:

 
1mod.px 
2        print "hello␣world" 
3 
4main.px 
5        %pimport mod

:-(Do not write if __name__==’__main__’: in a Pex file, Pyrex defines __name__, but it never defines it to be "__main__", thus this if statement will happily compile, but will never be true.

7 Pimports

7.1 Simple

Imports work in Pex in the same way they do in Python, except you say %pimport instead of import. In the simplest form you say,

You may also use more complicated forms, like in Python, the full syntax is the following:

thus any of the following is valid:

 
1pkg/__init__.py 
2 
3pkg/submod.px 
4 
5        def func(): 
6                pass 
7 
8        cdef class Klass: 
9                pass 
10 
11mod.px 
12 
13        cdef func(): 
14                pass 
15 
16        class Klass: 
17                pass 
18 
19main.px 
20 
21        %pimport mod, pkg.submod 
22 
23        %pimport mod as foo, pkg.submod as bar 
24 
25        %from pkg.submod pimport func, Klass as baz 
26 
27        %from mod pimport func as gah, Klass

Imports are a weak point for Pex, Pyrex, and to some extent Python. There are some problem cases, some with errors easy to figure out, some not. Make sure you read the Gotchas section 7.2.2 below.

7.2 Elaborate

7.2.1 Search Path

The pimport search path machinery in Pex, works similarly to Python. There is a PEXPATH environment variable with semantics similar to PYTHONPATH, and there is a way to alter your Pex path from inside your modules. Whereas in Python you would say

in Pex you would say

See 12 for more information on compile time configuration.

7.2.2 Gotchas

:-(Like for Python, your Pex package directories need to contain an __init__.py file in order to be importable, an empty __init__.py file is sufficient. This is really easy to forget, and really annoying to discover, so be careful.

:-(This is a trick for troubleshooting your imports. Sometimes you can have name collisions between modules, and because Python memoizes imports by module name, your import will not give you the module object you expect. Suppose at some point earlier in the program, the module foo was imported, all later import foo statements will return this module, even if you are attempting to import a different foo, and according to the semantics of the search path can expect to get it. When this happens, you’ll start seeing errors like “module object doesn’t have expected attribute”, etc. A useful way of debugging is to just print foo at the point of the error, which shows what file the module came from, and print dir(foo), which shows the module’s attributes.

A particularly nasty, and not uncommon, manifestation of this problem is when foo is a directory that happens to have an __init__.py file, which makes the directory importable. Worse yet, an __init__.pyc alone is also sufficient. To fix, remove __init__.py AND __init__.pyc.

:-(Can not do pimport *.

:-(If you wish to subclass a class that you import from another module, you must pimport that module without using from or as; do this:

not this:

:-(Can not do pimport <module>.<var>, can only do pimport <module> and then refer to the variable as <module>.<var>, or from <module> pimport <var>.

:-(Though %pimport looks like a regular statement, it is not, it causes things to happen both at compile time and at runtime. This means that the following piece of code will not do what you may expect:

The if 0: is purely runtime statement, it does not actually bind the %pimport. Here, the %pimport is still processed at compile time, but not at runtime, and bad things will happen.

8 NDArray Decoration

8.1 Simple

In Python, [] accesses are slow. For example, make yourself a numpy array (henceforth referred to as “ndarray”), and then access it like so:

There is a lot of work that happens behind the scenes for that arr[1], here is just the partial C class stack:

All this overhead makes the [] access two orders of magnitude slower than if arr was a C double arr[] array. Pex lets you get that speed back by saying arr{1} instead, though before you are allowed to do so, you must “decorate” arr with some type information:

this arr{1} happens at C speed, as if arr was a C int * . Similarly for multiple dimensions:

 
1def main(): 
2        cdef ndarray<int,(2,3,4)> mat 
3 
4        cdef int i,j,k 
5 
6        for i from 0 <= i < mat.dimensions[0]: 
7                for j from 0 <= j < mat.dimensions[1]: 
8                        for k from 0 <= k < mat.dimensions[2]: 
9 
10                                mat{i,j,k} = i+j+k 
11 
12        print mat

Supported types for a decorated ndarray are char,short,int,double, and object.

8.2 Elaborate

8.2.1 Decorating NDArrays

There are a few ways ndarrays may become decorated. The simplest is when an ndarray comes in as an argument to a function:

The general syntax is ndarray<TYPE DIMENSIONALITYd>. In the above example a 2 dimensional array of shorts is passed in. The type and dimensionality are checked, and if you try to pass in the wrong thing, an NDArrayDecorationError exception will be thrown.

There are also two ways to declare decorated ndarrays, the first is non-allocating:

The intention is that at some point later, the variable will be assigned an ndarray of the right type and dimensionality. Such assignments are typechecked, and an exception will be raised if the type or dimensionality is wrong. If you access your array before allocating it with something like arr = numpy.zeros(’d’,3), you will SEGFAULT (see 18 for complete discussion of this type of error).DEATH!

The other flavor of decorated declaration is allocating:

The above is equivalent to

The syntax for one dimensional ndarray declaration is ndarray<TYPE, DIMENSION1>, for multi-dimensional: ndarray<TYPE, (DIMENSION1,...,DIMENSIONn)>.

The last way to decorate an ndarray is the following:

It is provided as a hack, to work around the fact that Pex does only shallow type analysis. For example, if an object has an attribute that is a decorated ndarray, you will not be able to get the fast {} accesses outside of that object:

 
1cdef class item: 
2        def __init__(me): 
3                cdef ndarray<int,10> me.arr 
4 
5def main(): 
6        cdef item x = item() 
7        print x.arr{0}

Using %decorate you can do:

 
1cdef class item: 
2        def __init__(me): 
3                cdef ndarray<int,10> me.arr 
4 
5def main(): 
6        cdef item x = item() 
7        %decorate(x.arr, ndarray<int 1d>) 
8        print x.arr{0}

You must do the same to access a decorated ndarray attribute of a base class:

 
1cdef class base: 
2        def __init__(me): 
3                cdef ndarray<int,10> me.arr 
4 
5cdef class item(base): 
6        def func(me): 
7                %decorate(me.arr, ndarray<int 1d>) 
8                print me.arr{0} 
9 
10item().func()

Note that you can only use %decorate with a typed, cdef’d ndarray (see B.2.4 for discussion about typed vs untyped objects).

8.2.2 Fast creation of NDArrays

Creating ndarrays using the numpy API is slow, the creation calls, like numpy.zeros(), have to plumb through the Python runtime. Pex provides a faster alternative:

where type is one of the decoration types char,short,int,double, or object. Here is an example:

The allocating declarations, e.g. cdef ndarray<double,(17,10,5)> arr, call these functions. For something even faster, there are also these calls

They have the same API as ndarray_zeros calls, but do not zero out the contents of the allocated ndarray, returning the memory as is. Thus the allocating declaration:

is equivalent to

and is slower than

For arrays of dimensionality bigger than 4, you are left with calling the Python numpy API.

8.2.3 Fast Decorated Slices

Slicing ndarrays – arr[4:7] – is slow. Things have to plumb through the Python runtime to get to the fast numpy code that creates the slice (note that an ndarray slice is not a copy, but a “view” into the parent array). Pex provides fast, “decorated” slices – arr{4:7}. The general idea is that for each dimension you specify a start:stop. Either start or stop can be negative, if so it is counted off the end. Either can be missing, if start is missing it is assumed to be zero, if stop is missing it is assumed to n, where n is length of the dimension. Either can go off the ends of the array, and is clipped to be inside [0,n]. These semantics come from Python, see python documentation for a more complete discussion. Python slices can also have a 3rd argument – stride – but this is not supported for decorated slices. Here are some examples:

 
1def main(): 
2        cdef ndarray<int, 10> arr 
3        cdef int                     i 
4 
5        for i from 0<=i<10: arr{i} = i 
6 
7        print "␣␣arr\n",arr 
8        print "\n␣␣{3:7}\n",arr{3:7} 
9        print "\n␣␣{:7}\n",arr{:7} 
10        print "\n␣␣{:}\n",arr{:} 
11        print "\n␣␣{-7:}\n",arr{-7:} 
12        print "\n␣␣{-7:-2}\n",arr{-7:-2}

similarly for multiple dimensions:

 
1def main(): 
2        cdef ndarray<object,(2,4)> arr 
3        cdef int                           i 
4 
5        for i from 0<=i<4: arr[0,i] = ’a’ + str(i) 
6        for i from 0<=i<4: arr[1,i] = ’b’ + str(i) 
7 
8        print "␣␣arr\n",arr 
9        print "\n␣␣{0:1,2:4}\n",arr{0:1,2:4} 
10        print "\n␣␣{:1,2:}\n",arr{:1,2:} 
11        print "\n␣␣{:,:}\n",arr{:,:} 
12        print "\n␣␣{1,0:1}\n",arr{1,0:1} 
13        print "\n␣␣{0,-2:}\n",arr{0,-2:} 
14        print "\n␣␣{:,2}\n",arr{:,2}

8.2.4 The object type

One of the supported types for decorated ndarrays is object, it is different from the other types char,short,int,double. The others are primitive C types, whereas each object is a Python object, and thus has an associated reference count, which is how garbage collection works in Python. Pex does the right thing for the reference count as objects are read and written to the array.

8.2.5 Type Checking

When you assign to a decorated ndarray, or when you create one by decorating an argument to a function, the operation is type checked at runtime to make sure an ndarray of the right type and dimensionality is coming in. In the following example we attempt to assign an ndarray of an incorrect type:

 
1def main(): 
2        cdef ndarray<double 1d> arr 
3        arr = ndarray_empty1(10,’int’)

 
1%whencompiling: scope.pragma_ndarray_type_check = False 
2 
3def main(): 
4        cdef ndarray<double 1d> arr 
5        arr = ndarray_empty1(10,’int’)

 
1%whencompiling: 
2        scope.pragma_ndarray_type_check = False 
3 
4cdef func(ndarray<double 1d> arr): pass 
5 
6%whencompiling: 
7        scope.pragma_ndarray_type_check = True

8.2.6 Bounds Checking

Normal {} accesses to decorated ndarrays are not bounds checked - hence their speed. They are just like C array accesses, you may read off the end of the array and thus get garbage, or write off the end of the array and thus corrupt memory. Pex allows you to turn on bounds checking, all the {} then become slow (a 50x50 matrix multiply runs 20 times slower with bounds checks on), but safe, the array bounds are checked for every access. Turning on bounds checking is probably the first thing to try if your program coredumps.

Here we access off the end of the array, and without bounds checking, get no errors:

 
1def main(): 
2    cdef ndarray<double,10> arr 
3    x=arr{11}

 
1%whencompiling: 
2    scope.pragma_ndarray_bounds_checks = True 
3 
4def main(): 
5    cdef ndarray<double,10> arr 
6    x=arr{11}

There are two ways to turn on bounds checking: using the pragma, as shown above, or passing -b to the Pex command line.

:-(If you wish to turn on bounds checking, all assignments to elements of decorated ndarrays must appear as the first thing on a line, do this:

instead of this:

8.2.7 Gotchas

:-(SLOWTo get the lengths of an ndarray, use .dimensions instead of .shape, do this:

not this:

Though they look similar, .shape is a Python tuple, getting it as an attribute of an ndarray is slow, and accessing its elements is slow. When you use .dimensions things run a C speed, since dimensions is a C attribute of the ndarray and is a C array. Be careful, as it is a C array, its accesses are not bounds checked.

:-(DEATH!Do not use negative indices with {} accesses. If you do, you’ll access garbage memory from before the beginning of the ndarray, same as would happen with a C array. Turning on bounds checks (see 8.2.6) will detect this error.

:-(Can not have global decorated ndarrays.

:-(Can not do

must do

:-(If you have a decorated ndarray as an attribute of a cdef class, you can not access it with {} outside of the class, or even in subclasses. This is a result of Pex’s lack of an honest type system. See 8.2.1 for how to overcome this limitation with %decorate.

:-(Can not use {} accesses inside declarations, e.g. can not do cdef int x=arr{i}.

:-(Believe it or not, {} are erroneously treated as accesses even inside strings, so the following:

will error unless you happen to have a 2d decorated ndarray named arr in the scope.

:-(SLOWYou must make sure index variables you use with {} accesses are cdef’d ints, otherwise things will be slow:

In the snippet above, i is a Python object, and gets converted to a C int for every {} access, and thus every time through the loop. Instead do:

:-(SLOWUse the following loop form:

instead of

Otherwise things will be slow (this is Pyrex syntax that allows you to write C fast loops).

This can happen in several ways. For one, due to its limitations, Pex is only able to track simple, arr= <...> style assignments, and for example does not see arr, b = <...>. Thus the following example silently corrupts memory:

As a hack around this, assign the array to itself, this forces unpacking of the internals:

Here is another way memory can get corrupted, suppose you have a decorated ndarray that is a class attribute. From inside the class method, you call another class method which re-assigns the attribute:

The above corrupts memory, you need to add me.arr = me.arr after me.change() in func to force the internals to be re-unpacked after the call to change.

:-(Pex gives you two ways to declare class attributes (see C.1 for full discussion), in the class preamble, and inside the __init__ method. Allocating ndarrays declarations, however, may only be declared inside the __init__ method, therefore do this:

not this:

Non-allocating declarations you may still put in the preamble:

9 Modest Cdef Classes

9.1 Simple

When you write a cdef class in Pyrex (see B.2.3 about why you may want to), a lot of the niceties you get for free with Python classes go away. Some of the downsides: you can’t print the resulting objects, can’t compare them for equality, can’t access their attributes from Python, and most importantly can’t automatically write/read them from disk (“pickling” in pythonese). Pex brings a lot of these niceties back, provided your cdef class is “modest” – its attributes come from a restricted set of types.

To make yourself a modest cdef class, restrict your attributes to the following types:

1. bool, char, uchar, short, ushort, int, uint, int64, uint64, float, double: these are primitive C types (see 11 for more info)
2. object: this is Pyrex’s type name for any Python object (list, tuple, class, etc)
3. <any_other_cdef_class>: this is foo if you have cdef class foo: defined somewhere.

Thus the following is a modest cdef class:

 
1cdef class modest: 
2        def __init__(me): 
3                cdef int    me.i 
4                cdef object me.ob = [1, 2, 3, 4]

 
1cdef class immodest: 
2        cdef int *modesty_violating_pointer

 
1cdef class unspoiled: 
2        def __init__(me): 
3                cdef int                   me.i 
4                cdef ndarray<char,(10,10)> me.arr

 
1cdef class modest_but_not_unspoiled: 
2        def __init__(me): 
3                cdef ndarray me.arr

9.2 Elaborate

9.2.1 One Pragma to Rule Them All

Each of the niceties described below, has its own pragma switch, but there is also one pragma that turns off all of the automatically generated methods described in this section:

9.2.2 __str__() – conversion to a string

cdef class requirements: modesty

The __str__() method is called by Python when you attempt to print an object, or convert it to a string. If it is absent, a less exciting string is produced, showing the object’s type and memory address. For example, this is what you get when you turn off __str__() method generation:

 
1%whencompiling: scope.pragma_gen_strmeth=False 
2 
3cdef class item: 
4        cdef int x 
5 
6print item()

If you leave it in, you get:

 
1cdef class item: 
2        cdef int x 
3 
4print item()

One possible reason to turn it off, is if you intend to write a custom __str__() method.

9.2.3 _equal_()

cdef class requirements: modesty

This method allows you to compare two modest cdef classes:

 
1cdef class item: 
2        cdef int i 
3 
4cdef item x=item(), y=item() 
5 
6print x._equal_(y) 
7y.i=7 
8print x._equal_(y)

Gotchas

:-(SLOWUnless all of your attributes are primitive C types, the _equal_() will happen at Python speeds. In principle, for attributes that are cdef classes or ndarrays it could be C fast, but at the moment isn’t.

:-(This is a cdef method, and so not callable from Python directly. However you can access it through == and !=, see next section.

9.2.4 __richcmp__() – Python comparisons

cdef class requirements: modesty

When Pyrex sees a == or != comparison between two cdef classes, it calls the __richcmp__() method of one of the objects. If this method is absent, the two objects are compared based on their memory address, thus even if two instances have every attribute the same, they will never be equal:

 
1%whencompiling: scope.pragma_gen_richcmpmeth = False 
2 
3cdef class item: 
4        cdef int i 
5 
6cdef item x=item(), y=item() 
7print x,y 
8print x==y

Pex generates this method to call the generated _equal_() method (see previous section), and this causes the == and != checks to happen based on the actual contents of the two objects, not just their memory addresses:

 
1cdef class item: 
2        cdef int i 
3 
4cdef item x=item(), y=item() 
5print x,y 
6print x==y

Gotchas

:-(SLOWThese == and != checks are slow because they plumb through Python.

9.2.5 _todict_(), _fromdict_() – dict coercion

cdef class requirements: modesty

Attributes of cdef classes are not visible from Python. This is illustrated by the following example where we are not able to access the attribute i from main.py:

 
1mod.px 
2        cdef class item: 
3                cdef int i 
4 
5main.py 
6        import pex 
7        mod = pex.pimport(’mod’) 
8        ob = mod.item() 
9        print ob.i

To overcome this limitation, Pex generates two methods for your cdef classes: _todict_() returns the cdef class’ attributes in a dictionary, _fromdict_() sets them from a dictionary:

 
1mod.px 
2        cdef class item: 
3                cdef int i 
4 
5main.py 
6        import pex 
7        mod = pex.pimport(’mod’) 
8 
9        ob = mod.item() 
10        print ’ob␣␣’,ob 
11 
12        d = ob._todict_() 
13        print ’dict’,d 
14 
15        ob._fromdict_({’i’: 17}) 
16        print ’ob␣␣’,ob

Gotchas

:-(Any extra keys in the dictionary that is passed into _fromdict_() are ignored. For example ob._fromdict_({’i’: 17, ’rubberchicken’: True}) would have worked just as well in the above example.

9.2.6 __reduce__(), __setstate__() – Python pickling

cdef class requirements: modesty

Normal Pyrex cdef classes are not “picklable” (pickling is Python’s term for serialization – writing and reading objects from disk). Pex automatically generates two special Python methods __reduce__() and __setstate__(), which make your cdef classes picklable. It is unlikely you’ll ever need to call these functions directly.

A thing of note is that the Python’s object copy machinery also works through these methods, and so their presence makes your cdef classes copiable:

 
1import copy 
2 
3cdef class item: 
4        cdef int i 
5 
6cdef item x = item() 
7x.i = 3 
8y   = copy.copy(x)

Gotchas

:-(If you have a list of cdef class objects you wish to pickle, do not dump them one at a time like so:

Instead do the whole list at once:

Pex dumps a type signature once for every dump invocation, thus once for every object when you write them one at a time. This unnecessarily, and possibly substantially, increases your storage requirements. In the second case, when you write the entire list at once, the type signature is written only once.

9.2.7 _fastload_(), _fastdump_() – fastio

cdef class requirements: must be unspoiled

If your cdef class is unspoiled, in addition to being modest (see 9.1), Pex will generate the two methods, _fastload_() and _fastdump_(), which implement a serialization scheme called “fastio”. It is slightly less convenient to use than pickling, but is 10-12 times faster. Here is an example showing basic usage:

 
1cdef class item: 
2        cdef int i 
3 
4cdef item x = item() 
5 
6x._fastdump_(open(’tempfile’,’w’)) 
7 
8cdef item y = item() 
9 
10y._fastload_(open(’tempfile’))