forked from python/peps
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathpep-0337.txt
205 lines (130 loc) · 4.86 KB
/
pep-0337.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
PEP: 337
Title: Logging Usage in the Standard Library
Version: $Revision$
Last-Modified: $Date$
Author: Michael P. Dubner <[email protected]>
Status: Deferred
Type: Standards Track
Content-Type: text/x-rst
Created: 02-Oct-2004
Python-Version: 2.5
Post-History: 10-Nov-2004
Abstract
========
This PEP defines a standard for using the logging system (:pep:`282`) in the
standard library.
Implementing this PEP will simplify development of daemon
applications. As a downside this PEP requires slight
modifications (however in a back-portable way) to a large number
of standard modules.
After implementing this PEP one can use following filtering
scheme::
logging.getLogger('py.BaseHTTPServer').setLevel(logging.FATAL)
PEP Deferral
============
Further exploration of the concepts covered in this PEP has been deferred
for lack of a current champion interested in promoting the goals of the
PEP and collecting and incorporating feedback, and with sufficient
available time to do so effectively.
Rationale
=========
There are a couple of situations when output to stdout or stderr
is impractical:
- Daemon applications where the framework doesn't allow the
redirection of standard output to some file, but assumes use of
some other form of logging. Examples are syslog under \*nix'es
and EventLog under WinNT+.
- GUI applications which want to output every new log entry in
separate pop-up window (i.e. fading OSD).
Also sometimes applications want to filter output entries based on
their source or severity. This requirement can't be implemented
using simple redirection.
Finally sometimes output needs to be marked with event timestamps,
which can be accomplished with ease using the logging system.
Proposal
========
Every module usable for daemon and GUI applications should be
rewritten to use the logging system instead of ``print`` or
``sys.stdout.write``.
There should be code like this included in the beginning of every
modified module::
import logging
_log = logging.getLogger('py.<module-name>')
A prefix of ``py.`` [2]_ must be used by all modules included in the
standard library distributed along with Python, and only by such
modules (unverifiable). The use of ``_log`` is intentional as we
don't want to auto-export it. For modules that use log only in
one class a logger can be created inside the class definition as
follows::
class XXX:
__log = logging.getLogger('py.<module-name>')
Then this class can create access methods to log to this private
logger.
So ``print`` and ``sys.std{out|err}.write`` statements should be
replaced with ``_log.{debug|info}``, and ``traceback.print_exception``
with ``_log.exception`` or sometimes ``_log.debug('...', exc_info=1)``.
Module List
===========
Here is a (possibly incomplete) list of modules to be reworked:
- asyncore (dispatcher.log, dispatcher.log_info)
- BaseHTTPServer (BaseHTTPRequestHandler.log_request,
BaseHTTPRequestHandler.log_error,
BaseHTTPRequestHandler.log_message)
- cgi (possibly - is cgi.log used by somebody?)
- ftplib (if FTP.debugging)
- gopherlib (get_directory)
- httplib (HTTPResponse, HTTPConnection)
- ihooks (_Verbose)
- imaplib (IMAP4._mesg)
- mhlib (MH.error)
- nntplib (NNTP)
- pipes (Template.makepipeline)
- pkgutil (extend_path)
- platform (_syscmd_ver)
- poplib (if POP3._debugging)
- profile (if Profile.verbose)
- robotparser (_debug)
- smtplib (if SGMLParser.verbose)
- shlex (if shlex.debug)
- smtpd (SMTPChannel/PureProxy where print >> DEBUGSTREAM)
- smtplib (if SMTP.debuglevel)
- SocketServer (BaseServer.handle_error)
- telnetlib (if Telnet.debuglevel)
- threading? (_Verbose._note, Thread.__bootstrap)
- timeit (Timer.print_exc)
- trace
- uu (decode)
Additionally there are a couple of modules with commented debug
output or modules where debug output should be added. For
example:
- urllib
Finally possibly some modules should be extended to provide more
debug information.
Doubtful Modules
================
Listed here are modules that the community will propose for
addition to the module list and modules that the community say
should be removed from the module list.
- tabnanny (check)
Guidelines for Logging Usage
============================
Also we can provide some recommendation to authors of library
modules so they all follow the same format of naming loggers. I
propose that non-standard library modules should use loggers named
after their full names, so a module "spam" in sub-package "junk"
of package "dummy" will be named "dummy.junk.spam" and, of course,
the ``__init__`` module of the same sub-package will have the logger
name "dummy.junk".
References
==========
.. [2] https://mail.python.org/pipermail/python-dev/2004-October/049282.html
Copyright
=========
This document has been placed in the public domain.
..
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
End: