BERJAYA

PEP 1, PEP Purpose and Guidelines
by barry＠zope.com May 18, 2021

May 18, 2021

It has been a while since I posted a copy of PEP 1 to the mailing lists and newsgroups. I've recently done some updating of a few sections, so in the interest of gaining wider community participation in the Python development process, I'm posting the latest revision of PEP 1 here. A version of the PEP is always available on-line at http://www.python.org/peps/pep-0001.html Enjoy, -Barry -------------------- snip snip -------------------- PEP: 1 Title: PEP Purpose and Guidelines Version: $Revision: 1.36 $ Last-Modified: $Date: 2002/07/29 18:34:59 $ Author: Barry A. Warsaw, Jeremy Hylton Status: Active Type: Informational Created: 13-Jun-2000 Post-History: 21-Mar-2001, 29-Jul-2002 What is a PEP? PEP stands for Python Enhancement Proposal. A PEP is a design document providing information to the Python community, or describing a new feature for Python. The PEP should provide a concise technical specification of the feature and a rationale for the feature. We intend PEPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Python. The PEP author is responsible for building consensus within the community and documenting dissenting opinions. Because the PEPs are maintained as plain text files under CVS control, their revision history is the historical record of the feature proposal[1]. Kinds of PEPs There are two kinds of PEPs. A standards track PEP describes a new feature or implementation for Python. An informational PEP describes a Python design issue, or provides general guidelines or information to the Python community, but does not propose a new feature. Informational PEPs do not necessarily represent a Python community consensus or recommendation, so users and implementors are free to ignore informational PEPs or follow their advice. PEP Work Flow The PEP editor, Barry Warsaw <peps(a)python.org>, assigns numbers for each PEP and changes its status. The PEP process begins with a new idea for Python. It is highly recommended that a single PEP contain a single key proposal or new idea. The more focussed the PEP, the more successfully it tends to be. The PEP editor reserves the right to reject PEP proposals if they appear too unfocussed or too broad. If in doubt, split your PEP into several well-focussed ones. Each PEP must have a champion -- someone who writes the PEP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The PEP champion (a.k.a. Author) should first attempt to ascertain whether the idea is PEP-able. Small enhancements or patches often don't need a PEP and can be injected into the Python development work flow with a patch submission to the SourceForge patch manager[2] or feature request tracker[3]. The PEP champion then emails the PEP editor <peps(a)python.org> with a proposed title and a rough, but fleshed out, draft of the PEP. This draft must be written in PEP style as described below. If the PEP editor approves, he will assign the PEP a number, label it as standards track or informational, give it status 'draft', and create and check-in the initial draft of the PEP. The PEP editor will not unreasonably deny a PEP. Reasons for denying PEP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Python philosophy. The BDFL (Benevolent Dictator for Life, Guido van Rossum) can be consulted during the approval phase, and is the final arbitrator of the draft's PEP-ability. If a pre-PEP is rejected, the author may elect to take the pre-PEP to the comp.lang.python newsgroup (a.k.a. python-list(a)python.org mailing list) to help flesh it out, gain feedback and consensus from the community at large, and improve the PEP for re-submission. The author of the PEP is then responsible for posting the PEP to the community forums, and marshaling community support for it. As updates are necessary, the PEP author can check in new versions if they have CVS commit permissions, or can email new PEP versions to the PEP editor for committing. Standards track PEPs consists of two parts, a design document and a reference implementation. The PEP should be reviewed and accepted before a reference implementation is begun, unless a reference implementation will aid people in studying the PEP. Standards Track PEPs must include an implementation - in the form of code, patch, or URL to same - before it can be considered Final. PEP authors are responsible for collecting community feedback on a PEP before submitting it for review. A PEP that has not been discussed on python-list(a)python.org and/or python-dev(a)python.org will not be accepted. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include, setting up a separate SIG mailing list for the topic, having the PEP author accept private comments in the early design phases, etc. PEP authors should use their discretion here. Once the authors have completed a PEP, they must inform the PEP editor that it is ready for review. PEPs are reviewed by the BDFL and his chosen consultants, who may accept or reject a PEP or send it back to the author(s) for revision. Once a PEP has been accepted, the reference implementation must be completed. When the reference implementation is complete and accepted by the BDFL, the status will be changed to `Final.' A PEP can also be assigned status `Deferred.' The PEP author or editor can assign the PEP this status when no progress is being made on the PEP. Once a PEP is deferred, the PEP editor can re-assign it to draft status. A PEP can also be `Rejected'. Perhaps after all is said and done it was not a good idea. It is still important to have a record of this fact. PEPs can also be replaced by a different PEP, rendering the original obsolete. This is intended for Informational PEPs, where version 2 of an API can replace version 1. PEP work flow is as follows: Draft -> Accepted -> Final -> Replaced ^ +----> Rejected v Deferred Some informational PEPs may also have a status of `Active' if they are never meant to be completed. E.g. PEP 1. What belongs in a successful PEP? Each PEP should have the following parts: 1. Preamble -- RFC822 style headers containing meta-data about the PEP, including the PEP number, a short descriptive title (limited to a maximum of 44 characters), the names, and optionally the contact info for each author, etc. 2. Abstract -- a short (~200 word) description of the technical issue being addressed. 3. Copyright/public domain -- Each PEP must either be explicitly labelled as placed in the public domain (see this PEP as an example) or licensed under the Open Publication License[4]. 4. Specification -- The technical specification should describe the syntax and semantics of any new language feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Python platforms (CPython, JPython, Python .NET). 5. Motivation -- The motivation is critical for PEPs that want to change the Python language. It should clearly explain why the existing language specification is inadequate to address the problem that the PEP solves. PEP submissions without sufficient motivation may be rejected outright. 6. Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion. 7. Backwards Compatibility -- All PEPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The PEP must explain how the author proposes to deal with these incompatibilities. PEP submissions without a sufficient backwards compatibility treatise may be rejected outright. 8. Reference Implementation -- The reference implementation must be completed before any PEP is given status 'Final,' but it need not be completed before the PEP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for either the Python language reference or the standard library reference. PEP Template PEPs are written in plain ASCII text, and should adhere to a rigid style. There is a Python script that parses this style and converts the plain text PEP to HTML for viewing on the web[5]. PEP 9 contains a boilerplate[7] template you can use to get started writing your PEP. Each PEP must begin with an RFC822 style header preamble. The headers must appear in the following order. Headers marked with `*' are optional and are described below. All other headers are required. PEP: <pep number> Title: <pep title> Version: <cvs version string> Last-Modified: <cvs date string> Author: <list of authors' real names and optionally, email addrs> * Discussions-To: <email address> Status: <Draft | Active | Accepted | Deferred | Final | Replaced> Type: <Informational | Standards Track> * Requires: <pep numbers> Created: <date created on, in dd-mmm-yyyy format> * Python-Version: <version number> Post-History: <dates of postings to python-list and python-dev> * Replaces: <pep number> * Replaced-By: <pep number> The Author: header lists the names and optionally, the email addresses of all the authors/owners of the PEP. The format of the author entry should be address(a)dom.ain (Random J. User) if the email address is included, and just Random J. User if the address is not given. If there are multiple authors, each should be on a separate line following RFC 822 continuation line conventions. Note that personal email addresses in PEPs will be obscured as a defense against spam harvesters. Standards track PEPs must have a Python-Version: header which indicates the version of Python that the feature will be released with. Informational PEPs do not need a Python-Version: header. While a PEP is in private discussions (usually during the initial Draft phase), a Discussions-To: header will indicate the mailing list or URL where the PEP is being discussed. No Discussions-To: header is necessary if the PEP is being discussed privately with the author, or on the python-list or python-dev email mailing lists. Note that email addresses in the Discussions-To: header will not be obscured. Created: records the date that the PEP was assigned a number, while Post-History: is used to record the dates of when new versions of the PEP are posted to python-list and/or python-dev. Both headers should be in dd-mmm-yyyy format, e.g. 14-Aug-2001. PEPs may have a Requires: header, indicating the PEP numbers that this PEP depends on. PEPs may also have a Replaced-By: header indicating that a PEP has been rendered obsolete by a later document; the value is the number of the PEP that replaces the current document. The newer PEP must have a Replaces: header containing the number of the PEP that it rendered obsolete. PEP Formatting Requirements PEP headings must begin in column zero and the initial letter of each word must be capitalized as in book titles. Acronyms should be in all capitals. The body of each section must be indented 4 spaces. Code samples inside body sections should be indented a further 4 spaces, and other indentation can be used as required to make the text readable. You must use two blank lines between the last line of a section's body and the next section heading. You must adhere to the Emacs convention of adding two spaces at the end of every sentence. You should fill your paragraphs to column 70, but under no circumstances should your lines extend past column 79. If your code samples spill over column 79, you should rewrite them. Tab characters must never appear in the document at all. A PEP should include the standard Emacs stanza included by example at the bottom of this PEP. A PEP must contain a Copyright section, and it is strongly recommended to put the PEP in the public domain. When referencing an external web page in the body of a PEP, you should include the title of the page in the text, with a footnote reference to the URL. Do not include the URL in the body text of the PEP. E.g. Refer to the Python Language web site [1] for more details. ... [1] http://www.python.org When referring to another PEP, include the PEP number in the body text, such as "PEP 1". The title may optionally appear. Add a footnote reference that includes the PEP's title and author. It may optionally include the explicit URL on a separate line, but only in the References section. Note that the pep2html.py script will calculate URLs automatically, e.g.: ... Refer to PEP 1 [7] for more information about PEP style ... References [7] PEP 1, PEP Purpose and Guidelines, Warsaw, Hylton http://www.python.org/peps/pep-0001.html If you decide to provide an explicit URL for a PEP, please use this as the URL template: http://www.python.org/peps/pep-xxxx.html PEP numbers in URLs must be padded with zeros from the left, so as to be exactly 4 characters wide, however PEP numbers in text are never padded. Reporting PEP Bugs, or Submitting PEP Updates How you report a bug, or submit a PEP update depends on several factors, such as the maturity of the PEP, the preferences of the PEP author, and the nature of your comments. For the early draft stages of the PEP, it's probably best to send your comments and changes directly to the PEP author. For more mature, or finished PEPs you may want to submit corrections to the SourceForge bug manager[6] or better yet, the SourceForge patch manager[2] so that your changes don't get lost. If the PEP author is a SF developer, assign the bug/patch to him, otherwise assign it to the PEP editor. When in doubt about where to send your changes, please check first with the PEP author and/or PEP editor. PEP authors who are also SF committers, can update the PEPs themselves by using "cvs commit" to commit their changes. Remember to also push the formatted PEP text out to the web by doing the following: % python pep2html.py -i NUM where NUM is the number of the PEP you want to push out. See % python pep2html.py --help for details. Transferring PEP Ownership It occasionally becomes necessary to transfer ownership of PEPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred PEP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the PEP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the PEP. We try to build consensus around a PEP, but if that's not possible, you can always submit a competing PEP. If you are interested assuming ownership of a PEP, send a message asking to take over, addressed to both the original author and the PEP editor <peps(a)python.org>. If the original author doesn't respond to email in a timely manner, the PEP editor will make a unilateral decision (it's not like such decisions can be reversed. :). References and Footnotes [1] This historical record is available by the normal CVS commands for retrieving older revisions. For those without direct access to the CVS tree, you can browse the current and past PEP revisions via the SourceForge web site at http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/python/nondist/peps/?cvsroot=… [2] http://sourceforge.net/tracker/?group_id=5470&atid=305470 [3] http://sourceforge.net/tracker/?atid=355470&group_id=5470&func=browse [4] http://www.opencontent.org/openpub/ [5] The script referred to here is pep2html.py, which lives in the same directory in the CVS tree as the PEPs themselves. Try "pep2html.py --help" for details. The URL for viewing PEPs on the web is http://www.python.org/peps/ [6] http://sourceforge.net/tracker/?group_id=5470&atid=305470 [7] PEP 9, Sample PEP Template http://www.python.org/peps/pep-0009.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:

