Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit6b0975b

Browse files
committed
Deploying to gh-pages from @1a480de 🚀
1 parent7ad9d31 commit6b0975b

File tree

610 files changed

+10865
-9383
lines changed

Some content is hidden

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

610 files changed

+10865
-9383
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 records the configuration used when building these files. When it is not found, a full rebuild will be done.
3-
config:d0f7e7491a617318ea66f31d3f61c0ee
3+
config:f9142bea56443272670326d4d54066fd
44
tags: 645f666f9bcd5a90fca523b33c5a78b7

‎_sources/c-api/allocation.rst.txt

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -35,6 +35,10 @@ Allocating Objects on the Heap
3535
The size of the memory allocation is determined from the
3636
:c:member:`~PyTypeObject.tp_basicsize` field of the type object.
3737
38+
Note that this function is unsuitable if *typeobj* has
39+
:c:macro:`Py_TPFLAGS_HAVE_GC` set. For such objects,
40+
use :c:func:`PyObject_GC_New` instead.
41+
3842
3943
.. c:macro:: PyObject_NewVar(TYPE, typeobj, size)
4044
@@ -49,6 +53,10 @@ Allocating Objects on the Heap
4953
fields into the same allocation decreases the number of allocations,
5054
improving the memory management efficiency.
5155
56+
Note that this function is unsuitable if *typeobj* has
57+
:c:macro:`Py_TPFLAGS_HAVE_GC` set. For such objects,
58+
use :c:func:`PyObject_GC_NewVar` instead.
59+
5260
5361
.. c:function:: void PyObject_Del(void *op)
5462

‎_sources/c-api/gcsupport.rst.txt

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -277,7 +277,7 @@ the garbage collector.
277277
278278
Type of the visitor function to be passed to:c:func:`PyUnstable_GC_VisitObjects`.
279279
*arg* is the same as the *arg* passed to ``PyUnstable_GC_VisitObjects``.
280-
Return ``0`` to continue iteration, return ``1`` to stop iteration. Other return
280+
Return ``1`` to continue iteration, return ``0`` to stop iteration. Other return
281281
values are reserved for now so behavior on returning anything else is undefined.
282282
283283
..versionadded::3.12

‎_sources/c-api/monitoring.rst.txt

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -190,3 +190,15 @@ would typically correspond to a python function.
190190
.. c:function:: int PyMonitoring_ExitScope(void)
191191
192192
Exit the last scope that was entered with :c:func:`!PyMonitoring_EnterScope`.
193+
194+
195+
.. c:function:: int PY_MONITORING_IS_INSTRUMENTED_EVENT(uint8_t ev)
196+
197+
Return true if the event corresponding to the event ID *ev* is
198+
a :ref:`local event <monitoring-event-local>`.
199+
200+
.. versionadded:: 3.13
201+
202+
.. deprecated:: 3.13.3
203+
204+
This function is :term:`soft deprecated`.

‎_sources/c-api/type.rst.txt

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -82,6 +82,9 @@ Type Objects
8282
error (e.g. no more watcher IDs available), return ``-1`` and set an
8383
exception.
8484
85+
In free-threaded builds, :c:func:`PyType_AddWatcher` is not thread-safe,
86+
so it must be called at start up (before spawning the first thread).
87+
8588
.. versionadded:: 3.12
8689
8790
@@ -412,6 +415,9 @@ The following functions and structs are used to create
412415
class need *in addition* to the superclass.
413416
Use:c:func:`PyObject_GetTypeData` to get a pointer to subclass-specific
414417
memory reserved this way.
418+
For negative:c:member:`!basicsize`, Python will insert padding when
419+
needed to meet:c:member:`~PyTypeObject.tp_basicsize`'s alignment
420+
requirements.
415421
416422
..versionchanged::3.12
417423

‎_sources/c-api/typeobj.rst.txt

Lines changed: 75 additions & 35 deletions
Original file line numberDiff line numberDiff line change
@@ -473,7 +473,7 @@ PyTypeObject Definition
473473
-----------------------
474474

475475
The structure definition for:c:type:`PyTypeObject` can be found in
476-
:file:`Include/object.h`. For convenience of reference, this repeats the
476+
:file:`Include/cpython/object.h`. For convenience of reference, this repeats the
477477
definition found there:
478478

479479
.. XXX Drop this?
@@ -537,6 +537,9 @@ PyVarObject Slots
537537
initialized to zero. For:ref:`dynamically allocated type objects
538538
<heap-types>`, this field has a special internal meaning.
539539

540+
This field should be accessed using the:c:func:`Py_SIZE()` and
541+
:c:func:`Py_SET_SIZE()` macros.
542+
540543
**Inheritance:**
541544

542545
This field is not inherited by subtypes.
@@ -587,47 +590,86 @@ and :c:data:`PyType_Type` effectively act as defaults.)
587590

588591

589592
..c:member:: Py_ssize_t PyTypeObject.tp_basicsize
590-
Py_ssize_t PyTypeObject.tp_itemsize
593+
Py_ssize_t PyTypeObject.tp_itemsize
591594
592595
These fields allow calculating the size in bytes of instances of the type.
593596

594597
There are two kinds of types: types with fixed-length instances have a zero
595-
:c:member:`~PyTypeObject.tp_itemsize` field, types with variable-length instances have a non-zero
596-
:c:member:`~PyTypeObject.tp_itemsize` field. For a type with fixed-length instances, all
597-
instances have the same size, given in:c:member:`~PyTypeObject.tp_basicsize`.
598+
:c:member:`!tp_itemsize` field, types with variable-length instances have a non-zero
599+
:c:member:`!tp_itemsize` field. For a type with fixed-length instances, all
600+
instances have the same size, given in:c:member:`!tp_basicsize`.
601+
(Exceptions to this rule can be made using
602+
:c:func:`PyUnstable_Object_GC_NewWithExtraData`.)
598603

599604
For a type with variable-length instances, the instances must have an
600-
:c:member:`~PyVarObject.ob_size` field, and the instance size is:c:member:`~PyTypeObject.tp_basicsize` plus N
601-
times:c:member:`~PyTypeObject.tp_itemsize`, where N is the "length" of the object. The value of
602-
N is typically stored in the instance's:c:member:`~PyVarObject.ob_size` field. There are
603-
exceptions: for example, ints use a negative:c:member:`~PyVarObject.ob_size` to indicate a
604-
negative number, and N is ``abs(ob_size)`` there. Also, the presence of an
605-
:c:member:`~PyVarObject.ob_size` field in the instance layout doesn't mean that the instance
606-
structure is variable-length (for example, the structure for the list type has
607-
fixed-length instances, yet those instances have a meaningful:c:member:`~PyVarObject.ob_size`
608-
field).
609-
610-
The basic size includes the fields in the instance declared by the macro
611-
:c:macro:`PyObject_HEAD` or:c:macro:`PyObject_VAR_HEAD` (whichever is used to
612-
declare the instance struct) and this in turn includes the:c:member:`~PyObject._ob_prev` and
613-
:c:member:`~PyObject._ob_next` fields if they are present. This means that the only correct
614-
way to get an initializer for the:c:member:`~PyTypeObject.tp_basicsize` is to use the
615-
``sizeof`` operator on the struct used to declare the instance layout.
616-
The basic size does not include the GC header size.
605+
:c:member:`~PyVarObject.ob_size` field, and the instance size is
606+
:c:member:`!tp_basicsize` plus N times:c:member:`!tp_itemsize`,
607+
where N is the "length" of the object.
608+
609+
Functions like:c:func:`PyObject_NewVar` will take the value of N as an
610+
argument, and store in the instance's:c:member:`~PyVarObject.ob_size` field.
611+
Note that the:c:member:`~PyVarObject.ob_size` field may later be used for
612+
other purposes. For example,:py:type:`int` instances use the bits of
613+
:c:member:`~PyVarObject.ob_size` in an implementation-defined
614+
way; the underlying storage and its size should be accessed using
615+
:c:func:`PyLong_Export`.
616+
617+
..note::
618+
619+
The:c:member:`~PyVarObject.ob_size` field should be accessed using
620+
the:c:func:`Py_SIZE()` and:c:func:`Py_SET_SIZE()` macros.
617621

618-
A note about alignment: ifthevariable items require a particular alignment,
619-
this should be taken care of bythevalue of:c:member:`~PyTypeObject.tp_basicsize`. Example:
620-
suppose a type implements an array of ``double``.:c:member:`~PyTypeObject.tp_itemsize` is
621-
``sizeof(double)``. It is the programmer's responsibility that
622-
:c:member:`~PyTypeObject.tp_basicsize` is a multiple of ``sizeof(double)`` (assuming this is the
623-
alignment requirement for ``double``).
622+
Also,thepresence of an:c:member:`~PyVarObject.ob_size` field in the
623+
instance layout doesn't mean thattheinstance structure is variable-length.
624+
For example, the:py:type:`list` type has fixed-length instances, yet those
625+
instances have a:c:member:`~PyVarObject.ob_size` field.
626+
(As with:py:type:`int`, avoid reading lists':c:member:`!ob_size` directly.
627+
Call:c:func:`PyList_Size` instead.)
624628

