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.)
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), Ellipses, slice(3, 4, None))
For more help with this you are referred to the matrix-sig.
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.