8 14

Re: subprocess and EINTR errnos
by Peter Astrand July 6, 2009

July 6, 2009

On Wed, 10 Nov 2004, John P Speno wrote: Hi, sorry for the delayed response. > While using subprocess (aka popen5), I came across one potential gotcha. I've had > exceptions ending like this: > > File "test.py", line 5, in test > cmd = popen5.Popen(args, stdout=PIPE) > File "popen5.py", line 577, in __init__ > data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB > OSError: [Errno 4] Interrupted system call > > (on Solaris 9) > > Would it make sense for subprocess to use a more robust read() function > which can handle these cases, i.e. when the parent's read on the pipe > to the child's stderr is interrupted by a system call, and returns EINTR? > I imagine it could catch EINTR and EAGAIN and retry the failed read(). I assume you are using signals in your application? The os.read above is not the only system call that can fail with EINTR. subprocess.py is full of other system calls that can fail, and I suspect that many other Python modules are as well. I've made a patch (attached) to subprocess.py (and test_subprocess.py) that should guard against EINTR, but I haven't committed it yet. It's quite large. Are Python modules supposed to handle EINTR? Why not let the C code handle this? Or, perhaps the signal module should provide a sigaction function, so that users can use SA_RESTART. Index: subprocess.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/subprocess.py,v retrieving revision 1.8 diff -u -r1.8 subprocess.py --- subprocess.py 7 Nov 2004 14:30:34 -0000 1.8 +++ subprocess.py 17 Nov 2004 19:42:30 -0000 @@ -888,6 +888,50 @@ pass + def _read_no_intr(self, fd, buffersize): + """Like os.read, but retries on EINTR""" + while True: + try: + return os.read(fd, buffersize) + except OSError, e: + if e.errno == errno.EINTR: + continue + else: + raise + + + def _read_all(self, fd, buffersize): + """Like os.read, but retries on EINTR, and reads until EOF""" + all = "" + while True: + data = self._read_no_intr(fd, buffersize) + all += data + if data == "": + return all + + + def _write_no_intr(self, fd, s): + """Like os.write, but retries on EINTR""" + while True: + try: + return os.write(fd, s) + except OSError, e: + if e.errno == errno.EINTR: + continue + else: + raise + + def _waitpid_no_intr(self, pid, options): + """Like os.waitpid, but retries on EINTR""" + while True: + try: + return os.waitpid(pid, options) + except OSError, e: + if e.errno == errno.EINTR: + continue + else: + raise + def _execute_child(self, args, executable, preexec_fn, close_fds, cwd, env, universal_newlines, startupinfo, creationflags, shell, @@ -963,7 +1007,7 @@ exc_value, tb) exc_value.child_traceback = ''.join(exc_lines) - os.write(errpipe_write, pickle.dumps(exc_value)) + self._write_no_intr(errpipe_write, pickle.dumps(exc_value)) # This exitcode won't be reported to applications, so it # really doesn't matter what we return. @@ -979,7 +1023,7 @@ os.close(errwrite) # Wait for exec to fail or succeed; possibly raising exception - data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB + data = self._read_all(errpipe_read, 1048576) # Exceptions limited to 1 MB os.close(errpipe_read) if data != "": child_exception = pickle.loads(data) @@ -1003,7 +1047,7 @@ attribute.""" if self.returncode == None: try: - pid, sts = os.waitpid(self.pid, os.WNOHANG) + pid, sts = self._waitpid_no_intr(self.pid, os.WNOHANG) if pid == self.pid: self._handle_exitstatus(sts) except os.error: @@ -1015,7 +1059,7 @@ """Wait for child process to terminate. Returns returncode attribute.""" if self.returncode == None: - pid, sts = os.waitpid(self.pid, 0) + pid, sts = self._waitpid_no_intr(self.pid, 0) self._handle_exitstatus(sts) return self.returncode @@ -1049,27 +1093,33 @@ stderr = [] while read_set or write_set: - rlist, wlist, xlist = select.select(read_set, write_set, []) + try: + rlist, wlist, xlist = select.select(read_set, write_set, []) + except select.error, e: + if e[0] == errno.EINTR: + continue + else: + raise if self.stdin in wlist: # When select has indicated that the file is writable, # we can write up to PIPE_BUF bytes without risk # blocking. POSIX defines PIPE_BUF >= 512 - bytes_written = os.write(self.stdin.fileno(), input[:512]) + bytes_written = self._write_no_intr(self.stdin.fileno(), input[:512]) input = input[bytes_written:] if not input: self.stdin.close() write_set.remove(self.stdin) if self.stdout in rlist: - data = os.read(self.stdout.fileno(), 1024) + data = self._read_no_intr(self.stdout.fileno(), 1024) if data == "": self.stdout.close() read_set.remove(self.stdout) stdout.append(data) if self.stderr in rlist: - data = os.read(self.stderr.fileno(), 1024) + data = self._read_no_intr(self.stderr.fileno(), 1024) if data == "": self.stderr.close() read_set.remove(self.stderr) Index: test/test_subprocess.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_subprocess.py,v retrieving revision 1.14 diff -u -r1.14 test_subprocess.py --- test/test_subprocess.py 12 Nov 2004 15:51:48 -0000 1.14 +++ test/test_subprocess.py 17 Nov 2004 19:42:30 -0000 @@ -7,6 +7,7 @@ import tempfile import time import re +import errno mswindows = (sys.platform == "win32") @@ -35,6 +36,16 @@ fname = tempfile.mktemp() return os.open(fname, os.O_RDWR|os.O_CREAT), fname + def read_no_intr(self, obj): + while True: + try: + return obj.read() + except IOError, e: + if e.errno == errno.EINTR: + continue + else: + raise + # # Generic tests # @@ -123,7 +134,7 @@ p = subprocess.Popen([sys.executable, "-c", 'import sys; sys.stdout.write("orange")'], stdout=subprocess.PIPE) - self.assertEqual(p.stdout.read(), "orange") + self.assertEqual(self.read_no_intr(p.stdout), "orange") def test_stdout_filedes(self): # stdout is set to open file descriptor @@ -151,7 +162,7 @@ p = subprocess.Popen([sys.executable, "-c", 'import sys; sys.stderr.write("strawberry")'], stderr=subprocess.PIPE) - self.assertEqual(remove_stderr_debug_decorations(p.stderr.read()), + self.assertEqual(remove_stderr_debug_decorations(self.read_no_intr(p.stderr)), "strawberry") def test_stderr_filedes(self): @@ -186,7 +197,7 @@ 'sys.stderr.write("orange")'], stdout=subprocess.PIPE, stderr=subprocess.STDOUT) - output = p.stdout.read() + output = self.read_no_intr(p.stdout) stripped = remove_stderr_debug_decorations(output) self.assertEqual(stripped, "appleorange") @@ -220,7 +231,7 @@ stdout=subprocess.PIPE, cwd=tmpdir) normcase = os.path.normcase - self.assertEqual(normcase(p.stdout.read()), normcase(tmpdir)) + self.assertEqual(normcase(self.read_no_intr(p.stdout)), normcase(tmpdir)) def test_env(self): newenv = os.environ.copy() @@ -230,7 +241,7 @@ 'sys.stdout.write(os.getenv("FRUIT"))'], stdout=subprocess.PIPE, env=newenv) - self.assertEqual(p.stdout.read(), "orange") + self.assertEqual(self.read_no_intr(p.stdout), "orange") def test_communicate(self): p = subprocess.Popen([sys.executable, "-c", @@ -305,7 +316,8 @@ 'sys.stdout.write("\\nline6");'], stdout=subprocess.PIPE, universal_newlines=1) - stdout = p.stdout.read() + + stdout = self.read_no_intr(p.stdout) if hasattr(open, 'newlines'): # Interpreter with universal newline support self.assertEqual(stdout, @@ -343,7 +355,7 @@ def test_no_leaking(self): # Make sure we leak no resources - max_handles = 1026 # too much for most UNIX systems + max_handles = 10 # too much for most UNIX systems if mswindows: max_handles = 65 # a full test is too slow on Windows for i in range(max_handles): @@ -424,7 +436,7 @@ 'sys.stdout.write(os.getenv("FRUIT"))'], stdout=subprocess.PIPE, preexec_fn=lambda: os.putenv("FRUIT", "apple")) - self.assertEqual(p.stdout.read(), "apple") + self.assertEqual(self.read_no_intr(p.stdout), "apple") def test_args_string(self): # args is a string @@ -457,7 +469,7 @@ p = subprocess.Popen(["echo $FRUIT"], shell=1, stdout=subprocess.PIPE, env=newenv) - self.assertEqual(p.stdout.read().strip(), "apple") + self.assertEqual(self.read_no_intr(p.stdout).strip(), "apple") def test_shell_string(self): # Run command through the shell (string) @@ -466,7 +478,7 @@ p = subprocess.Popen("echo $FRUIT", shell=1, stdout=subprocess.PIPE, env=newenv) - self.assertEqual(p.stdout.read().strip(), "apple") + self.assertEqual(self.read_no_intr(p.stdout).strip(), "apple") def test_call_string(self): # call() function with string argument on UNIX @@ -525,7 +537,7 @@ p = subprocess.Popen(["set"], shell=1, stdout=subprocess.PIPE, env=newenv) - self.assertNotEqual(p.stdout.read().find("physalis"), -1) + self.assertNotEqual(self.read_no_intr(p.stdout).find("physalis"), -1) def test_shell_string(self): # Run command through the shell (string) @@ -534,7 +546,7 @@ p = subprocess.Popen("set", shell=1, stdout=subprocess.PIPE, env=newenv) - self.assertNotEqual(p.stdout.read().find("physalis"), -1) + self.assertNotEqual(self.read_no_intr(p.stdout).find("physalis"), -1) def test_call_string(self): # call() function with string argument on Windows /Peter Åstrand <astrand(a)lysator.liu.se>

