Skip to content

Commit da10cad

Browse files
cschan1828cschan1828
committed
Deploying to gh-pages from @ cbb7556 🚀
1 parent b52c2f3 commit da10cad

File tree

549 files changed

+1088
-996
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

549 files changed

+1088
-996
lines changed

‎.buildinfo

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
11
# Sphinx build info version 1
22
# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
3-
config: 0bf4451ad335a0431d7cee9d6c8c3292
3+
config: 692ac3a71785e62ce08a2c56829dad4c
44
tags: 645f666f9bcd5a90fca523b33c5a78b7

‎_images/kde_example.png

-16.7 KB
Loading

‎_sources/faq/design.rst.txt

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -451,7 +451,7 @@ on the key and a per-process seed; for example, ``'Python'`` could hash to
451451
to ``1142331976``. The hash code is then used to calculate a location in an
452452
internal array where the value will be stored. Assuming that you're storing
453453
keys that all have different hash values, this means that dictionaries take
454-
constant time -- O(1), in Big-O notation -- to retrieve a key.
454+
constant time -- *O*\ (1), in Big-O notation -- to retrieve a key.
455455

456456

457457
Why must dictionary keys be immutable?

‎_sources/glossary.rst.txt

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -741,7 +741,7 @@ Glossary
741741
list
742742
A built-in Python :term:`sequence`. Despite its name it is more akin
743743
to an array in other languages than to a linked list since access to
744-
elements is O(1).
744+
elements is *O*\ (1).
745745

746746
list comprehension
747747
A compact way to process all or part of the elements in a sequence and

‎_sources/howto/descriptor.rst.txt

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1240,7 +1240,7 @@ instance::
12401240
<function D.f at 0x00C45070>
12411241

12421242
>>> d.f.__self__
1243-
<__main__.D object at 0x1012e1f98>
1243+
<__main__.D object at 0x00B18C90>
12441244

12451245
If you have ever wondered where *self* comes from in regular methods or where
12461246
*cls* comes from in class methods, this is it!

‎_sources/library/asyncio-policy.rst.txt

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -237,7 +237,7 @@ implementation used by the asyncio event loop:
237237

238238
It works reliably even when the asyncio event loop is run in a non-main OS thread.
239239