625-
For any type with variable-length instances, this field must not be ``NULL``.
629+
The:c:member:`!tp_basicsize` includes size needed for data of the type's
630+
:c:member:`~PyTypeObject.tp_base`, plus any extra data needed
631+
by each instance.
632+
633+
The correct way to set:c:member:`!tp_basicsize` is to use the
634+
``sizeof`` operator on the struct used to declare the instance layout.
635+
This struct must include the struct used to declare the base type.
636+
In other words,:c:member:`!tp_basicsize` must be greater than or equal
637+
to the base's:c:member:`!tp_basicsize`.
638+
639+
Since every type is a subtype of:py:type:`object`, this struct must
640+
include:c:type:`PyObject` or:c:type:`PyVarObject` (depending on
641+
whether:c:member:`~PyVarObject.ob_size` should be included). These are
642+
usually defined by the macro:c:macro:`PyObject_HEAD` or
643+
:c:macro:`PyObject_VAR_HEAD`, respectively.
644+
645+
The basic size does not include the GC header size, as that header is not
646+
part of:c:macro:`PyObject_HEAD`.
647+
648+
For cases where struct used to declare the base type is unknown,
649+
see:c:member:`PyType_Spec.basicsize` and:c:func:`PyType_FromMetaclass`.
650+
651+
Notes about alignment:
652+
653+
-:c:member:`!tp_basicsize` must be a multiple of ``_Alignof(PyObject)``.
654+
When using ``sizeof`` on a ``struct`` that includes
655+
:c:macro:`PyObject_HEAD`, as recommended, the compiler ensures this.
656+
When not using a C ``struct``, or when using compiler
657+
extensions like ``__attribute__((packed))``, it is up to you.
658+
- If the variable items require a particular alignment,
659+
:c:member:`!tp_basicsize` and:c:member:`!tp_itemsize` must each be a
660+
multiple of that alignment.
661+
For example, if a type's variable part stores a ``double``, it is
662+
your responsibility that both fields are a multiple of
663+
``_Alignof(double)``.
626664

627665
**Inheritance:**
628666

629-
These fields are inherited separately by subtypes. If the base type has a
630-
non-zero:c:member:`~PyTypeObject.tp_itemsize`, it is generally not safe to set
667+
These fields are inherited separately by subtypes.
668+
(That is, if the field is set to zero,:c:func:`PyType_Ready` will copy
669+
the value from the base type, indicating that the instances do not
670+
need additional storage.)
671+
672+
If the base type has a non-zero:c:member:`~PyTypeObject.tp_itemsize`, it is generally not safe to set
631673
:c:member:`~PyTypeObject.tp_itemsize` to a different non-zero value in a subtype (though this
632674
depends on the implementation of the base type).
633675

@@ -2111,15 +2153,13 @@ and :c:data:`PyType_Type` effectively act as defaults.)
21112153
static void
21122154
local_finalize(PyObject *self)
21132155
{
2114-
PyObject *error_type, *error_value, *error_traceback;
2115-
21162156
/* Save the current exception, if any. */
2117-
PyErr_Fetch(&error_type, &error_value, &error_traceback);
2157+
PyObject *exc = PyErr_GetRaisedException();
21182158

21192159
/* ... */
21202160

21212161
/* Restore the saved exception. */
2122-
PyErr_Restore(error_type, error_value, error_traceback);
2162+
PyErr_SetRaisedException(exc);
21232163
}
21242164

21252165
**Inheritance:**

‎_sources/c-api/unicode.rst.txt

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -589,6 +589,14 @@ APIs:
589589
Objects other than Unicode or its subtypes will cause a :exc:`TypeError`.
590590
591591
592+
.. c:function:: PyObject* PyUnicode_FromOrdinal(int ordinal)
593+
594+
Create a Unicode Object from the given Unicode code point *ordinal*.
595+
596+
The ordinal must be in ``range(0x110000)``. A :exc:`ValueError` is
597+
raised in the case it is not.
598+
599+
592600
.. c:function:: PyObject* PyUnicode_FromEncodedObject(PyObject *obj, \
593601
const char *encoding, const char *errors)
594602

‎_sources/faq/programming.rst.txt

Lines changed: 12 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -986,8 +986,8 @@ There are various techniques.
986986
f()
987987

988988

