Merged revisions 75393,75416,75581,75609,75615 via svnmerge from
svn+ssh://svn.python.org/python/branches/py3k ................ r75393 | georg.brandl | 2009-10-13 18:55:12 +0200 (Di, 13 Okt 2009) | 1 line Update module names in references in the FAQ. ................ r75416 | georg.brandl | 2009-10-14 20:46:15 +0200 (Mi, 14 Okt 2009) | 1 line #7129: add missing function. ................ r75581 | georg.brandl | 2009-10-21 09:17:48 +0200 (Mi, 21 Okt 2009) | 9 lines Merged revisions 75580 via svnmerge from svn+ssh://pythondev@svn.python.org/python/trunk ........ r75580 | georg.brandl | 2009-10-21 09:15:59 +0200 (Mi, 21 Okt 2009) | 1 line #7170: fix explanation about non-weakrefable builtin types. ........ ................ r75609 | georg.brandl | 2009-10-22 17:16:26 +0200 (Do, 22 Okt 2009) | 1 line #7137: fix makefile() documentation to match the new parameters. ................ r75615 | georg.brandl | 2009-10-22 18:08:10 +0200 (Do, 22 Okt 2009) | 1 line #6927: fix wrong word. ................
This commit is contained in:
parent
cb7cb247b3
commit
1e8cbe36cc
|
@ -232,11 +232,9 @@ Threads
|
||||||
How do I program using threads?
|
How do I program using threads?
|
||||||
-------------------------------
|
-------------------------------
|
||||||
|
|
||||||
.. XXX it's _thread in py3k
|
Be sure to use the :mod:`threading` module and not the :mod:`_thread` module.
|
||||||
|
|
||||||
Be sure to use the :mod:`threading` module and not the :mod:`thread` module.
|
|
||||||
The :mod:`threading` module builds convenient abstractions on top of the
|
The :mod:`threading` module builds convenient abstractions on top of the
|
||||||
low-level primitives provided by the :mod:`thread` module.
|
low-level primitives provided by the :mod:`_thread` module.
|
||||||
|
|
||||||
Aahz has a set of slides from his threading tutorial that are helpful; see
|
Aahz has a set of slides from his threading tutorial that are helpful; see
|
||||||
http://starship.python.net/crew/aahz/OSCON2001/.
|
http://starship.python.net/crew/aahz/OSCON2001/.
|
||||||
|
@ -280,7 +278,7 @@ A simple fix is to add a tiny sleep to the start of the run function::
|
||||||
|
|
||||||
Instead of trying to guess how long a :func:`time.sleep` delay will be enough,
|
Instead of trying to guess how long a :func:`time.sleep` delay will be enough,
|
||||||
it's better to use some kind of semaphore mechanism. One idea is to use the
|
it's better to use some kind of semaphore mechanism. One idea is to use the
|
||||||
:mod:`Queue` module to create a queue object, let each thread append a token to
|
:mod:`queue` module to create a queue object, let each thread append a token to
|
||||||
the queue when it finishes, and let the main thread read as many tokens from the
|
the queue when it finishes, and let the main thread read as many tokens from the
|
||||||
queue as there are threads.
|
queue as there are threads.
|
||||||
|
|
||||||
|
@ -288,8 +286,8 @@ queue as there are threads.
|
||||||
How do I parcel out work among a bunch of worker threads?
|
How do I parcel out work among a bunch of worker threads?
|
||||||
---------------------------------------------------------
|
---------------------------------------------------------
|
||||||
|
|
||||||
Use the :mod:`Queue` module to create a queue containing a list of jobs. The
|
Use the :mod:`queue` module to create a queue containing a list of jobs. The
|
||||||
:class:`~Queue.Queue` class maintains a list of objects with ``.put(obj)`` to
|
:class:`~queue.Queue` class maintains a list of objects with ``.put(obj)`` to
|
||||||
add an item to the queue and ``.get()`` to return an item. The class will take
|
add an item to the queue and ``.get()`` to return an item. The class will take
|
||||||
care of the locking necessary to ensure that each job is handed out exactly
|
care of the locking necessary to ensure that each job is handed out exactly
|
||||||
once.
|
once.
|
||||||
|
@ -777,11 +775,10 @@ Are there any interfaces to database packages in Python?
|
||||||
|
|
||||||
Yes.
|
Yes.
|
||||||
|
|
||||||
.. XXX remove bsddb in py3k, fix other module names
|
Interfaces to disk-based hashes such as :mod:`DBM <dbm.ndbm>` and :mod:`GDBM
|
||||||
|
<dbm.gnu>` are also included with standard Python. There is also the
|
||||||
Python 2.3 includes the :mod:`bsddb` package which provides an interface to the
|
:mod:`sqlite3` module, which provides a lightweight disk-based relational
|
||||||
BerkeleyDB library. Interfaces to disk-based hashes such as :mod:`DBM <dbm>`
|
database.
|
||||||
and :mod:`GDBM <gdbm>` are also included with standard Python.
|
|
||||||
|
|
||||||
Support for most relational databases is available. See the
|
Support for most relational databases is available. See the
|
||||||
`DatabaseProgramming wiki page
|
`DatabaseProgramming wiki page
|
||||||
|
@ -794,8 +791,7 @@ How do you implement persistent objects in Python?
|
||||||
The :mod:`pickle` library module solves this in a very general way (though you
|
The :mod:`pickle` library module solves this in a very general way (though you
|
||||||
still can't store things like open files, sockets or windows), and the
|
still can't store things like open files, sockets or windows), and the
|
||||||
:mod:`shelve` library module uses pickle and (g)dbm to create persistent
|
:mod:`shelve` library module uses pickle and (g)dbm to create persistent
|
||||||
mappings containing arbitrary Python objects. For better performance, you can
|
mappings containing arbitrary Python objects.
|
||||||
use the :mod:`cPickle` module.
|
|
||||||
|
|
||||||
A more awkward way of doing things is to use pickle's little sister, marshal.
|
A more awkward way of doing things is to use pickle's little sister, marshal.
|
||||||
The :mod:`marshal` module provides very fast ways to store noncircular basic
|
The :mod:`marshal` module provides very fast ways to store noncircular basic
|
||||||
|
|
|
@ -364,7 +364,7 @@ What are the "best practices" for using import in a module?
|
||||||
In general, don't use ``from modulename import *``. Doing so clutters the
|
In general, don't use ``from modulename import *``. Doing so clutters the
|
||||||
importer's namespace. Some people avoid this idiom even with the few modules
|
importer's namespace. Some people avoid this idiom even with the few modules
|
||||||
that were designed to be imported in this manner. Modules designed in this
|
that were designed to be imported in this manner. Modules designed in this
|
||||||
manner include :mod:`Tkinter`, and :mod:`threading`.
|
manner include :mod:`tkinter`, and :mod:`threading`.
|
||||||
|
|
||||||
Import modules at the top of a file. Doing so makes it clear what other modules
|
Import modules at the top of a file. Doing so makes it clear what other modules
|
||||||
your code requires and avoids questions of whether the module name is in scope.
|
your code requires and avoids questions of whether the module name is in scope.
|
||||||
|
|
|
@ -565,17 +565,17 @@ correspond to Unix system calls applicable to sockets.
|
||||||
is system-dependent (usually 5).
|
is system-dependent (usually 5).
|
||||||
|
|
||||||
|
|
||||||
.. method:: socket.makefile([mode[, bufsize]])
|
.. method:: socket.makefile(mode='r', buffering=None, *, encoding=None, newline=None)
|
||||||
|
|
||||||
.. index:: single: I/O control; buffering
|
.. index:: single: I/O control; buffering
|
||||||
|
|
||||||
Return a :dfn:`file object` associated with the socket. (File objects are
|
Return a :dfn:`file object` associated with the socket. (File objects are
|
||||||
described in :ref:`bltin-file-objects`.) The file object
|
described in :ref:`bltin-file-objects`.) The file object references a
|
||||||
references a :cfunc:`dup`\ ped version of the socket file descriptor, so the
|
:cfunc:`dup`\ ped version of the socket file descriptor, so the file object
|
||||||
file object and socket object may be closed or garbage-collected independently.
|
and socket object may be closed or garbage-collected independently. The
|
||||||
The socket must be in blocking mode (it can not have a timeout). The optional
|
socket must be in blocking mode (it can not have a timeout). The optional
|
||||||
*mode* and *bufsize* arguments are interpreted the same way as by the built-in
|
arguments are interpreted the same way as by the built-in :func:`open`
|
||||||
:func:`file` function.
|
function.
|
||||||
|
|
||||||
|
|
||||||
.. method:: socket.recv(bufsize[, flags])
|
.. method:: socket.recv(bufsize[, flags])
|
||||||
|
|
|
@ -69,6 +69,10 @@ support weak references but can add support through subclassing::
|
||||||
|
|
||||||
obj = Dict(red=1, green=2, blue=3) # this object is weak referenceable
|
obj = Dict(red=1, green=2, blue=3) # this object is weak referenceable
|
||||||
|
|
||||||
|
Other built-in types such as :class:`tuple` and :class:`int` do not support
|
||||||
|
weak references even when subclassed (those types implemented as a
|
||||||
|
:ctype:`PyVarObject`).
|
||||||
|
|
||||||
Extension types can easily be made to support weak references; see
|
Extension types can easily be made to support weak references; see
|
||||||
:ref:`weakref-support`.
|
:ref:`weakref-support`.
|
||||||
|
|
||||||
|
|
|
@ -608,9 +608,9 @@ which is then bound to the class name.
|
||||||
.. [#] The exception is propagated to the invocation stack only if there is no
|
.. [#] The exception is propagated to the invocation stack only if there is no
|
||||||
:keyword:`finally` clause that negates the exception.
|
:keyword:`finally` clause that negates the exception.
|
||||||
|
|
||||||
.. [#] Currently, control "flows off the end" except in the case of an exception or the
|
.. [#] Currently, control "flows off the end" except in the case of an exception
|
||||||
execution of a :keyword:`return`, :keyword:`continue`, or :keyword:`break`
|
or the execution of a :keyword:`return`, :keyword:`continue`, or
|
||||||
statement.
|
:keyword:`break` statement.
|
||||||
|
|
||||||
.. [#] A string literal appearing as the first statement in the function body is
|
.. [#] A string literal appearing as the first statement in the function body is
|
||||||
transformed into the function's ``__doc__`` attribute and therefore the
|
transformed into the function's ``__doc__`` attribute and therefore the
|
||||||
|
|
|
@ -1532,7 +1532,7 @@ returning an ordered dictionary.
|
||||||
|
|
||||||
The appropriate metaclass is determined by the following precedence rules:
|
The appropriate metaclass is determined by the following precedence rules:
|
||||||
|
|
||||||
* If the ``metaclass`` keyword argument is based with the bases, it is used.
|
* If the ``metaclass`` keyword argument is passed with the bases, it is used.
|
||||||
|
|
||||||
* Otherwise, if there is at least one base class, its metaclass is used.
|
* Otherwise, if there is at least one base class, its metaclass is used.
|
||||||
|
|
||||||
|
|
|
@ -126,7 +126,7 @@ _tg_screen_functions = ['addshape', 'bgcolor', 'bgpic', 'bye',
|
||||||
_tg_turtle_functions = ['back', 'backward', 'begin_fill', 'begin_poly', 'bk',
|
_tg_turtle_functions = ['back', 'backward', 'begin_fill', 'begin_poly', 'bk',
|
||||||
'circle', 'clear', 'clearstamp', 'clearstamps', 'clone', 'color',
|
'circle', 'clear', 'clearstamp', 'clearstamps', 'clone', 'color',
|
||||||
'degrees', 'distance', 'dot', 'down', 'end_fill', 'end_poly', 'fd',
|
'degrees', 'distance', 'dot', 'down', 'end_fill', 'end_poly', 'fd',
|
||||||
'fillcolor', 'forward', 'get_poly', 'getpen', 'getscreen', 'get_shapepoly',
|
'fillcolor', 'filling', 'forward', 'get_poly', 'getpen', 'getscreen', 'get_shapepoly',
|
||||||
'getturtle', 'goto', 'heading', 'hideturtle', 'home', 'ht', 'isdown',
|
'getturtle', 'goto', 'heading', 'hideturtle', 'home', 'ht', 'isdown',
|
||||||
'isvisible', 'left', 'lt', 'onclick', 'ondrag', 'onrelease', 'pd',
|
'isvisible', 'left', 'lt', 'onclick', 'ondrag', 'onrelease', 'pd',
|
||||||
'pen', 'pencolor', 'pendown', 'pensize', 'penup', 'pos', 'position',
|
'pen', 'pencolor', 'pendown', 'pensize', 'penup', 'pos', 'position',
|
||||||
|
|
Loading…
Reference in New Issue