Removed spaces before colons and semicolons.
This commit is contained in:
commit
89e84e7523
|
@ -247,7 +247,7 @@ Embedding the Python interpreter in a Windows app can be summarized as follows:
|
|||
...
|
||||
Py_Initialize(); // Initialize Python.
|
||||
initmyAppc(); // Initialize (import) the helper class.
|
||||
PyRun_SimpleString("import myApp") ; // Import the shadow class.
|
||||
PyRun_SimpleString("import myApp"); // Import the shadow class.
|
||||
|
||||
5. There are two problems with Python's C API which will become apparent if you
|
||||
use a compiler other than MSVC, the compiler used to build pythonNN.dll.
|
||||
|
|
|
@ -839,7 +839,7 @@ separate thread::
|
|||
},
|
||||
'loggers': {
|
||||
'foo': {
|
||||
'handlers' : ['foofile']
|
||||
'handlers': ['foofile']
|
||||
}
|
||||
},
|
||||
'root': {
|
||||
|
@ -1527,7 +1527,7 @@ works::
|
|||
},
|
||||
'loggers': {
|
||||
'foo': {
|
||||
'handlers' : ['foofile']
|
||||
'handlers': ['foofile']
|
||||
}
|
||||
},
|
||||
'root': {
|
||||
|
|
|
@ -454,7 +454,7 @@ Authentication Tutorial
|
|||
|
||||
When authentication is required, the server sends a header (as well as the 401
|
||||
error code) requesting authentication. This specifies the authentication scheme
|
||||
and a 'realm'. The header looks like : ``WWW-Authenticate: SCHEME
|
||||
and a 'realm'. The header looks like: ``WWW-Authenticate: SCHEME
|
||||
realm="REALM"``.
|
||||
|
||||
e.g. ::
|
||||
|
@ -526,7 +526,7 @@ the ``ProxyHandler``, which is part of the normal handler chain when a proxy
|
|||
setting is detected. Normally that's a good thing, but there are occasions
|
||||
when it may not be helpful [#]_. One way to do this is to setup our own
|
||||
``ProxyHandler``, with no proxies defined. This is done using similar steps to
|
||||
setting up a `Basic Authentication`_ handler : ::
|
||||
setting up a `Basic Authentication`_ handler: ::
|
||||
|
||||
>>> proxy_support = urllib.request.ProxyHandler({})
|
||||
>>> opener = urllib.request.build_opener(proxy_support)
|
||||
|
|
|
@ -193,7 +193,7 @@ updates keys found deeper in the chain::
|
|||
return
|
||||
raise KeyError(key)
|
||||
|
||||
>>> d = DeepChainMap({'zebra': 'black'}, {'elephant' : 'blue'}, {'lion' : 'yellow'})
|
||||
>>> d = DeepChainMap({'zebra': 'black'}, {'elephant': 'blue'}, {'lion': 'yellow'})
|
||||
>>> d['lion'] = 'orange' # update an existing key two levels down
|
||||
>>> d['snake'] = 'red' # new keys get added to the topmost dict
|
||||
>>> del d['elephant'] # remove an existing key one level down
|
||||
|
|
|
@ -218,7 +218,7 @@ more about :mod:`ctypes` data types.
|
|||
Fundamental data types
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
:mod:`ctypes` defines a number of primitive C compatible data types :
|
||||
:mod:`ctypes` defines a number of primitive C compatible data types:
|
||||
|
||||
+----------------------+------------------------------------------+----------------------------+
|
||||
| ctypes type | C type | Python type |
|
||||
|
|
|
@ -205,7 +205,7 @@ Telnet Objects
|
|||
.. method:: Telnet.set_option_negotiation_callback(callback)
|
||||
|
||||
Each time a telnet option is read on the input flow, this *callback* (if set) is
|
||||
called with the following parameters : callback(telnet socket, command
|
||||
called with the following parameters: callback(telnet socket, command
|
||||
(DO/DONT/WILL/WONT), option). No other action is done afterwards by telnetlib.
|
||||
|
||||
|
||||
|
|
|
@ -440,7 +440,7 @@ back will contain the name of the synonym and the "real" option (such as
|
|||
Example::
|
||||
|
||||
>>> print(fred.config())
|
||||
{'relief' : ('relief', 'relief', 'Relief', 'raised', 'groove')}
|
||||
{'relief': ('relief', 'relief', 'Relief', 'raised', 'groove')}
|
||||
|
||||
Of course, the dictionary printed will include all the options available and
|
||||
their values. This is meant only as an example.
|
||||
|
|
|
@ -1652,17 +1652,17 @@ Methods and their defaults:
|
|||
* ``__gt__``: NotImplemented
|
||||
* ``__le__``: NotImplemented
|
||||
* ``__ge__``: NotImplemented
|
||||
* ``__int__`` : 1
|
||||
* ``__contains__`` : False
|
||||
* ``__len__`` : 1
|
||||
* ``__iter__`` : iter([])
|
||||
* ``__exit__`` : False
|
||||
* ``__complex__`` : 1j
|
||||
* ``__float__`` : 1.0
|
||||
* ``__bool__`` : True
|
||||
* ``__index__`` : 1
|
||||
* ``__hash__`` : default hash for the mock
|
||||
* ``__str__`` : default str for the mock
|
||||
* ``__int__``: 1
|
||||
* ``__contains__``: False
|
||||
* ``__len__``: 1
|
||||
* ``__iter__``: iter([])
|
||||
* ``__exit__``: False
|
||||
* ``__complex__``: 1j
|
||||
* ``__float__``: 1.0
|
||||
* ``__bool__``: True
|
||||
* ``__index__``: 1
|
||||
* ``__hash__``: default hash for the mock
|
||||
* ``__str__``: default str for the mock
|
||||
* ``__sizeof__``: default sizeof for the mock
|
||||
|
||||
For example:
|
||||
|
|
|
@ -846,7 +846,7 @@ Here are all of the changes that Python 2.4 makes to the core Python language.
|
|||
['A', 'b', 'c', 'D']
|
||||
|
||||
Finally, the *reverse* parameter takes a Boolean value. If the value is true,
|
||||
the list will be sorted into reverse order. Instead of ``L.sort() ;
|
||||
the list will be sorted into reverse order. Instead of ``L.sort();
|
||||
L.reverse()``, you can now write ``L.sort(reverse=True)``.
|
||||
|
||||
The results of sorting are now guaranteed to be stable. This means that two
|
||||
|
|
|
@ -286,7 +286,7 @@ Python's standard :mod:`string` module? There's no clean way to ignore
|
|||
:mod:`pkg.string` and look for the standard module; generally you had to look at
|
||||
the contents of ``sys.modules``, which is slightly unclean. Holger Krekel's
|
||||
:mod:`py.std` package provides a tidier way to perform imports from the standard
|
||||
library, ``import py ; py.std.string.join()``, but that package isn't available
|
||||
library, ``import py; py.std.string.join()``, but that package isn't available
|
||||
on all Python installations.
|
||||
|
||||
Reading code which relies on relative imports is also less clear, because a
|
||||
|
|
|
@ -1891,7 +1891,7 @@ changes, or look through the Subversion logs for all the details.
|
|||
>>> dq=deque(maxlen=3)
|
||||
>>> dq
|
||||
deque([], maxlen=3)
|
||||
>>> dq.append(1) ; dq.append(2) ; dq.append(3)
|
||||
>>> dq.append(1); dq.append(2); dq.append(3)
|
||||
>>> dq
|
||||
deque([1, 2, 3], maxlen=3)
|
||||
>>> dq.append(4)
|
||||
|
@ -2783,12 +2783,12 @@ http://www.json.org.
|
|||
types. The following example encodes and decodes a dictionary::
|
||||
|
||||
>>> import json
|
||||
>>> data = {"spam" : "foo", "parrot" : 42}
|
||||
>>> data = {"spam": "foo", "parrot": 42}
|
||||
>>> in_json = json.dumps(data) # Encode the data
|
||||
>>> in_json
|
||||
'{"parrot": 42, "spam": "foo"}'
|
||||
>>> json.loads(in_json) # Decode into a Python object
|
||||
{"spam" : "foo", "parrot" : 42}
|
||||
{"spam": "foo", "parrot": 42}
|
||||
|
||||
It's also possible to write your own decoders and encoders to support
|
||||
more types. Pretty-printing of the JSON strings is also supported.
|
||||
|
|
|
@ -1823,12 +1823,12 @@ signal
|
|||
* The :mod:`signal` module has new functions:
|
||||
|
||||
* :func:`~signal.pthread_sigmask`: fetch and/or change the signal mask of the
|
||||
calling thread (Contributed by Jean-Paul Calderone in :issue:`8407`) ;
|
||||
* :func:`~signal.pthread_kill`: send a signal to a thread ;
|
||||
* :func:`~signal.sigpending`: examine pending functions ;
|
||||
* :func:`~signal.sigwait`: wait a signal.
|
||||
calling thread (Contributed by Jean-Paul Calderone in :issue:`8407`);
|
||||
* :func:`~signal.pthread_kill`: send a signal to a thread;
|
||||
* :func:`~signal.sigpending`: examine pending functions;
|
||||
* :func:`~signal.sigwait`: wait a signal;
|
||||
* :func:`~signal.sigwaitinfo`: wait for a signal, returning detailed
|
||||
information about it.
|
||||
information about it;
|
||||
* :func:`~signal.sigtimedwait`: like :func:`~signal.sigwaitinfo` but with a
|
||||
timeout.
|
||||
|
||||
|
|
Loading…
Reference in New Issue