diff options
Diffstat (limited to 'Doc/whatsnew')
-rw-r--r-- | Doc/whatsnew/2.0.rst | 2 | ||||
-rw-r--r-- | Doc/whatsnew/2.1.rst | 4 | ||||
-rw-r--r-- | Doc/whatsnew/2.2.rst | 14 | ||||
-rw-r--r-- | Doc/whatsnew/2.3.rst | 8 | ||||
-rw-r--r-- | Doc/whatsnew/3.0.rst | 4 |
5 files changed, 16 insertions, 16 deletions
diff --git a/Doc/whatsnew/2.0.rst b/Doc/whatsnew/2.0.rst index 87462f3..4d49af1 100644 --- a/Doc/whatsnew/2.0.rst +++ b/Doc/whatsnew/2.0.rst @@ -506,7 +506,7 @@ arguments and/or a dictionary of keyword arguments. In Python 1.5 and earlier, you'd use the :func:`apply` built-in function: ``apply(f, args, kw)`` calls the function :func:`f` with the argument tuple *args* and the keyword arguments in the dictionary *kw*. :func:`apply` is the same in 2.0, but thanks to a patch -from Greg Ewing, ``f(*args, **kw)`` as a shorter and clearer way to achieve the +from Greg Ewing, ``f(*args, **kw)`` is a shorter and clearer way to achieve the same effect. This syntax is symmetrical with the syntax for defining functions:: diff --git a/Doc/whatsnew/2.1.rst b/Doc/whatsnew/2.1.rst index e55eaac..06366b8 100644 --- a/Doc/whatsnew/2.1.rst +++ b/Doc/whatsnew/2.1.rst @@ -442,8 +442,8 @@ Python syntax:: f.grammar = "A ::= B (C D)*" The dictionary containing attributes can be accessed as the function's -:attr:`__dict__`. Unlike the :attr:`__dict__` attribute of class instances, in -functions you can actually assign a new dictionary to :attr:`__dict__`, though +:attr:`~object.__dict__`. Unlike the :attr:`~object.__dict__` attribute of class instances, in +functions you can actually assign a new dictionary to :attr:`~object.__dict__`, though the new value is restricted to a regular Python dictionary; you *can't* be tricky and set it to a :class:`UserDict` instance, or any other random object that behaves like a mapping. diff --git a/Doc/whatsnew/2.2.rst b/Doc/whatsnew/2.2.rst index 885fd60..4e8d7fa 100644 --- a/Doc/whatsnew/2.2.rst +++ b/Doc/whatsnew/2.2.rst @@ -157,7 +157,7 @@ attributes and methods were supported by an object. There were some informal conventions, such as defining :attr:`__members__` and :attr:`__methods__` attributes that were lists of names, but often the author of an extension type or a class wouldn't bother to define them. You could fall back on inspecting -the :attr:`__dict__` of an object, but when class inheritance or an arbitrary +the :attr:`~object.__dict__` of an object, but when class inheritance or an arbitrary :meth:`__getattr__` hook were in use this could still be inaccurate. The one big idea underlying the new class model is that an API for describing @@ -169,7 +169,7 @@ possible, as well as more exotic constructs. Attribute descriptors are objects that live inside class objects, and have a few attributes of their own: -* :attr:`__name__` is the attribute's name. +* :attr:`~definition.__name__` is the attribute's name. * :attr:`__doc__` is the attribute's docstring. @@ -329,7 +329,7 @@ However, Python 2.2's support for :dfn:`properties` will often be a simpler way to trap attribute references. Writing a :meth:`__getattr__` method is complicated because to avoid recursion you can't use regular attribute accesses inside them, and instead have to mess around with the contents of -:attr:`__dict__`. :meth:`__getattr__` methods also end up being called by Python +:attr:`~object.__dict__`. :meth:`__getattr__` methods also end up being called by Python when it checks for other methods such as :meth:`__repr__` or :meth:`__coerce__`, and so have to be written with this in mind. Finally, calling a function on every attribute access results in a sizable performance loss. @@ -357,15 +357,15 @@ write:: That is certainly clearer and easier to write than a pair of :meth:`__getattr__`/:meth:`__setattr__` methods that check for the :attr:`size` attribute and handle it specially while retrieving all other attributes from the -instance's :attr:`__dict__`. Accesses to :attr:`size` are also the only ones +instance's :attr:`~object.__dict__`. Accesses to :attr:`size` are also the only ones which have to perform the work of calling a function, so references to other attributes run at their usual speed. Finally, it's possible to constrain the list of attributes that can be -referenced on an object using the new :attr:`__slots__` class attribute. Python +referenced on an object using the new :attr:`~object.__slots__` class attribute. Python objects are usually very dynamic; at any time it's possible to define a new attribute on an instance by just doing ``obj.new_attr=1``. A new-style class -can define a class attribute named :attr:`__slots__` to limit the legal +can define a class attribute named :attr:`~object.__slots__` to limit the legal attributes to a particular set of names. An example will make this clear:: >>> class C(object): @@ -383,7 +383,7 @@ attributes to a particular set of names. An example will make this clear:: AttributeError: 'C' object has no attribute 'newattr' Note how you get an :exc:`AttributeError` on the attempt to assign to an -attribute not listed in :attr:`__slots__`. +attribute not listed in :attr:`~object.__slots__`. .. _sect-rellinks: diff --git a/Doc/whatsnew/2.3.rst b/Doc/whatsnew/2.3.rst index b8cdcf1..fe8368e 100644 --- a/Doc/whatsnew/2.3.rst +++ b/Doc/whatsnew/2.3.rst @@ -1111,10 +1111,10 @@ Here are all of the changes that Python 2.3 makes to the core Python language. <type '_socket.socket'> * One of the noted incompatibilities between old- and new-style classes has been - removed: you can now assign to the :attr:`__name__` and :attr:`__bases__` + removed: you can now assign to the :attr:`~definition.__name__` and :attr:`~class.__bases__` attributes of new-style classes. There are some restrictions on what can be - assigned to :attr:`__bases__` along the lines of those relating to assigning to - an instance's :attr:`__class__` attribute. + assigned to :attr:`~class.__bases__` along the lines of those relating to assigning to + an instance's :attr:`~instance.__class__` attribute. .. ====================================================================== @@ -1920,7 +1920,7 @@ Changes to Python's build process and to the C API include: * If you dynamically allocate type objects in your extension, you should be aware of a change in the rules relating to the :attr:`__module__` and - :attr:`__name__` attributes. In summary, you will want to ensure the type's + :attr:`~definition.__name__` attributes. In summary, you will want to ensure the type's dictionary contains a ``'__module__'`` key; making the module name the part of the type name leading up to the final period will no longer have the desired effect. For more detail, read the API reference documentation or the source. diff --git a/Doc/whatsnew/3.0.rst b/Doc/whatsnew/3.0.rst index 044d7be..f53e4f8 100644 --- a/Doc/whatsnew/3.0.rst +++ b/Doc/whatsnew/3.0.rst @@ -783,8 +783,8 @@ Operators And Special Methods :attr:`func_closure`, :attr:`func_code`, :attr:`func_defaults`, :attr:`func_dict`, :attr:`func_doc`, :attr:`func_globals`, :attr:`func_name` were renamed to :attr:`__closure__`, - :attr:`__code__`, :attr:`__defaults__`, :attr:`__dict__`, - :attr:`__doc__`, :attr:`__globals__`, :attr:`__name__`, + :attr:`__code__`, :attr:`__defaults__`, :attr:`~object.__dict__`, + :attr:`__doc__`, :attr:`__globals__`, :attr:`~definition.__name__`, respectively. * :meth:`__nonzero__` is now :meth:`__bool__`. |