Skip to content

Commit 2b1e26b

Browse files
CarreauCarreau
committed
Convert pep 2 to ReST
42b38c5 Fix indentation to 4 space. 5962011 Auto convert pep-0002 to rst 6fcce5d Manual fixes to pep 0002
1 parent d0af539 commit 2b1e26b

File tree

1 file changed

+150
-158
lines changed

1 file changed

+150
-158
lines changed

‎pep-0002.txt

+150-158
Original file line numberDiff line numberDiff line change
@@ -5,204 +5,196 @@ Last-Modified: $Date$
55
Author: Martijn Faassen <[email protected]>
66
Status: Final
77
Type: Process
8+
Content-Type: text/x-rst
89
Created: 07-Jul-2001
910
Post-History: 07-Jul-2001, 09-Mar-2002
1011

1112

13+
1214
PEP Replacement
15+
===============
1316

14-
This PEP has been superseded by the updated material in the Python
15-
Developer's Guide [1].
17+
This PEP has been superseded by the updated material in the Python Developer's
18+
Guide [1]_.
1619

1720
Introduction
21+
============
22+
23+
The Python Standard Library contributes significantly to Python's success. The
24+
language comes with "batteries included", so it is easy for people to become
25+
productive with just the standard library alone. It is therefore important
26+
that this library grows with the language, and that such growth is supported
27+
and encouraged.
28+
29+
Many contributions to the library are not created by core developers but by
30+
people from the Python community who are experts in their particular field.
31+
Furthermore, community members are also the users of the standard library,
32+
applying it in a great diversity of settings. This makes the community well
33+
equipped to detect and report gaps in the library; things that are missing but
34+
should be added.
35+
36+
New functionality is commonly added to the library in the form of new modules.
37+
This PEP will describe the procedure for the *addition* of new modules. PEP 4
38+
deals with procedures for deprecation of modules; the *removal* of old and
39+
unused modules from the standard library. Finally there is also the issue of
40+
*changing* existing modules to make the picture of library evolution complete.
41+
PEP 3 and PEP 5 give some guidelines on this. The continued maintenance of
42+
existing modules is an integral part of the decision on whether to add a new
43+
module to the standard library. Therefore, this PEP also introduces concepts
44+
(integrators, maintainers) relevant to the maintenance issue.
1845

19-
The Python Standard Library contributes significantly to Python's
20-
success. The language comes with "batteries included", so it is
21-
easy for people to become productive with just the standard
22-
library alone. It is therefore important that this library grows
23-
with the language, and that such growth is supported and
24-
encouraged.
25-
26-
Many contributions to the library are not created by core
27-
developers but by people from the Python community who are experts
28-
in their particular field. Furthermore, community members are
29-
also the users of the standard library, applying it in a great
30-
diversity of settings. This makes the community well equipped to
31-
detect and report gaps in the library; things that are missing but
32-
should be added.
33-
34-
New functionality is commonly added to the library in the form of
35-
new modules. This PEP will describe the procedure for the
36-
_addition_ of new modules. PEP 4 deals with procedures for
37-
deprecation of modules; the _removal_ of old and unused modules
38-
from the standard library. Finally there is also the issue of
39-
_changing_ existing modules to make the picture of library
40-
evolution complete. PEP 3 and PEP 5 give some guidelines on this.
41-
The continued maintenance of existing modules is an integral part
42-
of the decision on whether to add a new module to the standard
43-
library. Therefore, this PEP also introduces concepts
44-
(integrators, maintainers) relevant to the maintenance issue.
45-
4646

4747
Integrators
48+
===========
4849

49-
The integrators are a group of people with the following
50-
responsibilities:
50+
The integrators are a group of people with the following responsibilities:
5151

52-
- They determine if a proposed contribution should become part of
53-
the standard library.
52+
* They determine if a proposed contribution should become part of the standard
53+
library.
5454

55-
- They integrate accepted contributions into the standard library.
55+
* They integrate accepted contributions into the standard library.
5656

57-
- They produce standard library releases.
57+
* They produce standard library releases.
5858

59-
This group of people shall be PythonLabs, led by Guido.
59+
This group of people shall be PythonLabs, led by Guido.
6060

6161

6262
Maintainer(s)
63+
=============
6364

64-
All contributions to the standard library need one or more
65-
maintainers. This can be an individual, but it is frequently a
66-
group of people such as the XML-SIG. Groups may subdivide
67-
maintenance tasks among themselves. One ore more maintainers
68-
shall be the _head maintainer_ (usually this is also the main
69-
developer). Head maintainers are convenient people the
70-
integrators can address if they want to resolve specific issues,
71-
such as the ones detailed later in this document.
65+
All contributions to the standard library need one or more maintainers. This
66+
can be an individual, but it is frequently a group of people such as the XML-
67+
SIG. Groups may subdivide maintenance tasks among themselves. One ore more
68+
maintainers shall be the *head maintainer* (usually this is also the main
69+
developer). Head maintainers are convenient people the integrators can address
70+
if they want to resolve specific issues, such as the ones detailed later in
71+
this document.
7272

