x**y is equivalent to pow(x, y).
This operator binds more tightly than *, / or %,
and binds from right to left when repeated or combined with unary
operators. For example, x**y**z is equivalent to
x**(y**z), and -x**y is -(x**y).'j'
suffix ('J' is allowed as well.) Complex numbers with a nonzero
real component are written as (real+imagj). You
can also use the new built-in function complex() which takes
one or two arguments: complex(x) is equivalent to x +
0j, and complex(x, y) is x + y*0j. For example,
1j**2 yields complex(-1.0) (which is another way of
saying ``the real value 1.0 represented as a complex number.''
Complex numbers are always represented as two floating point numbers,
the real and imaginary part.
To extract these parts from a complex number z,
use z.real and z.imag. The conversion functions to
floating point and integer (float(), int() and
long()) don't work for complex numbers -- there is no one
correct way to convert a complex number to a real number. Use
abs(z) to get its magnitude (as a float) or z.real to
get its real part.
Module cmath provides versions of all math functions that take
complex arguments and return complex results. (Module math
only supports real numbers, so that math.sqrt(-1) still raises
a ValueError exception. Numerical experts agree that this is
the way it should be.)
x[1, 2, 3] is equivalent to x[(1, 2, 3)].x[lo:hi:stride] are possible, multiple slice indices separated by
commas are allowed, and an index position may be replaced by an ellipsis,
as follows: x[a, ..., z]. There's also a new built-in function
slice(lo, hi, stride) and a new built-in object
Ellipsis, which yield the same effect without using special
syntax. None of the standard sequence types support indexing with
slice objects or ellipses yet.
Note that when this new slicing syntax is used, the mapping interface
will be used, not the sequence interface. In particular, when a
user-defined class instance is sliced using this new slicing syntax,
its __getitem__ method is invoked -- the
__getslice__ method is only invoked when a single old-style
slice is used, i.e. x[lo:hi], with possible omission of
lo and/or hi. Some examples:
x[0:10:2] -> slice(0, 10, 2)
x[:2:] -> slice(None, 2, None)
x[::-1] -> slice(None, None, -1)
x[::] -> slice(None, None, None)
x[1, 2:3] -> (1, slice(2, 3, None))
x[1:2, 3:4] -> (slice(1, 2, None), slice(3, 4, None))
x[1:2, ..., 3:4] -> (slice(1, 2, None), Ellipsis,
slice(3, 4, None))
For more help with this you are referred to the matrix-sig.
access statement is now truly gone; access is no
longer a reserved word. This saves a few cycles here and there.__spam (at least two
leading underscores, at most one trailing underscore) is now textually
replaced with _classname__spam, where classname is the
current class name with leading underscore(s) stripped. This mangling
is done without regard of the syntactic position of the identifier, so
it can be used to define class-private instance and class variables,
methods, as well as globals, and even to store instance variables
private to this class on instances of other classes. Truncation
may occur when the mangled name would be longer than 255 characters.
Outside classes, or when the class name consists of only underscores,
no mangling occurs.
Name mangling is intended to give classes an easy way to define ``private'' instance variables and methods, without having to worry about instance variables defined by derived classes, or mucking with instance variables by code outside the class. Note that the mangling rules are designed mostly to avoid accidents; it still is possible for a determined soul to access or modify a variable that is considered private. This can even be useful, e.g. for the debugger, and that's one reason why this loophole is not closed. (Buglet: derivation of a class with the same name as the base class makes use of private variables of the base class possible.)
Notice that code passed to exec, eval() or
evalfile() does not consider the classname of the invoking
class to be the current class; this is similar to the effect of the
global statement, the effect of which is likewise restricted to
code that is byte-compiled together. The same restriction applies to
getattr(), setattr() and delattr(), as well as
when referencing __dict__ directly.
Here's an example of a class that implements its own
__getattr__ and __setattr__ methods and stores all
attributes in a private variable, in a way that works in Python 1.4 as
well as in previous versions:
class VirtualAttributes:
__vdict = None
__vdict_name = locals().keys()[0]
def __init__(self):
self.__dict__[self.__vdict_name] = {}
def __getattr__(self, name):
return self.__vdict[name]
def __setattr__(self, name, value):
self.__vdict[name] = value
Warning: this is an experimental feature. To avoid all
potential problems, refrain from using identifiers starting with
double underscore except for predefined uses like __init__. To
use private names while maintaining future compatibility: refrain from
using the same private name in classes related via subclassing; avoid
explicit (manual) mangling/unmangling; and assume that at some point
in the future, leading double underscore will revert to being just a
naming convention. Discussion on extensive compile-time declarations
are currently underway, and it is impossible to predict what solution
will eventually be chosen for private names. Double leading
underscore is still a candidate, of course -- just not the only one.
It is placed in the distribution in the belief that it is useful, and
so that widespread experience with its use can be gained. It will not
be removed without providing a better solution and a migration path.