Skip to content

Commit cce5754

Browse files
Carreauberkerpeksag
Carreau
authored and
berkerpeksag
committed
Convert PEP 2 to reST format
1 parent 6929f85 commit cce5754

File tree

1 file changed

+164
-159
lines changed

1 file changed

+164
-159
lines changed

‎pep-0002.txt

+164-159
Original file line numberDiff line numberDiff line change
@@ -5,204 +5,209 @@ 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
18+
Developer's Guide [1]_.
1619

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

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-
4647

4748
Integrators
49+
===========
4850

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

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

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

57-
- They produce standard library releases.
59+
* They produce standard library releases.
5860

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

6163

6264
Maintainer(s)
65+
=============
6366

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

7376

7477
Developers(s)
78+
=============
7579

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).
80+
Contributions to the standard library have been developed by one or
81+
more developers. The initial maintainers are the original developers
82+
unless there are special circumstances (which should be detailed in
83+
the PEP proposing the contribution).
8084

8185

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

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.
119+
* Even rejected contributions will be useful outside the standard
120+
library, so there will a lower risk of waste of effort by the
121+
developers.
122+
123+
* It will impress the integrators of the seriousness of contribution
124+
and will help guard them against having to evaluate too many
125+
frivolous proposals.
126+
127+
Once the library PEP has been submitted for review, the integrators
128+
will then evaluate it. The PEP will follow the normal PEP work flow
129+
as described in PEP 1. If the PEP is accepted, they will work through
130+
the head maintainers to make the contribution ready for integration.
127131

128132

129133
Maintenance Procedure
134+
=====================
130135

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.
136+
After a contribution has been accepted, the job is not over for both
137+
integrators and maintainers. The integrators will forward any bug
138+
reports in the standard library to the appropriate head maintainers.
156139

140+
Before the feature freeze preparing for a release of the standard
141+
library, the integrators will check with the head maintainers for all
142+
contributions, to see if there are any updates to be included in the
143+
next release. The integrators will evaluate any such updates for
144+
issues like backwards compatibility and may require PEPs if the
145+
changes are deemed to be large.
157146

158-
Open issues
147+
The head maintainers should take an active role in keeping up to date
148+
with the Python development process. If a head maintainer is unable
149+
to function in this way, he or she should announce the intention to
150+
step down to the integrators and the rest of the maintainers, so that
151+
a replacement can step forward. The integrators should at all times
152+
be capable of reaching the head maintainers by email.
153+
154+
In the case where no head maintainer can be found (possibly because
155+
there are no maintainers left), the integrators will issue a call to
156+
the community at large asking for new maintainers to step forward. If
157+
no one does, the integrators can decide to declare the contribution
158+
deprecated as described in PEP 4.
159159

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

193196
References
197+
==========
194198

195-
[1] Adding to the Stdlib
196-
http://docs.python.org/devguide/stdlibchanges.html
199+
.. [1] Adding to the Stdlib
200+
(http://docs.python.org/devguide/stdlibchanges.html)
197201

198202
Copyright
203+
=========
199204

200-
This document has been placed in the public domain.
201-
205+
This document has been placed in the public domain.
202206

203-
204-
Local Variables:
205-
mode: indented-text
206-
indent-tabs-mode: nil
207-
fill-column: 70
208-
End:
207+
..
208+
Local Variables:
209+
mode: indented-text
210+
indent-tabs-mode: nil
211+
fill-column: 70
212+
coding: utf-8
213+
End:

0 commit comments

Comments
 (0)