Skip to content

Commit fe2adf0

Browse files
committed
Deploying to gh-pages from @ bbc8024 🚀
1 parent d325dec commit fe2adf0

File tree

550 files changed

+20892
-23429
lines changed

Some content is hidden

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

550 files changed

+20892
-23429
lines changed

_sources/c-api/buffer.rst.txt

Lines changed: 13 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -163,13 +163,6 @@ a buffer, see :c:func:`PyObject_GetBuffer`.
163163
and :c:member:`~Py_buffer.suboffsets` MUST be ``NULL``.
164164
The maximum number of dimensions is given by :c:macro:`PyBUF_MAX_NDIM`.
165165

166-
.. :c:macro:: PyBUF_MAX_NDIM
167-
168-
The maximum number of dimensions the memory represents.
169-
Exporters MUST respect this limit, consumers of multi-dimensional
170-
buffers SHOULD be able to handle up to :c:macro:`!PyBUF_MAX_NDIM` dimensions.
171-
Currently set to 64.
172-
173166
.. c:member:: Py_ssize_t *shape
174167
175168
An array of :c:type:`Py_ssize_t` of length :c:member:`~Py_buffer.ndim`
@@ -221,6 +214,17 @@ a buffer, see :c:func:`PyObject_GetBuffer`.
221214
freed when the buffer is released. The consumer MUST NOT alter this
222215
value.
223216

217+
218+
Constants:
219+
220+
.. c:macro:: PyBUF_MAX_NDIM
221+
222+
The maximum number of dimensions the memory represents.
223+
Exporters MUST respect this limit, consumers of multi-dimensional
224+
buffers SHOULD be able to handle up to :c:macro:`!PyBUF_MAX_NDIM` dimensions.
225+
Currently set to 64.
226+
227+
224228
.. _buffer-request-types:
225229

226230
Buffer request types
@@ -444,7 +448,7 @@ Buffer-related functions
444448
445449
Send a request to *exporter* to fill in *view* as specified by *flags*.
446450
If the exporter cannot provide a buffer of the exact type, it MUST raise
447-
:c:data:`PyExc_BufferError`, set ``view->obj`` to ``NULL`` and
451+
:exc:`BufferError`, set ``view->obj`` to ``NULL`` and
448452
return ``-1``.
449453
450454
On success, fill in *view*, set ``view->obj`` to a new reference
@@ -531,7 +535,7 @@ Buffer-related functions
531535
and :c:macro:`PyBUF_WRITABLE` is set in *flags*.
532536
533537
On success, set ``view->obj`` to a new reference to *exporter* and
534-
return 0. Otherwise, raise :c:data:`PyExc_BufferError`, set
538+
return 0. Otherwise, raise :exc:`BufferError`, set
535539
``view->obj`` to ``NULL`` and return ``-1``;
536540
537541
If this function is used as part of a :ref:`getbufferproc <buffer-structs>`,

_sources/c-api/typeobj.rst.txt

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1697,7 +1697,7 @@ and :c:data:`PyType_Type` effectively act as defaults.)
16971697
to a pointer, are valid C99 address constants.
16981698

16991699
However, the unary '&' operator applied to a non-static variable
1700-
like :c:func:`PyBaseObject_Type` is not required to produce an address
1700+
like :c:data:`PyBaseObject_Type` is not required to produce an address
17011701
constant. Compilers may support this (gcc does), MSVC does not.
17021702
Both compilers are strictly standard conforming in this particular
17031703
behavior.
@@ -2443,7 +2443,7 @@ Buffer Object Structures
24432443
Except for point (3), an implementation of this function MUST take these
24442444
steps:
24452445

2446-
(1) Check if the request can be met. If not, raise :c:data:`PyExc_BufferError`,
2446+
(1) Check if the request can be met. If not, raise :exc:`BufferError`,
24472447
set :c:expr:`view->obj` to ``NULL`` and return ``-1``.
24482448

24492449
(2) Fill in the requested fields.

_sources/contents.rst.txt

Lines changed: 0 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -11,7 +11,6 @@
1111
library/index.rst
1212
extending/index.rst
1313
c-api/index.rst
14-
distributing/index.rst
1514
installing/index.rst
1615
howto/index.rst
1716
faq/index.rst
@@ -21,10 +20,3 @@
2120
bugs.rst
2221
copyright.rst
2322
license.rst
24-
25-
.. to include legacy packaging docs in build
26-
27-
.. toctree::
28-
:hidden:
29-
30-
install/index.rst
Lines changed: 10 additions & 165 deletions
Original file line numberDiff line numberDiff line change
@@ -1,174 +1,19 @@
1+
:orphan:
2+
3+
.. This page is retained solely for existing links to /distributing/index.html.
4+
Direct readers to the PPUG instead.
5+
16
.. _distributing-index:
27