240-
There is no noticeable overhead when handling a big number of children (*O(1)* each
240+
There is no noticeable overhead when handling a big number of children (*O*\ (1) each
241241
time a child terminates), but starting a thread per process requires extra memory.
242242

243243
This watcher is used by default.
@@ -257,7 +257,7 @@ implementation used by the asyncio event loop:
257257
watcher is installed.
258258

259259
The solution is safe but it has a significant overhead when
260-
handling a big number of processes (*O(n)* each time a
260+
handling a big number of processes (*O*\ (*n*) each time a
261261
:py:data:`SIGCHLD` is received).
262262

263263
.. versionadded:: 3.8
@@ -273,7 +273,7 @@ implementation used by the asyncio event loop:
273273
The watcher avoids disrupting other code spawning processes
274274
by polling every process explicitly on a :py:data:`SIGCHLD` signal.
275275

276-
This solution is as safe as :class:`MultiLoopChildWatcher` and has the same *O(N)*
276+
This solution is as safe as :class:`MultiLoopChildWatcher` and has the same *O*\ (*n*)
277277
complexity but requires a running event loop in the main thread to work.
278278

279279
.. deprecated:: 3.12
@@ -285,7 +285,7 @@ implementation used by the asyncio event loop:
285285
processes and waiting for their termination.
286286

287287
There is no noticeable overhead when handling a big number of
288-
children (*O(1)* each time a child terminates).
288+
children (*O*\ (1) each time a child terminates).
289289

290290
This solution requires a running event loop in the main thread to work, as
291291
:class:`SafeChildWatcher`.

‎_sources/library/bisect.rst.txt

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -79,7 +79,7 @@ The following functions are provided:
7979
To support inserting records in a table, the *key* function (if any) is
8080
applied to *x* for the search step but not for the insertion step.
8181

82-
Keep in mind that the ``O(log n)`` search is dominated by the slow O(n)
82+
Keep in mind that the *O*\ (log *n*) search is dominated by the slow *O*\ (*n*)
8383
insertion step.
8484

8585
.. versionchanged:: 3.10
@@ -99,7 +99,7 @@ The following functions are provided:
9999
To support inserting records in a table, the *key* function (if any) is
100100
applied to *x* for the search step but not for the insertion step.
101101

102-
Keep in mind that the ``O(log n)`` search is dominated by the slow O(n)
102+
Keep in mind that the *O*\ (log *n*) search is dominated by the slow *O*\ (*n*)
103103
insertion step.
104104

105105
.. versionchanged:: 3.10
@@ -115,7 +115,7 @@ thoughts in mind:
115115
* Bisection is effective for searching ranges of values.
116116
For locating specific values, dictionaries are more performant.
117117

118-
* The *insort()* functions are ``O(n)`` because the logarithmic search step
118+
* The *insort()* functions are *O*\ (*n*) because the logarithmic search step
119119
is dominated by the linear time insertion step.
120120

121121
* The search functions are stateless and discard key function results after

‎_sources/library/collections.rst.txt

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -458,10 +458,10 @@ or subtracting from an empty counter.
458458
Deques are a generalization of stacks and queues (the name is pronounced "deck"
459459
and is short for "double-ended queue"). Deques support thread-safe, memory
460460
efficient appends and pops from either side of the deque with approximately the
461-
same O(1) performance in either direction.
461+
same *O*\ (1) performance in either direction.
462462

463463
Though :class:`list` objects support similar operations, they are optimized for
464-
fast fixed-length operations and incur O(n) memory movement costs for
464+
fast fixed-length operations and incur *O*\ (*n*) memory movement costs for
465465
``pop(0)`` and ``insert(0, v)`` operations which change both the size and
466466
position of the underlying data representation.
467467

@@ -585,7 +585,7 @@ or subtracting from an empty counter.
585585
In addition to the above, deques support iteration, pickling, ``len(d)``,
586586
``reversed(d)``, ``copy.copy(d)``, ``copy.deepcopy(d)``, membership testing with
587587
the :keyword:`in` operator, and subscript references such as ``d[0]`` to access
588-
the first element. Indexed access is O(1) at both ends but slows to O(n) in
588+
the first element. Indexed access is *O*\ (1) at both ends but slows to *O*\ (*n*) in
589589
the middle. For fast random access, use lists instead.
590590

591591
Starting in version 3.5, deques support ``__add__()``, ``__mul__()``,

‎_sources/library/contextvars.rst.txt

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -131,7 +131,7 @@ Manual Context Management
131131
ctx: Context = copy_context()
132132
print(list(ctx.items()))
133133

134-
The function has an O(1) complexity, i.e. works equally fast for
134+
The function has an *O*\ (1) complexity, i.e. works equally fast for
135135
contexts with a few context variables and for contexts that have
136136
a lot of them.
137137

‎_sources/library/heapq.rst.txt

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -270,7 +270,7 @@ winner. The simplest algorithmic way to remove it and find the "next" winner is
270270
to move some loser (let's say cell 30 in the diagram above) into the 0 position,
271271
and then percolate this new 0 down the tree, exchanging values, until the
272272
invariant is re-established. This is clearly logarithmic on the total number of
273-
items in the tree. By iterating over all items, you get an O(n log n) sort.
273+
items in the tree. By iterating over all items, you get an *O*\ (*n* log *n*) sort.
274274

275275
A nice feature of this sort is that you can efficiently insert new items while
276276
the sort is going on, provided that the inserted items are not "better" than the

0 commit comments

Comments
 (0)