Emulates behavior of

from <module> import *

For some reason, it actually makes it slower in some of the most common cases (now commented out). Why? It does help in others.

Now if you inherit cdef methods from another class, you may re-declare the
arguments and return variables to be sub-types of the original declared type.
This will be especially convenient for the SAGE arithmetic architecture.
Type-checking is performed if necessary.

One rarely, if ever, wants the [step] argument to be negative.

Compile-time checking for builtin names, cast TypeObjects to PyObject* so c compiler won't complain.

E.g.

for i from 0 <= i < 10 by 2:
    print i

0
2
4
6
8

Old for-from loops remain exactly the same (using the ++ or --). If step is specified, the increment operator will be += step or -= step, depending on the orientation of the inequalities (as before).

NOTE: 'by' is now a keyword

Added a bint c type, which is a c int that coerces to and from python objects via the boolean routines.

The purpose of this type is to free the coder from having to use
bool() when retrieving and returning semantically "boolean" values
(e.g. the result of a compare).

The bint type is a subclass of the int type, and the only difference
is that it uses PyBool_FromLong and PyObject_IsTrue rather than
PyInt_FromLong and PyInt_AsLong. Arithmatic on bints will return ints.

Where it makes sense, several builtin functions have been re-declared
to return bints, as well as comparisons and the boolean operations
or, and, and not.

The code "__Pyx_GetName(__pyx_b, __pyx_n_[string])" is performed in several
thousand places throughout the sage library, and can be quite expensive
(a dictionary lookup, possibly raising an error, etc.) This is redundant
as the result will always be the same. I perform the lookup once
(on loading the module), then have a pointer to the result for all subsequent use.

The most common examples are bool/str/int (both as function calls and
in isinstance), True/False, and raisign errors.

A side feature is that on loading a module with an illegal __builtin__ name,
it will complain at load time rather than at run time.

"cdef inline foo()" now valid, and will place inline in the resulting c code

"cdef o = expr" and "cdef type x = expr" now valid.
This may not seem like a huge change, but it ended up requiring
quite a bit of work. The variables are still all declared at the
top, but the assignment takes place at the specified line in the
code.

If an assignment is made at declaration, the variable is initalized to
0 rather than None (also skipping an INCREF) and Py_XDECREF is used on
exiting the function (in case an error occured before the actual value
was calculated). Hence these variables MUST NOT be used before they are
defined or it will probably segfault.

add dummy py_index for cdef arrays so subexprs valid

Figured out how to use the Python/C API for some builtin functions (such as len) to avoid python calling conventions.

Changes in grammar required change for this, see http://www.python.org/dev/peps/pep-0308/
Most noteably for list comprehensions (dissambiguate the if)

- 5 times as fast for L[i], list/tuple L, cdef integer type i, 0 <= i < len(L)
- no change for L[a], python object a
- 1-1.5% slowdown for L[i], i negative or out of range