summaryrefslogtreecommitdiffstats
path: root/Doc/whatsnew
diff options
context:
space:
mode:
Diffstat (limited to 'Doc/whatsnew')
-rw-r--r--Doc/whatsnew/2.0.rst2
-rw-r--r--Doc/whatsnew/2.1.rst4
-rw-r--r--Doc/whatsnew/2.2.rst14
-rw-r--r--Doc/whatsnew/2.3.rst8
-rw-r--r--Doc/whatsnew/3.0.rst4
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__`.