7373

7474
Developers(s)
75+
=============
7576

76-
Contributions to the standard library have been developed by one
77-
or more developers. The initial maintainers are the original
78-
developers unless there are special circumstances (which should be
79-
detailed in the PEP proposing the contribution).
77+
Contributions to the standard library have been developed by one or more
78+
developers. The initial maintainers are the original developers unless there
79+
are special circumstances (which should be detailed in the PEP proposing the
80+
contribution).
8081

8182

8283
Acceptance Procedure
84+
====================
85+
86+
When developers wish to have a contribution accepted into the standard library,
87+
they will first form a group of maintainers (normally initially consisting of
88+
themselves).
89+
90+
Then, this group shall produce a PEP called a library PEP. A library PEP is a
91+
special form of standards track PEP. The library PEP gives an overview of the
92+
proposed contribution, along with the proposed contribution as the reference
93+
implementation. This PEP should also contain a motivation on why this
94+
contribution should be part of the standard library.
95+
96+
One or more maintainers shall step forward as PEP champion (the people listed
97+
in the Author field are the champions). The PEP champion(s) shall be the
98+
initial head maintainer(s).
99+
100+
As described in PEP 1, a standards track PEP should consist of a design
101+
document and a reference implementation. The library PEP differs from a normal
102+
standard track PEP in that the reference implementation should in this case
103+
always already have been written before the PEP is to be reviewed for inclusion
104+
by the integrators and to be commented upon by the community; the reference
105+
implementation *is* the proposed contribution.
106+
107+
This different requirement exists for the following reasons:
108+
109+
* The integrators can only properly evaluate a contribution to the standard
110+
library when there is source code and documentation to look at; i.e. the
111+
reference implementation is always necessary to aid people in studying the
112+
PEP.
113+
114+
* Even rejected contributions will be useful outside the standard library, so
115+
there will a lower risk of waste of effort by the developers.
116+
117+
* It will impress the integrators of the seriousness of contribution and will
118+
help guard them against having to evaluate too many frivolous proposals.
83119

84-
When developers wish to have a contribution accepted into the
85-
standard library, they will first form a group of maintainers
86-
(normally initially consisting of themselves).
87-
88-
Then, this group shall produce a PEP called a library PEP. A
89-
library PEP is a special form of standards track PEP. The library
90-
PEP gives an overview of the proposed contribution, along with the
91-
proposed contribution as the reference implementation. This PEP
92-
should also contain a motivation on why this contribution should
93-
be part of the standard library.
94-
95-
One or more maintainers shall step forward as PEP champion (the
96-
people listed in the Author field are the champions). The PEP
97-
champion(s) shall be the initial head maintainer(s).
98-
99-
As described in PEP 1, a standards track PEP should consist of a
100-
design document and a reference implementation. The library PEP
101-
differs from a normal standard track PEP in that the reference
102-
implementation should in this case always already have been
103-
written before the PEP is to be reviewed for inclusion by the
104-
integrators and to be commented upon by the community; the
105-
reference implementation _is_ the proposed contribution.
106-
107-
This different requirement exists for the following reasons:
108-
109-
- The integrators can only properly evaluate a contribution to the
110-
standard library when there is source code and documentation to
111-
look at; i.e. the reference implementation is always necessary
112-
to aid people in studying the PEP.
113-
114-
- Even rejected contributions will be useful outside the standard
115-
library, so there will a lower risk of waste of effort by the
116-
developers.
117-
118-
- It will impress the integrators of the seriousness of
119-
contribution and will help guard them against having to evaluate
120-
too many frivolous proposals.
121-
122-
Once the library PEP has been submitted for review, the
123-
integrators will then evaluate it. The PEP will follow the normal
124-
PEP work flow as described in PEP 1. If the PEP is accepted, they
125-
will work through the head maintainers to make the contribution
126-
ready for integration.
120+
Once the library PEP has been submitted for review, the integrators will then
121+
evaluate it. The PEP will follow the normal PEP work flow as described in PEP
122+
1. If the PEP is accepted, they will work through the head maintainers to make
123+
the contribution ready for integration.
127124

128125

129126
Maintenance Procedure
127+
=====================
130128

