mirror of
https://github.com/python/cpython.git
synced 2025-09-27 18:59:43 +00:00
Minor wording changes, plus correct a typo.
This commit is contained in:
parent
30d59baecd
commit
9aa97e835d
1 changed files with 7 additions and 7 deletions
|
@ -20,9 +20,9 @@ object - it just contains the refcount and a pointer to the object's
|
||||||
``type object''. This is where the action is; the type object
|
``type object''. This is where the action is; the type object
|
||||||
determines which (C) functions get called when, for instance, an
|
determines which (C) functions get called when, for instance, an
|
||||||
attribute gets looked up on an object or it is multiplied by another
|
attribute gets looked up on an object or it is multiplied by another
|
||||||
object. I call these C functions ``type methods'' to distinguish them
|
object. These C functions are called ``type methods'' to distinguish
|
||||||
from things like \code{[].append} (which I will call ``object
|
them from things like \code{[].append} (which we call ``object
|
||||||
methods'' when I get around to them).
|
methods'').
|
||||||
|
|
||||||
So, if you want to define a new object type, you need to create a new
|
So, if you want to define a new object type, you need to create a new
|
||||||
type object.
|
type object.
|
||||||
|
@ -184,7 +184,7 @@ definition above. The remaining fields will be filled with zeros by
|
||||||
the C compiler, and it's common practice to not specify them
|
the C compiler, and it's common practice to not specify them
|
||||||
explicitly unless you need them.
|
explicitly unless you need them.
|
||||||
|
|
||||||
This is so important that I'm going to pick the top of it apart still
|
This is so important that we're going to pick the top of it apart still
|
||||||
further:
|
further:
|
||||||
|
|
||||||
\begin{verbatim}
|
\begin{verbatim}
|
||||||
|
@ -237,7 +237,7 @@ This is so that Python knows how much memory to allocate when you call
|
||||||
\end{verbatim}
|
\end{verbatim}
|
||||||
|
|
||||||
This has to do with variable length objects like lists and strings.
|
This has to do with variable length objects like lists and strings.
|
||||||
Ignore for now...
|
Ignore this for now.
|
||||||
|
|
||||||
Now we get into the type methods, the things that make your objects
|
Now we get into the type methods, the things that make your objects
|
||||||
different from the others. Of course, the Noddy object doesn't
|
different from the others. Of course, the Noddy object doesn't
|
||||||
|
@ -248,7 +248,7 @@ the deallocation function.
|
||||||
noddy_noddy_dealloc, /* tp_dealloc */
|
noddy_noddy_dealloc, /* tp_dealloc */
|
||||||
\end{verbatim}
|
\end{verbatim}
|
||||||
|
|
||||||
From here, all the type methods are \NULL, so I won't go over them yet
|
From here, all the type methods are \NULL, so we'll go over them later
|
||||||
--- that's for the next section!
|
--- that's for the next section!
|
||||||
|
|
||||||
Everything else in the file should be familiar, except for this line
|
Everything else in the file should be familiar, except for this line
|
||||||
|
@ -452,7 +452,7 @@ The \member{tp_str} handler is to \function{str()} what the
|
||||||
is, it is called when Python code calls \function{str()} on an
|
is, it is called when Python code calls \function{str()} on an
|
||||||
instance of your object. It's implementation is very similar to the
|
instance of your object. It's implementation is very similar to the
|
||||||
\member{tp_repr} function, but the resulting string is intended for
|
\member{tp_repr} function, but the resulting string is intended for
|
||||||
human consumption. It \member{tp_str} is not specified, the
|
human consumption. If \member{tp_str} is not specified, the
|
||||||
\member{tp_repr} handler is used instead.
|
\member{tp_repr} handler is used instead.
|
||||||
|
|
||||||
Here is a simple example:
|
Here is a simple example:
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue