Next: 13.2 Run-time Changes Up: 13 New in Release Previous: 13 New in Release

# 13.1 Language Changes

• Power operator. `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)`.
• Complex numbers. Imaginary literals are writen with a `'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.)

• New indexing syntax. It is now possible to use a tuple as an indexing expression for a mapping object without parenthesizing it, e.g. `x[1, 2, 3]` is equivalent to `x[(1, 2, 3)]`.
• New slicing syntax. In support of the Numerical Python extension (distributed independently), slice indices of the form `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.

• The `access` statement is now truly gone; `access` is no longer a reserved word. This saves a few cycles here and there.
• Private variables through name mangling. There is now limited support for class-private identifiers. Any identifier of the form `__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.

Next: 13.2 Run-time Changes Up: 13 New in Release Previous: 13 New in Release

guido@cnri.reston.va.us