5 5

Pickling instances of nested classes
by Walter Dörwald April 1, 2005

April 1, 2005

Currently instances of nested classes can't be pickled. For old style classes unpickling fails to find the class: >>> import cPickle >>> class Foo: ... class Bar: ... pass ... >>> cPickle.loads(cPickle.dumps(Foo.Bar())) Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'module' object has no attribute 'Bar' For new style classes, pickling itself fails: >>> class Foo(object): ... class Bar(object): ... pass ... >>> cPickle.loads(cPickle.dumps(Foo.Bar())) Traceback (most recent call last): File "<stdin>", line 1, in ? cPickle.PicklingError: Can't pickle <class '__main__.Bar'>: attribute lookup __main__.Bar failed I think this should be fixed (see below for use cases). There's an old bug report open for this (http://www.python.org/sf/633930). Classes would need access to their fully qualified name (starting from the module level) (perhaps in a new class attribute __fullname__?) and the pickle machinery would have to use this name when storing class names instead of __name__. The second part should be easy to implement. The first part is harder. It can't be done by changing meta classes, because classes are created "inside out", i.e. in: class Foo: class Bar: class Baz: pass when Baz class is created, the Bar class hasn't been assigned a name yet. Another problem is that it should only be done for classes *defined* inside other classes, i.e. in class Foo: pass class Bar: Baz = Foo Foo should remain unchanged. For this I guess the parser would have to be changed to somehow keep a stack of currently "open" class definitions, so the __fullname__ attribute (or dict entry) can be set once a new class statement is encountered. Of course the remaining interesting question is if this change is worth it and if there are use cases for it. Possible use cases require that: 1) There's a collection of name objects in the scope of a class. 2) These objects are subclasses of other (nested or global) classes. 3) There are instances of those classes. There are two use cases that immediately come to mind: XML and ORMs. For XML: 1) Those classes are the element types and the nested classes are the attributes. 2) Being able to define those attributes as separate classes makes it possible to implement custom functionality (e.g. for validation or for handling certain attribute types like URLs, colors etc.) and 3) Those classes get instantiated when an XML tree is created or parsed. A framework that does this (and my main motivation for writing this :)) is XIST (see http://www.livinglogic.de/Python/xist/). For the ORM case: Each top level class defines a table and the nested classes are the fields, i.e. something like this: class person(Table): class firstname(Varchar): "The person's first name" null = False class lastname(Varchar): "The person's last name" null = False class password(Varchar): "Login password" def validate(self, value): if not any(c.islower() for c in value) and \ not any(c.isupper() for c in value) and \ not any(c.isdigit() for c in value): raise InvalidField("password requires a mix of upper and lower" "case letters and digits") Instances of these classes are the records read from the database. A framework that does something similar to this (although AFAIK fields are not nested classes is SQLObject (http://sqlobject.org/) So is this change wanted? useful? implementable with reasonable effort? Or just not worth it? Bye, Walter Dörwald

3 8

RE: [Python-checkins] python/dist/src/Lib/logging handlers.py, 1.19, 1.19.2.1
by Raymond Hettinger March 31, 2005

March 31, 2005

> Tag: release24-maint > handlers.py > Log Message: > Added optional encoding argument to File based handlers and improved error > handling for SysLogHandler Are you sure you want to backport an API change and new feature? Raymond

2 1

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser March 31, 2005

March 31, 2005

Patch / Bug Summary ___________________ Patches : 297 open (+11) / 2812 closed (+11) / 3109 total (+22) Bugs : 871 open ( +1) / 4900 closed (+33) / 5771 total (+34) RFE : 175 open ( +0) / 150 closed ( +0) / 325 total ( +0) New / Reopened Patches ______________________ Decimal interaction with __rop__ (2005-03-19) http://python.org/sf/1166602 opened by Facundo Batista Fix _tryorder in webbrowser.py (2005-03-20) http://python.org/sf/1166780 opened by Rodrigo Dias Arruda Senra Fix handling of large octal literals (2005-03-20) CLOSED http://python.org/sf/1166879 opened by Nick Coghlan locale.getdefaultencoding: LANGUAGE not correctly parsed (2005-03-20) http://python.org/sf/1166938 opened by Matthias Klose locale.getdefaultencoding: precedence of LANGUAGE / LANG (2005-03-20) http://python.org/sf/1166948 opened by Matthias Klose locale: 'utf' is not a known encoding (2005-03-20) http://python.org/sf/1166957 opened by Matthias Klose asdl_c.py fix for long lines (2005-03-20) CLOSED http://python.org/sf/1167117 opened by John Ehresman Tar file symbolic link bug fix (2005-03-20) CLOSED http://python.org/sf/1167128 opened by Ellers a fix for doctest crash when it is ran on itself (2005-03-20) CLOSED http://python.org/sf/1167316 opened by Ilya Sandler [AST] Generator expressions (2005-03-22) http://python.org/sf/1167628 opened by Nick Coghlan ast for decorators (2005-03-21) http://python.org/sf/1167709 opened by John Ehresman distutils.dir_utils.mkpath to support unicode (2005-03-21) http://python.org/sf/1167716 opened by John M. Camara Add current dir when running try_run test program (2005-03-22) http://python.org/sf/1168055 opened by Michiel de Hoon tarfile.py: set sizes of non-regular files to zero. (2005-03-22) http://python.org/sf/1168594 opened by Lars Gustäbel Handle ungzipped man pages in rpm builds correctly (2005-03-23) http://python.org/sf/1169193 opened by Robin Green [ast branch] unicode literal fixes (2005-03-25) http://python.org/sf/1170272 opened by John Ehresman Method for cell objects to access contents (2005-03-24) http://python.org/sf/1170323 opened by paul cannon Newline in error output of py_compile.compile (2005-03-26) http://python.org/sf/1171150 opened by paul cannon bug fix for islice() in docs (2005-03-27) CLOSED http://python.org/sf/1171417 opened by Pernici Mario Patch for [ 1170331 ] Error in base64.b32decode (2005-03-27) http://python.org/sf/1171487 opened by logistix Fix compile/link when using Darwin 8 (2005-03-28) CLOSED http://python.org/sf/1171735 opened by Bob Ippolito Fix compile/link when using Darwin 8 (2005-03-28) CLOSED http://python.org/sf/1171767 opened by Bob Ippolito long long support for array module (2005-03-29) http://python.org/sf/1172711 opened by Oren Tirosh Patches Closed ______________ [AST] Fix handling of large octal literals (2005-03-20) http://python.org/sf/1166879 closed by bcannon asdl_c.py fix for long lines (2005-03-20) http://python.org/sf/1167117 closed by bcannon Tar file symbolic link bug fix (2005-03-20) http://python.org/sf/1167128 closed by loewis ast-branch: msvc project sync (2003-05-23) http://python.org/sf/742621 closed by bcannon ast-branch: hacks so asdl_c.py generates compilable code (2005-01-14) http://python.org/sf/1102710 closed by bcannon a fix for doctest crash when it is ran on itself (2005-03-21) http://python.org/sf/1167316 closed by tim_one urllib2 .getheaders attribute error (2005-02-06) http://python.org/sf/1117588 closed by fdrake the quotes page on the Web site links to something broken (2005-03-14) http://python.org/sf/1163314 closed by jjinux add set/getattr interface to tkFont.Font objects (2003-07-01) http://python.org/sf/764221 closed by loewis bug fix for islice() in docs (2005-03-27) http://python.org/sf/1171417 closed by rhettinger Fix compile/link when using Darwin 8 (2005-03-28) http://python.org/sf/1171735 closed by etrepum Fix compile/link when using Darwin 8 (2005-03-28) http://python.org/sf/1171767 closed by etrepum New / Reopened Bugs ___________________ IterableUserDict not in docs (2005-03-19) http://python.org/sf/1166582 opened by Kent Johnson The readline module can cause python to segfault (2005-03-19) http://python.org/sf/1166660 opened by Yariv Ido [ast branch] fatal error when compiling test_bool.py (2005-03-19) CLOSED http://python.org/sf/1166704 opened by John Ehresman [ast branch] fatal error when compiling test_bool.py (2005-03-20) http://python.org/sf/1166714 opened by John Ehresman Fails assertion in winsig.c under VC 8.0 (2005-03-21) http://python.org/sf/1167262 opened by Timothy Fitz Error "exec"ing python code (2005-03-21) http://python.org/sf/1167300 opened by Stefan Seefeld xmlrpclib invalid url (2005-03-21) CLOSED http://python.org/sf/1167329 opened by Mark Doukidis Python 2.4 causes BitTorrent 3.4.2 failure (2005-03-21) http://python.org/sf/1167397 opened by Andrew P. Lentvorski, Jr. Argument genexp corner case (2005-03-21) http://python.org/sf/1167751 opened by John Ehresman Line ending documentation is misleading (2005-03-21) http://python.org/sf/1167922 opened by Paul Moore threading.Thread.join() cannot be interrupted by a Ctrl-C (2005-03-21) http://python.org/sf/1167930 opened by Nicholas Veeser Python 2.5a0 Tutorial errors and observations (2005-03-21) http://python.org/sf/1168135 opened by Michael R Bax Possible windows+python bug (2005-03-22) http://python.org/sf/1168427 opened by holo9 frame.f_exc_type,value,traceback (2005-03-22) http://python.org/sf/1168746 opened by Armin Rigo ftplib.py string index out of range (2005-03-23) http://python.org/sf/1168983 opened by David Carroll PySys_WriteStderr() -> WaitForSingleObject() hangs system (2005-03-23) http://python.org/sf/1169108 opened by stan pinte improvement of ossaudiodev module doc. (2005-03-23) CLOSED http://python.org/sf/1169212 opened by hiower Install fail code 2932 after fail to copy python_icon.exe (2005-03-24) http://python.org/sf/1169633 opened by Wagner modules missing from list of Carbon modules (2005-03-23) http://python.org/sf/1169679 opened by Jesse Weinstein HTTPResponse.getheaders() returns lowercased header names (2005-03-24) http://python.org/sf/1170065 opened by yain BaseCookie does not call value_decode (2005-03-25) http://python.org/sf/1170279 opened by Ryan Lovett zipfile UnicodeDecodeError (2005-03-25) http://python.org/sf/1170311 opened by adam davis Error in base64.b32decode (2005-03-25) http://python.org/sf/1170331 opened by toidinamai doc speaks of extensions option while it's *called* ext_modu (2005-03-25) http://python.org/sf/1170422 opened by Jürgen A. Erhard why should URL be required for all packages (2005-03-25) http://python.org/sf/1170424 opened by Jürgen A. Erhard gc module docu (2005-03-25) CLOSED http://python.org/sf/1170460 opened by Martin Renold weakref.proxy incorrect behaviour (2005-03-26) http://python.org/sf/1170766 opened by Alexander Kozlovsky Thread.join() fails to release Lock on KeyboardInterrupt (2005-03-26) http://python.org/sf/1171023 reopened by phansen Thread.join() fails to release Lock on KeyboardInterrupt (2005-03-26) http://python.org/sf/1171023 opened by Peter Hansen Error in code example in main tutorial, section 9.3.4 (2005-03-28) CLOSED http://python.org/sf/1171819 opened by Niek error in documentation for splitting empty string (2005-03-28) http://python.org/sf/1171994 opened by Wai Yip Tung BaseCookie does not call value_decode (2005-03-28) http://python.org/sf/1172011 opened by Ryan Lovett "cmp" should be "key" in sort doc (2005-03-29) CLOSED http://python.org/sf/1172554 opened by Keith Briggs "cmp" should be "key" in sort doc (2005-03-29) http://python.org/sf/1172581 opened by Keith Briggs dumbdbm hoses index on load failure (2005-03-29) http://python.org/sf/1172763 opened by currivan doctest.script_from_examples() result sometimes un-exec-able (2005-03-29) http://python.org/sf/1172785 opened by Jonathan E. Guyer Bugs Closed ___________ subprocess.Popen with copious output hangs (2005-03-13) http://python.org/sf/1162428 closed by astrand subprocess pipe fails under Emacs (2005-03-15) http://python.org/sf/1163759 closed by astrand KeyboardInterrupt causes segmentation fault with threads (2005-03-18) http://python.org/sf/1165761 closed by anthonybaxter super(...).__new__( ... ) behaves "unexpected" (2005-03-16) http://python.org/sf/1164631 closed by brenck Optik OptionParse important undocumented option (2005-01-10) http://python.org/sf/1099324 closed by gward optparse needs reference documentation (2004-07-19) http://python.org/sf/993601 closed by gward optparse docs missing section on Extending (2004-12-16) http://python.org/sf/1086675 closed by gward [ast branch] fatal error when compiling test_bool.py (2005-03-19) http://python.org/sf/1166704 closed by bcannon After fork in subthread, signals are blocked (2003-12-03) http://python.org/sf/853411 closed by mwh xmlrpclib invalid url (2005-03-21) http://python.org/sf/1167329 closed by montanaro BasHTTPServer IE Mac 5.1 size problem (2003-09-25) http://python.org/sf/812340 closed by facundobatista Section 11.20: xmlrpclib Details (2003-08-19) http://python.org/sf/791067 closed by facundobatista socket.inet_aton on 64bit platform (2003-07-07) http://python.org/sf/767150 closed by facundobatista xml.sax second time file loading problem (2002-09-09) http://python.org/sf/606692 closed by facundobatista Error using Tkinter embeded in C++ (2003-03-06) http://python.org/sf/699068 closed by facundobatista urllib ftp broken if Win32 proxy (2002-03-19) http://python.org/sf/532007 closed by facundobatista missing sequence tests - pull from deque (2005-03-18) http://python.org/sf/1166274 closed by doerwalter Unable to Install Python 2.4.1rc1 on windows XP SP2 (2005-03-14) http://python.org/sf/1162677 closed by loewis segfault when running smtplib example (2004-08-04) http://python.org/sf/1003195 closed by facundobatista sgmllib incorrectly handles entities in attributes (2003-07-29) http://python.org/sf/779388 closed by facundobatista Unix popen does not return exit status (2002-09-12) http://python.org/sf/608635 closed by facundobatista Implied __init__.py not copied (2002-09-11) http://python.org/sf/608033 closed by facundobatista pydoc -g dumps core on Solaris 2.8 (2002-08-30) http://python.org/sf/602627 closed by facundobatista makesetup fails: long Setup.local lines (2002-08-05) http://python.org/sf/591287 closed by facundobatista os.tmpfile() can fail on win32 (2002-08-05) http://python.org/sf/591104 closed by facundobatista pthread_exit missing in thread_pthread.h (2002-07-09) http://python.org/sf/579116 closed by facundobatista cgi.py broken with xmlrpclib on Python 2 (2002-06-15) http://python.org/sf/569316 closed by facundobatista Popen exectuion blocking w/threads (2002-06-07) http://python.org/sf/566037 closed by facundobatista fpectl build on solaris: -lsunmath (2002-03-15) http://python.org/sf/530163 closed by facundobatista small change in ossaudiodev module doc. (2005-03-23) http://python.org/sf/1169212 closed by gward Solaris and Python/pykota (2005-03-04) http://python.org/sf/1156441 closed by loewis gc module docu (2005-03-25) http://python.org/sf/1170460 closed by loewis Thread.join() fails to release Lock on KeyboardInterrupt (2005-03-26) http://python.org/sf/1171023 closed by bcannon Error in code example in main tutorial, section 9.3.4 (2005-03-28) http://python.org/sf/1171819 closed by loewis "cmp" should be "key" in sort doc (2005-03-29) http://python.org/sf/1172554 closed by rhettinger

7 8

New PyPI broken package editing
by Walter Dörwald March 31, 2005

March 31, 2005

I've uploaded a new package to the new PyPI. Editing this new packages gives me a unicode error. The URL is http://www.python.org/pypi?:action=submit_form&name=ll-ansistyle&version=0.… The error I get is the following: --- Error... There's been a problem with your request exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 92: ordinal not in range(128) ---- I've used the distutils from current CVS and have author=u"Walter Dörwald" in my setup.py Bye, Walter Dörwald

3 11

BRANCH UNFROZEN
by Anthony Baxter March 30, 2005

March 30, 2005

Ok, 2.4.1 seems good, so the release24-maint branch is unfrozen for bugfixes. We'll aim for a 2.4.2 around August/September, assuming no critical bugs come up before then... -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0

RE: [Python-Dev] @decoration of classes
by Michael Chermside March 30, 2005

March 30, 2005

Josiah Carlson writes: [... stuff about reST and TeX ...] > While I have not used it often, I have done the equivalent of decorating > classes; it is as natural (though perhaps not quite as useful initially) > as decorating functions, [... stuff about ice cream and sprinkles ...] Hmm... the only bit that I found particularly interesting there was the bit where you mention that you've used class decorators (without the syntax) before. What did you use them for? After all, the current state of things is "don't bother implementing class decorators because there is no compelling use case". If you've got some sample use cases, what were they? For my own part, I observe the following. Because a function decorator acts after the function object is created, there are limits to what it can do to the function. It can add some markup (eg: set properties or doc strings). It can "hook" either before or after the function is called. Or it can "veto" the function call and do something else instead. In the case of function calls, these are pretty much the interesting things you would want to do. Similarly, because a class decorator acts after the class is created there are limits on what it can do. It can modify the class object (replacing methods and such). It can add markup. It can replace the class with another (perhaps a proxy or some such). But most of these are things which are more easily done by a metaclass... and all of them *can* be done by metaclasses. The only noticable advantage that I see to class decorators over metaclasses is that there's a more straightforward way to combine them. And I'm not sure that combining metaclasses (or class decorators) is something I want to encourage. So I'm inclined to use different tools for modifying functions and modifying classes because the ways you want to modify them are different, and decorators are "tuned" to what people normally want to do with functions (like simple wrapping) while metaclasses are "tuned" to what people normally want to do with classes (like support for inheritance. But a few *good* use cases would change my mind. -- Michael Chermside

6 5

RE: [Python-Dev] @decoration of classes
by Delaney, Timothy C (Timothy) March 30, 2005

March 30, 2005

Nick Coghlan wrote: > # A decorator that does not alter its argument > def register(callable): > # Register the callable somewhere > ... > return callable > > # Decorated factory function > @register > def factory(): > pass > > # Post-decorated class > class factory: > pass > register(factory) > > # Metaclass > class RegisteredType(type): > def __init__(self, name, bases, dict): > super(self, RegisteredType).__init__(self, name, bases, dict) > register(self) > > class factory: > __metaclass__ = RegisteredType > > # Class decorator (not currently possible) > @register > class factory: > pass class factory: @register def __call__(self): pass Just as an additional data point - obviously not applicable in all cases. Tim Delaney

2 1

Re: RELEASED Python 2.4.1 (final)
by Skip Montanaro March 30, 2005

March 30, 2005

Terry> The page http://www.python.org/download/ needs to be added to the Terry> list of things updated with a new release. Terry, I'll let others take care of that list (I don't know where it's kept). In the meantime, I updated the download page to reference 2.4.1. Skip

1 0

Python-Dev

March 2005