131-
After a contribution has been accepted, the job is not over for
132-
both integrators and maintainers. The integrators will forward
133-
any bug reports in the standard library to the appropriate head
134-
maintainers.
135-
136-
Before the feature freeze preparing for a release of the standard
137-
library, the integrators will check with the head maintainers for
138-
all contributions, to see if there are any updates to be included
139-
in the next release. The integrators will evaluate any such
140-
updates for issues like backwards compatibility and may require
141-
PEPs if the changes are deemed to be large.
142-
143-
The head maintainers should take an active role in keeping up to
144-
date with the Python development process. If a head maintainer is
145-
unable to function in this way, he or she should announce the
146-
intention to step down to the integrators and the rest of the
147-
maintainers, so that a replacement can step forward. The
148-
integrators should at all times be capable of reaching the head
149-
maintainers by email.
150-
151-
In the case where no head maintainer can be found (possibly
152-
because there are no maintainers left), the integrators will issue
153-
a call to the community at large asking for new maintainers to
154-
step forward. If no one does, the integrators can decide to
155-
declare the contribution deprecated as described in PEP 4.
129+
After a contribution has been accepted, the job is not over for both
130+
integrators and maintainers. The integrators will forward any bug reports in
131+
the standard library to the appropriate head maintainers.
132+
133+
Before the feature freeze preparing for a release of the standard library, the
134+
integrators will check with the head maintainers for all contributions, to see
135+
if there are any updates to be included in the next release. The integrators
136+
will evaluate any such updates for issues like backwards compatibility and may
137+
require PEPs if the changes are deemed to be large.
138+
139+
The head maintainers should take an active role in keeping up to date with the
140+
Python development process. If a head maintainer is unable to function in this
141+
way, he or she should announce the intention to step down to the integrators
142+
and the rest of the maintainers, so that a replacement can step forward. The
143+
integrators should at all times be capable of reaching the head maintainers by
144+
email.
145+
146+
In the case where no head maintainer can be found (possibly because there are
147+
no maintainers left), the integrators will issue a call to the community at
148+
large asking for new maintainers to step forward. If no one does, the
149+
integrators can decide to declare the contribution deprecated as described in
150+
PEP 4.
156151

157152

158153
Open issues
154+
===========
155+
156+
There needs to be some procedure so that the integrators can always reach the
157+
maintainers (or at least the head maintainers). This could be accomplished by a
158+
mailing list to which all head maintainers should be subscribed (this could be
159+
python-dev). Another possibility, which may be useful in any case, is the
160+
maintenance of a list similar to that of the list of PEPs which lists all the
161+
contributions and their head maintainers with contact info. This could in fact
162+
be part of the list of the PEPs, as a new contribution requires a PEP. But
163+
since the authors/owners of a PEP introducing a new module may eventually be
164+
different from those who maintain it, this wouldn't resolve all issues yet.
165+
166+
Should there be a list of what criteria integrators use for evaluating
167+
contributions? (Source code but also things like documentation and a test
168+
suite, as well as such vague things like 'dependability of the maintainers'.)
159169

160-
There needs to be some procedure so that the integrators can
161-
always reach the maintainers (or at least the head maintainers).
162-
This could be accomplished by a mailing list to which all head
163-
maintainers should be subscribed (this could be python-dev).
164-
Another possibility, which may be useful in any case, is the
165-
maintenance of a list similar to that of the list of PEPs which
166-
lists all the contributions and their head maintainers with
167-
contact info. This could in fact be part of the list of the PEPs,
168-
as a new contribution requires a PEP. But since the
169-
authors/owners of a PEP introducing a new module may eventually be
170-
different from those who maintain it, this wouldn't resolve all
171-
issues yet.
172-
173-
Should there be a list of what criteria integrators use for
174-
evaluating contributions? (Source code but also things like
175-
documentation and a test suite, as well as such vague things like
176-
'dependability of the maintainers'.)
177-
178-
This relates to all the technical issues; check-in privileges,
179-
coding style requirements, documentation requirements, test suite
180-
requirements. These are preferably part of another PEP.
181-
182-
Should the current standard library be subdivided among
183-
maintainers? Many parts already have (informal) maintainers; it
184-
may be good to make this more explicit.
185-
186-
Perhaps there is a better word for 'contribution'; the word
187-
'contribution' may not imply enough that the process (of
188-
development and maintenance) does not stop after the contribution
189-
is accepted and integrated into the library.
190-
191-
Relationship to the mythical Catalog?
170+
This relates to all the technical issues; check-in privileges, coding style
171+
requirements, documentation requirements, test suite requirements. These are
172+
preferably part of another PEP.
173+
174+
Should the current standard library be subdivided among maintainers? Many
175+
parts already have (informal) maintainers; it may be good to make this more
176+
explicit.
177+
178+
Perhaps there is a better word for 'contribution'; the word 'contribution' may
179+
not imply enough that the process (of development and maintenance) does not
180+
stop after the contribution is accepted and integrated into the library.
181+
182+
Relationship to the mythical Catalog?
192183

193184
References
185+
==========
194186

195-
[1] Adding to the Stdlib
196-
http://docs.python.org/devguide/stdlibchanges.html
187+
.. [1] Adding to the Stdlib
188+
(http://docs.python.org/devguide/stdlibchanges.html)
197189

198190
Copyright
191+
=========
199192

200-
This document has been placed in the public domain.
201-
193+
This document has been placed in the public domain.
202194

203-
204-
Local Variables:
205-
mode: indented-text
206-
indent-tabs-mode: nil
207-
fill-column: 70
208-
End:
195+
..
196+
Local Variables:
197+
mode: indented-text
198+
indent-tabs-mode: nil
199+
fill-column: 70
200+
End:

0 commit comments

Comments
 (0)