38
###############################
49
Distributing Python Modules
510
###############################
611

7-
:Email: distutils-sig@python.org
8-
9-
10-
As a popular open source development project, Python has an active
11-
supporting community of contributors and users that also make their software
12-
available for other Python developers to use under open source license terms.
13-
14-
This allows Python users to share and collaborate effectively, benefiting
15-
from the solutions others have already created to common (and sometimes
16-
even rare!) problems, as well as potentially contributing their own
17-
solutions to the common pool.
18-
19-
This guide covers the distribution part of the process. For a guide to
20-
installing other Python projects, refer to the
21-
:ref:`installation guide <installing-index>`.
22-
2312
.. note::
2413

25-
For corporate and other institutional users, be aware that many
26-
organisations have their own policies around using and contributing to
27-
open source software. Please take such policies into account when making
28-
use of the distribution and installation tools provided with Python.
29-
30-
31-
Key terms
32-
=========
33-
34-
* the `Python Package Index <https://pypi.org>`__ is a public
35-
repository of open source licensed packages made available for use by
36-
other Python users
37-
* the `Python Packaging Authority
38-
<https://www.pypa.io/>`__ are the group of
39-
developers and documentation authors responsible for the maintenance and
40-
evolution of the standard packaging tools and the associated metadata and
41-
file format standards. They maintain a variety of tools, documentation
42-
and issue trackers on `GitHub <https://github.com/pypa>`__.
43-
* ``distutils`` is the original build and distribution system first added
44-
to the Python standard library in 1998. While direct use of ``distutils``
45-
is being phased out, it still laid the foundation for the current packaging
46-
and distribution infrastructure, and it not only remains part of the
47-
standard library, but its name lives on in other ways (such as the name
48-
of the mailing list used to coordinate Python packaging standards
49-
development).
50-
* `setuptools`_ is a (largely) drop-in replacement for ``distutils`` first
51-
published in 2004. Its most notable addition over the unmodified
52-
``distutils`` tools was the ability to declare dependencies on other
53-
packages. It is currently recommended as a more regularly updated
54-
alternative to ``distutils`` that offers consistent support for more
55-
recent packaging standards across a wide range of Python versions.
56-
* `wheel`_ (in this context) is a project that adds the ``bdist_wheel``
57-
command to ``distutils``/`setuptools`_. This produces a cross platform
58-
binary packaging format (called "wheels" or "wheel files" and defined in
59-
:pep:`427`) that allows Python libraries, even those including binary
60-
extensions, to be installed on a system without needing to be built
61-
locally.
62-
63-
.. _setuptools: https://setuptools.readthedocs.io/en/latest/
64-
.. _wheel: https://wheel.readthedocs.io/
65-
66-
Open source licensing and collaboration
67-
=======================================
68-
69-
In most parts of the world, software is automatically covered by copyright.
70-
This means that other developers require explicit permission to copy, use,
71-
modify and redistribute the software.
72-
73-
Open source licensing is a way of explicitly granting such permission in a
74-
relatively consistent way, allowing developers to share and collaborate
75-
efficiently by making common solutions to various problems freely available.
76-
This leaves many developers free to spend more time focusing on the problems
77-
that are relatively unique to their specific situation.
78-
79-
The distribution tools provided with Python are designed to make it
80-
reasonably straightforward for developers to make their own contributions
81-
back to that common pool of software if they choose to do so.
82-
83-
The same distribution tools can also be used to distribute software within
84-
an organisation, regardless of whether that software is published as open
85-
source software or not.
86-
87-
88-
Installing the tools
89-
====================
90-
91-
The standard library does not include build tools that support modern
92-
Python packaging standards, as the core development team has found that it
93-
is important to have standard tools that work consistently, even on older
94-
versions of Python.
95-
96-
The currently recommended build and distribution tools can be installed
97-
by invoking the ``pip`` module at the command line::
98-
99-
python -m pip install setuptools wheel twine
100-
101-
.. note::
102-
103-
For POSIX users (including macOS and Linux users), these instructions
104-
assume the use of a :term:`virtual environment`.
105-
106-
For Windows users, these instructions assume that the option to
107-
adjust the system PATH environment variable was selected when installing
108-
Python.
109-
110-
The Python Packaging User Guide includes more details on the `currently
111-
recommended tools`_.
112-
113-
.. _currently recommended tools: https://packaging.python.org/guides/tool-recommendations/#packaging-tool-recommendations
114-
115-
.. index::
116-
single: Python Package Index (PyPI)
117-
single: PyPI; (see Python Package Index (PyPI))
118-
119-
.. _publishing-python-packages:
120-
121-
Reading the Python Packaging User Guide
122-
=======================================
123-
124-
The Python Packaging User Guide covers the various key steps and elements
125-
involved in creating and publishing a project:
126-
127-
* `Project structure`_
128-
* `Building and packaging the project`_
129-
* `Uploading the project to the Python Package Index`_
130-
* `The .pypirc file`_
131-
132-
.. _Project structure: https://packaging.python.org/tutorials/packaging-projects/#packaging-python-projects
133-
.. _Building and packaging the project: https://packaging.python.org/tutorials/packaging-projects/#creating-the-package-files
134-
.. _Uploading the project to the Python Package Index: https://packaging.python.org/tutorials/packaging-projects/#uploading-the-distribution-archives
135-
.. _The .pypirc file: https://packaging.python.org/specifications/pypirc/
136-
137-
138-
How do I...?
139-
============
140-
141-
These are quick answers or links for some common tasks.
142-
143-
... choose a name for my project?
144-
---------------------------------
145-
146-
This isn't an easy topic, but here are a few tips:
147-
148-
* check the Python Package Index to see if the name is already in use
149-
* check popular hosting sites like GitHub, Bitbucket, etc to see if there
150-
is already a project with that name
151-
* check what comes up in a web search for the name you're considering
152-
* avoid particularly common words, especially ones with multiple meanings,
153-
as they can make it difficult for users to find your software when
154-
searching for it
155-
156-
157-
... create and distribute binary extensions?
158-
--------------------------------------------
159-
160-
This is actually quite a complex topic, with a variety of alternatives
161-
available depending on exactly what you're aiming to achieve. See the
162-
Python Packaging User Guide for more information and recommendations.
163-
164-
.. seealso::
165-
166-
`Python Packaging User Guide: Binary Extensions
167-
<https://packaging.python.org/guides/packaging-binary-extensions/>`__
168-
169-
.. other topics:
14+
Information and guidance on distributing Python modules and packages
15+
has been moved to the `Python Packaging User Guide`_,
16+
and the tutorial on `packaging Python projects`_.
17017

171-
Once the Development & Deployment part of PPUG is fleshed out, some of
172-
those sections should be linked from new questions here (most notably,
173-
we should have a question about avoiding depending on PyPI that links to
174-
https://packaging.python.org/en/latest/mirrors/)
18+
.. _Python Packaging User Guide: https://packaging.python.org/
19+
.. _packaging Python projects: https://packaging.python.org/en/latest/tutorials/packaging-projects/

_sources/extending/building.rst.txt

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -45,6 +45,7 @@ See the *"Multiple modules in one library"* section in :pep:`489` for details.
4545
4646
.. highlight:: c
4747
48+
.. _install-index:
4849
.. _setuptools-index:
4950
5051
Building C and C++ Extensions with setuptools

_sources/extending/extending.rst.txt

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -242,7 +242,7 @@ needed to ensure that it will not be discarded, causing :c:data:`!SpamError` to
242242
become a dangling pointer. Should it become a dangling pointer, C code which
243243
raises the exception could cause a core dump or other unintended side effects.
244244

245-
We discuss the use of ``PyMODINIT_FUNC`` as a function return type later in this
245+
We discuss the use of :c:macro:`PyMODINIT_FUNC` as a function return type later in this
246246
sample.
247247

248248
The :exc:`!spam.error` exception can be raised in your extension module using a
@@ -363,7 +363,7 @@ only non-\ ``static`` item defined in the module file::
363363
return PyModule_Create(&spammodule);
364364
}
365365

366-
Note that PyMODINIT_FUNC declares the function as ``PyObject *`` return type,
366+
Note that :c:macro:`PyMODINIT_FUNC` declares the function as ``PyObject *`` return type,
367367
declares any special linkage declarations required by the platform, and for C++
368368
declares the function as ``extern "C"``.
369369

0 commit comments

Comments
 (0)