989-
Is there an equivalent to Perl's chomp() for removing trailing newlines from strings?
990-
-------------------------------------------------------------------------------------
989+
Is there an equivalent to Perl's``chomp()`` for removing trailing newlines from strings?
990+
-----------------------------------------------------------------------------------------
991991

992992
You can use ``S.rstrip("\r\n")`` to remove all occurrences of any line
993993
terminator from the end of the string ``S`` without removing other trailing
@@ -1005,8 +1005,8 @@ Since this is typically only desired when reading text one line at a time, using
10051005
``S.rstrip()`` this way works well.
10061006

10071007

1008-
Is there a scanf() or sscanf() equivalent?
1009-
------------------------------------------
1008+
Is there a``scanf()`` or``sscanf()`` equivalent?
1009+
--------------------------------------------------
10101010

10111011
Not as such.
10121012

@@ -1020,8 +1020,8 @@ For more complicated input parsing, regular expressions are more powerful
10201020
than C's ``sscanf`` and better suited for the task.
10211021

10221022

1023-
What does'UnicodeDecodeError' or'UnicodeEncodeError' error mean?
1024-
-------------------------------------------------------------------
1023+
What does``UnicodeDecodeError`` or``UnicodeEncodeError`` error mean?
1024+
----------------------------------------------------------------------
10251025

10261026
See the:ref:`unicode-howto`.
10271027

@@ -1036,7 +1036,7 @@ A raw string ending with an odd number of backslashes will escape the string's q
10361036
>>> r'C:\this\will\not\work\'
10371037
File "<stdin>", line 1
10381038
r'C:\this\will\not\work\'
1039-
^
1039+
^
10401040
SyntaxError: unterminated string literal (detected at line 1)
10411041

10421042
There are several workarounds for this. One is to use regular strings and double
@@ -1868,15 +1868,15 @@ object identity is assured. Generally, there are three circumstances where
18681868
identity is guaranteed:
18691869

18701870
1) Assignments create new names but do not change object identity. After the
1871-
assignment ``new = old``, it is guaranteed that ``new is old``.
1871+
assignment ``new = old``, it is guaranteed that ``new is old``.
18721872

18731873
2) Putting an object in a container that stores object references does not
1874-
change object identity. After the list assignment ``s[0] = x``, it is
1875-
guaranteed that ``s[0] is x``.
1874+
change object identity. After the list assignment ``s[0] = x``, it is
1875+
guaranteed that ``s[0] is x``.
18761876

18771877
3) If an object is a singleton, it means that only one instance of that object
1878-
can exist. After the assignments ``a = None`` and ``b = None``, it is
1879-
guaranteed that ``a is b`` because ``None`` is a singleton.
1878+
can exist. After the assignments ``a = None`` and ``b = None``, it is
1879+
guaranteed that ``a is b`` because ``None`` is a singleton.
18801880

18811881
In most other circumstances, identity tests are inadvisable and equality tests
18821882
are preferred. In particular, identity tests should not be used to check

‎_sources/glossary.rst.txt

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -787,6 +787,10 @@ Glossary
787787
thread removes *key* from *mapping* after the test, but before the lookup.
788788
This issue can be solved with locks or by using the EAFP approach.
789789

790+
lexical analyzer
791+
792+
Formal name for the *tokenizer*; see:term:`token`.
793+
790794
list
791795
A built-in Python:term:`sequence`. Despite its name it is more akin
792796
to an array in other languages than to a linked list since access to
@@ -1278,6 +1282,17 @@ Glossary
12781282
See also:term:`binary file` for a file object able to read and write
12791283
:term:`bytes-like objects <bytes-like object>`.
12801284

1285+
token
1286+
1287+
A small unit of source code, generated by the
1288+
:ref:`lexical analyzer<lexical>` (also called the *tokenizer*).
1289+
Names, numbers, strings, operators,
1290+
newlines and similar are represented by tokens.
1291+
1292+
The:mod:`tokenize` module exposes Python's lexical analyzer.
1293+
The:mod:`token` module contains information on the various types
1294+
of tokens.
1295+
12811296
triple-quoted string
12821297
A string which is bound by three instances of either a quotation mark
12831298
(") or an apostrophe ('). While they don't provide any functionality

‎_sources/howto/curses.rst.txt

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -145,8 +145,8 @@ importing the :func:`curses.wrapper` function and using it like this::
145145
v = i-10
146146
stdscr.addstr(i, 0, '10 divided by {} is {}'.format(v, 10/v))
147147

148-
stdscr.refresh()
149-
stdscr.getkey()
148+
stdscr.refresh()
149+
stdscr.getkey()
150150

151151
wrapper(main)
152152

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp