Mailman 3 September 2004 - Python-checkins

python/nondist/peps pep-0333.txt,1.6,1.7
by pje＠users.sourceforge.net Sept. 1, 2004

Sept. 1, 2004

Update of /cvsroot/python/python/nondist/peps In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2121 Modified Files: pep-0333.txt Log Message: Fix some typos, and clean up/clarify language regarding iterables so that Alan's Jython-based server will be compatible with the "letter of the law" of the spec. Index: pep-0333.txt =================================================================== RCS file: /cvsroot/python/python/nondist/peps/pep-0333.txt,v retrieving revision 1.6 retrieving revision 1.7 diff -u -d -r1.6 -r1.7 --- pep-0333.txt 1 Sep 2004 13:44:07 -0000 1.6 +++ pep-0333.txt 1 Sep 2004 20:35:42 -0000 1.7 @@ -773,11 +773,18 @@ more complex: * You may not return a file object and expect it to work as an iterable, - since before Python 2.2, files were not iterable. + since before Python 2.2, files were not iterable. (Some servers + may loosen this guideline by checking for ``types.FileType``, but + this is an optional, server-specific extension. If you want your + application code to be used with pre-2.2 Pythons such as Jython, + you should *not* return a file object; use a pre-2.2 iterable + or a sequence instead.) -* If you return an iterable, it **must** implement the pre-2.2 iterator - protocol. That is, provide a ``__getitem__`` method that accepts - an integer key, and raises ``IndexError`` when exhausted. +* If you return a custom iterable, it **must** implement the pre-2.2 + iterator protocol. That is, provide a ``__getitem__`` method that + accepts an integer key, and raises ``IndexError`` when exhausted. + (Note that built-in sequence types are also acceptable, since they + also implement this protocol.) Finally, middleware that wishes to support pre-2.2 versions of Python, and iterates over application return values or itself returns an @@ -863,7 +870,7 @@ ``fileno`` attribute if it is anything other than a method returning an **operating system file descriptor**. "File-like" objects that do not possess a true operating system file descriptor number -are expressly. Servers running on platforms where file +are expressly forbidden. Servers running on platforms where file descriptors do not exist, or where there is no meaningful API for accelerating transmission from a file descriptor should ignore the ``fileno`` attribute.

1 0

python/dist/src/PCbuild BUILDno.txt, 1.60, 1.61 pythoncore.vcproj, 1.19, 1.20
by loewis＠users.sourceforge.net Sept. 1, 2004

Sept. 1, 2004

Update of /cvsroot/python/python/dist/src/PCbuild In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv8741 Modified Files: BUILDno.txt pythoncore.vcproj Log Message: Update buildno for 2.4a3 Index: BUILDno.txt =================================================================== RCS file: /cvsroot/python/python/dist/src/PCbuild/BUILDno.txt,v retrieving revision 1.60 retrieving revision 1.61 diff -u -d -r1.60 -r1.61 --- BUILDno.txt 4 Aug 2004 13:42:43 -0000 1.60 +++ BUILDno.txt 1 Sep 2004 18:29:25 -0000 1.61 @@ -33,6 +33,8 @@ Windows Python BUILD numbers ---------------------------- + 56 2.4.0a3 + 2-Sep-2004 55 2.4.0a2 4-Aug-2004 54 2.4.0a1 Index: pythoncore.vcproj =================================================================== RCS file: /cvsroot/python/python/dist/src/PCbuild/pythoncore.vcproj,v retrieving revision 1.19 retrieving revision 1.20 diff -u -d -r1.19 -r1.20 --- pythoncore.vcproj 31 Aug 2004 14:29:12 -0000 1.19 +++ pythoncore.vcproj 1 Sep 2004 18:29:25 -0000 1.20 @@ -1382,7 +1382,7 @@ Name="VCCLCompilerTool" Optimization="2" AdditionalIncludeDirectories="" - PreprocessorDefinitions="BUILD=55"/> + PreprocessorDefinitions="BUILD=56"/> </FileConfiguration> <FileConfiguration Name="Debug|Win32"> @@ -1390,7 +1390,7 @@ Name="VCCLCompilerTool" Optimization="0" AdditionalIncludeDirectories="" - PreprocessorDefinitions="BUILD=55"/> + PreprocessorDefinitions="BUILD=56"/> </FileConfiguration> <FileConfiguration Name="ReleaseItanium|Win32"> @@ -1398,7 +1398,7 @@ Name="VCCLCompilerTool" Optimization="2" AdditionalIncludeDirectories="" - PreprocessorDefinitions="BUILD=55"/> + PreprocessorDefinitions="BUILD=56"/> </FileConfiguration> </File> <File

1 0

python/nondist/peps pep-0000.txt,1.287,1.288
by anthonybaxter＠users.sourceforge.net Sept. 1, 2004

Sept. 1, 2004

Update of /cvsroot/python/python/nondist/peps In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv14628 Modified Files: pep-0000.txt Log Message: pep318 is accepted Index: pep-0000.txt =================================================================== RCS file: /cvsroot/python/python/nondist/peps/pep-0000.txt,v retrieving revision 1.287 retrieving revision 1.288 diff -u -d -r1.287 -r1.288 --- pep-0000.txt 27 Aug 2004 20:28:57 -0000 1.287 +++ pep-0000.txt 1 Sep 2004 16:18:20 -0000 1.288 @@ -66,6 +66,7 @@ S 252 Making Types Look More Like Classes GvR S 253 Subtyping Built-in Types GvR SA 309 Partial Function Application Harris + SA 318 Decorators for Functions and Methods Smith, et al SA 328 Imports: Multi-Line and Absolute/Relative Aahz Open PEPs (under consideration) @@ -112,7 +113,6 @@ S 313 Adding Roman Numeral Literals to Python Meyer S 314 Metadata for Python Software Packages v1.1 Kuchling S 315 Enhanced While Loop Carroll - S 318 Decorators for Functions and Methods Smith, et al S 319 Python Synchronize/Asynchronize Block Pelletier S 321 Date/Time Parsing and Formatting Kuchling S 323 Copyable Iterators Martelli @@ -346,7 +346,7 @@ S 315 Enhanced While Loop Carroll SD 316 Programming by Contract for Python Way SR 317 Eliminate Implicit Exception Instantiation Taschuk - S 318 Decorators for Functions, Methods & Classes Smith, et al + SA 318 Decorators for Functions and Methods Smith, et al S 319 Python Synchronize/Asynchronize Block Pelletier I 320 Python 2.4 Release Schedule Warsaw S 321 Date/Time Parsing and Formatting Kuchling

1 0

python/nondist/peps pep-0318.txt,1.30,1.31
by anthonybaxter＠users.sourceforge.net Sept. 1, 2004

Sept. 1, 2004

Update of /cvsroot/python/python/nondist/peps In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31156 Modified Files: pep-0318.txt Log Message: ding dong the witch is dead. or rather, the decorator discussion is. updating the pep. (I'm not sure if the "Community Concensus" section should be trimmed down radically now - it's a lot of words for a rejected form, and the case for the form is still available on the web and in the mailing list archives... opinions, anyone?) Index: pep-0318.txt =================================================================== RCS file: /cvsroot/python/python/nondist/peps/pep-0318.txt,v retrieving revision 1.30 retrieving revision 1.31 diff -u -d -r1.30 -r1.31 --- pep-0318.txt 30 Aug 2004 16:00:06 -0000 1.30 +++ pep-0318.txt 1 Sep 2004 15:02:22 -0000 1.31 @@ -8,49 +8,49 @@ Content-Type: text/x-rst Created: 05-Jun-2003 Python-Version: 2.4 -Post-History: 09-Jun-2003, 10-Jun-2003, 27-Feb-2004, 23-Mar-2004, 30-Aug-2004 +Post-History: 09-Jun-2003, 10-Jun-2003, 27-Feb-2004, 23-Mar-2004, 30-Aug-2004, +2-Sep-2004 WarningWarningWarning ===================== -The final decision on the syntax for 2.4a3 is not yet made. This will -be done before 2.4a3, and this document will be updated to match. -Note also that this document does not attempt to cover the huge number -of potential alternative syntaxes, nor is it an attempt to -exhaustively list all the positives and negatives of each form. +This document is meant to describe the decorator syntax and the +process that resulted in the decisions that were made. It does not +attempt to cover the huge number of potential alternative syntaxes, +nor is it an attempt to exhaustively list all the positives and +negatives of each form. Abstract ======== -The current method for transforming functions and methods (for -instance, declaring them as a class or static method) is awkward and -can lead to code that is difficult to understand. Ideally, these -transformations should be made at the same point in the code where the -declaration itself is made. This PEP introduces new syntax for -transformations of a function or method declaration. +The current method for transforming functions and methods (for instance, +declaring them as a class or static method) is awkward and can lead to +code that is difficult to understand. Ideally, these transformations +should be made at the same point in the code where the declaration +itself is made. This PEP introduces new syntax for transformations of a +function or method declaration. Motivation ========== -The current method of applying a transformation to a function or -method places the actual translation after the function body. For -large functions this separates a key component of the function's -behavior from the definition of the rest of the function's external -interface. For example:: +The current method of applying a transformation to a function or method +places the actual translation after the function body. For large +functions this separates a key component of the function's behavior from +the definition of the rest of the function's external interface. For +example:: def foo(self): perform method operation foo = classmethod(foo) This becomes less readable with longer methods. It also seems less -than pythonic to name the function three times for what is -conceptually a single declaration. A solution to this problem is to -move the transformation of the method closer to the method's own -declaration. While the new syntax is not yet final, the intent is to -replace:: +than pythonic to name the function three times for what is conceptually +a single declaration. A solution to this problem is to move the +transformation of the method closer to the method's own declaration. +While the new syntax is not yet final, the intent is to replace:: def foo(cls): pass @@ -65,41 +65,39 @@ def foo(cls): pass -Modifying classes in this fashion is also possible, though the -benefits are not as immediately apparent. Almost certainly, anything -which could be done with class decorators could be done using -metaclasses, but using metaclasses is sufficiently obscure that there -is some attraction to having an easier way to make simple -modifications to classes. For Python 2.4, only function/method -decorators are being added. +Modifying classes in this fashion is also possible, though the benefits +are not as immediately apparent. Almost certainly, anything which could +be done with class decorators could be done using metaclasses, but +using metaclasses is sufficiently obscure that there is some attraction +to having an easier way to make simple modifications to classes. For +Python 2.4, only function/method decorators are being added. Why Is This So Hard? -------------------- -Two decorators (``classmethod()`` and ``staticmethod()``) have -been available in Python since version 2.2. It's been assumed since +Two decorators (``classmethod()`` and ``staticmethod()``) have been +available in Python since version 2.2. It's been assumed since approximately that time that some syntactic support for them would eventually be added to the language. Given this assumption, one might -wonder why it's been so difficult to arrive at a consensus. -Discussions have raged off-and-on at times in both comp.lang.python -and the python-dev mailing list about how best to implement function -decorators. There is no one clear reason why this should be so, but a -few problems seem to be most problematic. +wonder why it's been so difficult to arrive at a consensus. Discussions +have raged off-and-on at times in both comp.lang.python and the +python-dev mailing list about how best to implement function decorators. +There is no one clear reason why this should be so, but a few problems +seem to be most problematic. * Disagreement about where the "declaration of intent" belongs. - Almost everyone agrees that decorating/transforming a function at - the end of its definition is suboptimal. Beyond that there seems to - be no clear consensus where to place this information. + Almost everyone agrees that decorating/transforming a function at the + end of its definition is suboptimal. Beyond that there seems to be no + clear consensus where to place this information. * Syntactic constraints. Python is a syntactically simple language with fairly strong constraints on what can and can't be done without "messing things up" (both visually and with regards to the language parser). There's no obvious way to structure this information so that people new to the concept will think, "Oh yeah, I know what - you're doing." The best that seems possible is to keep new users - from creating a wildly incorrect mental model of what the syntax - means. + you're doing." The best that seems possible is to keep new users from + creating a wildly incorrect mental model of what the syntax means. * Overall unfamiliarity with the concept. For people who have a passing acquaintance with algebra (or even basic arithmetic) or have @@ -109,7 +107,7 @@ strong preexisting meme that captures the concept. * Syntax discussions in general appear to cause more contention than - almost anything else. Readers are pointed to the ternary operator + almost anything else. Readers are pointed to the ternary operator discussions that were associated with PEP 308 for another example of this. @@ -117,12 +115,12 @@ Background ========== -There is general agreement that syntactic support is desirable to the -current state of affairs. Guido mentioned `syntactic support for -decorators`_ in his DevDay keynote presentation at the `10th Python -Conference`_, though `he later said`_ it was only one of several -extensions he proposed there "semi-jokingly". `Michael Hudson raised -the topic`_ on ``python-dev`` shortly after the conference, +There is general agreement that syntactic support is desirable to +the current state of affairs. Guido mentioned `syntactic support +for decorators`_ in his DevDay keynote presentation at the `10th +Python Conference`_, though `he later said`_ it was only one of +several extensions he proposed there "semi-jokingly". `Michael Hudson +raised the topic`_ on ``python-dev`` shortly after the conference, attributing the initial bracketed syntax to an earlier proposal on ``comp.lang.python`` by `Gareth McCaughan`_. @@ -138,18 +136,21 @@ http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=slrna40k88… Class decorations seem like an obvious next step because class -definition and function definition are syntactically similar. +definition and function definition are syntactically similar, +however Guido remains unconvinced, and class decorators will almost +certainly not be in Python 2.4. -The discussion continued on and off on python-dev from February 2002 -through July 2004. Hundreds and hundreds of posts were made, with -people proposing many possible syntax variations. Guido took a list -of proposals to `EuroPython 2004`_, where a discussion took place. -Subsequent to this, he decided that for 2.4a2 we'd have the -`Java-style`_ @decorator syntax. Barry Warsaw named this the -'pie-decorator' syntax, in honor of the Pie-thon Parrot shootout which -was announced about the same time as the decorator syntax, and because -the @ looks a little like a pie. Guido `outlined his case`_ on -Python-dev, including `this piece`_ on the various rejected forms. +The discussion continued on and off on python-dev from February +2002 through July 2004. Hundreds and hundreds of posts were made, +with people proposing many possible syntax variations. Guido took +a list of proposals to `EuroPython 2004`_, where a discussion took +place. Subsequent to this, he decided that we'd have the `Java-style`_ +@decorator syntax, and this appeared for the first time in 2.4a2. +Barry Warsaw named this the 'pie-decorator' syntax, in honor of the +Pie-thon Parrot shootout which was occured around the same time as +the decorator syntax, and because the @ looks a little like a pie. +Guido `outlined his case`_ on Python-dev, including `this piece`_ +on some of the (many) rejected forms. .. _EuroPython 2004: http://www.python.org/doc/essays/ppt/euro2004/euro2004.pdf @@ -199,8 +200,8 @@ frequently * not make it more difficult to scan through code quickly. It should - still be easy to search for all definitions, a particular - definition, or the arguments that a function accepts + still be easy to search for all definitions, a particular definition, + or the arguments that a function accepts * not needlessly complicate secondary support tools such as language-sensitive editors and other "`toy parser tools out @@ -208,8 +209,8 @@ * allow future compilers to optimize for decorators. With the hope of a JIT compiler for Python coming into existence at some point this - tends to require the syntax for decorators to come before the - function definition + tends to require the syntax for decorators to come before the function + definition * move from the end of the function, where it's currently hidden, to the front where it is more `in your face`_ @@ -246,8 +247,8 @@ func = dec2(dec1(func)) without the intermediate assignment to the variable ``func``. The -decorators are near the function declaration. The @ sign makes it -clear that something new is going on here. +decorators are near the function declaration. The @ sign makes it clear +that something new is going on here. The decorator statement is limited in what it can accept -- arbitrary expressions will not work. Guido preferred this because of a `gut @@ -278,8 +279,8 @@ The first syntax point is the location of the decorators. For the following examples, we use the @syntax used in 2.4a2. -Decorators before the def statement are the first alternative, -and the syntax used in 2.4a2:: +Decorators before the def statement are the first alternative, and the +syntax used in 2.4a2:: @classmethod def foo(arg1,arg2): @@ -290,36 +291,36 @@ def bar(low,high): pass -There have been a number of objections raised to this location -- -the primary one is that it's the first real Python case where a -line of code has a result on a following line. The syntax that -will be in 2.4a3 will also require one decorator per line (in a2, -multiple decorators can be specified on the same line). +There have been a number of objections raised to this location -- the +primary one is that it's the first real Python case where a line of code +has a result on a following line. The syntax available for in 2.4a3 +requires one decorator per line (in a2, multiple decorators could be +specified on the same line). People also complained that the syntax got unworldly quickly when multiple decorators were used. The point was made, though, that the chances of a large number of decorators being used on a single function were small and thus this was not a large worry. -Some of the advantages of this form are that the decorators live -outside the method body -- they are obviously executed at the time -the function is defined. +Some of the advantages of this form are that the decorators live outside +the method body -- they are obviously executed at the time the function +is defined. -Another advantage is that being prefix to the function definition fit the -idea of knowing about a change to the semantics of the code before the -code itself, thus knowing how to interpret the code's semantics +Another advantage is that being prefix to the function definition fit +the idea of knowing about a change to the semantics of the code before +the code itself, thus knowing how to interpret the code's semantics properly without having to go back and change your initial perceptions if the syntax did not come before the function definition. Guido decided `he preferred`_ having the decorators on the line before -the 'def', because it was felt that a long argument list would mean -that the decorators would be 'hidden' +the 'def', because it was felt that a long argument list would mean that +the decorators would be 'hidden' .. _he preferred: http://mail.python.org/pipermail/python-dev/2004-March/043756.html -The second form is the decorators between the def and the function -name, or the function name and the argument list:: +The second form is the decorators between the def and the function name, +or the function name and the argument list:: def @classmethod foo(arg1,arg2): pass @@ -336,12 +337,12 @@ There are a couple of objections to this form. The first is that it breaks easily 'greppability' of the source -- you can no longer search for 'def foo(' and find the definition of the function. The second, -more serious, objection is that in the case of multiple decorators, -the syntax would be extremely unwieldy. +more serious, objection is that in the case of multiple decorators, the +syntax would be extremely unwieldy. -The next form, which has had a number of strong proponents, is to -have the decorators between the argument list and the trailing ``:`` -in the 'def' line:: +The next form, which has had a number of strong proponents, is to have +the decorators between the argument list and the trailing ``:`` in the +'def' line:: def foo(arg1,arg2) @classmethod: pass @@ -349,8 +350,8 @@ def bar(low,high) @accepts(int,int),@returns(float): pass -Guido `summarized the arguments`_ against this form (many of which -also apply to the previous form) as: +Guido `summarized the arguments`_ against this form (many of which also +apply to the previous form) as: - it hides crucial information (e.g. that it is a static method) after the signature, where it is easily missed @@ -364,9 +365,8 @@ .. _summarized the arguments: http://mail.python.org/pipermail/python-dev/2004-August/047112.html -The next form is that the decorator syntax go inside the method -body at the start, in the same place that docstrings currently -live: +The next form is that the decorator syntax go inside the method body at +the start, in the same place that docstrings currently live: def foo(arg1,arg2): @classmethod @@ -377,16 +377,16 @@ @returns(float) pass -The primary objection to this form is that it requires "peeking -inside" the method body to determine the decorators. In addition, -even though the code is inside the method body, it is not executed -when the method is run. Guido felt that docstrings were not a good -counter-example, and that it was quite possible that a 'docstring' -decorator could help move the docstring to outside the function body. +The primary objection to this form is that it requires "peeking inside" +the method body to determine the decorators. In addition, even though +the code is inside the method body, it is not executed when the method +is run. Guido felt that docstrings were not a good counter-example, and +that it was quite possible that a 'docstring' decorator could help move +the docstring to outside the function body. -The final form is a new block that encloses the method's code. For -this example, we'll use a 'decorate' keyword, as it makes no sense -with the @syntax. :: +The final form is a new block that encloses the method's code. For this +example, we'll use a 'decorate' keyword, as it makes no sense with the +@syntax. :: decorate: classmethod @@ -400,8 +400,8 @@ pass This form would result in inconsistent indentation for decorated and -undecorated methods. In addition, a decorated method's body would -start three indent levels in. +undecorated methods. In addition, a decorated method's body would start +three indent levels in. Syntax forms @@ -420,7 +420,7 @@ The major objections against this syntax are that the @ symbol is not currently used in Python (and is used in both IPython and Leo), - and that the @ symbol is not meaningful. Another objection is that + and that the @ symbol is not meaningful. Another objection is that this "wastes" a currently unused character (from a limited set) on something that is not perceived as a major use. @@ -437,8 +437,8 @@ This is a variant on the @decorator syntax -- it has the advantage that it does not break IPython and Leo. Its major disadvantage - compared to the @syntax is that the | symbol looks like both a - capital I and a lowercase l. + compared to the @syntax is that the | symbol looks like both a capital + I and a lowercase l. * list syntax:: @@ -474,28 +474,29 @@ * ``decorate()`` - The ``decorate()`` proposal was that no new syntax be implemented -- - instead a magic function that used introspection to manipulate the - following function. Both Jp Calderone and Philip Eby produced + The ``decorate()`` proposal was that no new syntax be implemented + -- instead a magic function that used introspection to manipulate + the following function. Both Jp Calderone and Philip Eby produced implementations of functions that did this. Guido was pretty firmly against this -- with no new syntax, the magicness of a function like this is extremely high: - Using functions with "action-at-a-distance" through - sys.settraceback may be okay for an obscure feature that can't be - had any other way yet doesn't merit changes to the language, but - that's not the situation for decorators. The widely held view - here is that decorators need to be added as a syntactic feature to - avoid the problems with the postfix notation used in 2.2 and 2.3. - Decorators are slated to be an important new language feature and - their design needs to be forward-looking, not constrained by what - can be implemented in 2.3. + Using functions with "action-at-a-distance" through sys.settraceback + may be okay for an obscure feature that can't be had any other + way yet doesn't merit changes to the language, but that's not + the situation for decorators. The widely held view here is that + decorators need to be added as a syntactic feature to avoid the + problems with the postfix notation used in 2.2 and 2.3. Decorators + are slated to be an important new language feature and their + design needs to be forward-looking, not constrained by what can be + implemented in 2.3. * _`new keyword (and block)` - This idea was the consensus alternate from comp.lang.python. Robert - Brewer wrote up a detailed `J2 proposal`_ document outlining the - arguments in favor of this. The issues with this form are: + This idea was the consensus alternate from comp.lang.python (more + on this in `Community Consensus`_ below.) Robert Brewer wrote up a + detailed `J2 proposal`_ document outlining the arguments in favor of + this form. The initial issues with this form are: - It requires a new keyword, and therefore a ``from __future__ import decorators`` statement. @@ -508,12 +509,39 @@ code block, but isn't. Attempts to use statements in this block will cause a syntax error, which may confuse users. - See `Community Consensus`_ below. + A few days later, Guido `rejected the proposal`_ on two main grounds, + firstly: + + ... the syntactic form of an indented block strongly + suggests that its contents should be a sequence of statements, but + in fact it is not -- only expressions are allowed, and there is an + implicit "collecting" of these expressions going on until they can + be applied to the subsequent function definition. ... + + and secondly: + + ... the keyword starting the line that heads a block + draws a lot of attention to it. This is true for "if", "while", + "for", "try", "def" and "class". But the "using" keyword (or any + other keyword in its place) doesn't deserve that attention; the + emphasis should be on the decorator or decorators inside the suite, + since those are the important modifiers to the function definition + that follows. ... + + Readers are invited to read `the full response`_. .. _J2 proposal: http://www.aminus.org/rbre/python/pydec.html -There are plenty of other variants and proposals on `the wiki page`_. + .. _rejected the proposal: + http://mail.python.org/pipermail/python-dev/2004-September/048518.html + + .. _the full response: + http://mail.python.org/pipermail/python-dev/2004-September/048518.html + +* Other forms + + There are plenty of other variants and proposals on `the wiki page`_. .. _the wiki page: http://www.python.org/moin/PythonDecorators @@ -522,18 +550,18 @@ Why @? ------ -There is some history in Java using @ initially as a marker in -`Javadoc comments`_ and later in Java 1.5 for `annotations`_, which -are similar to Python decorators. The fact that @ was previously -unused as a token in Python also means it's clear there is no -possibility of such code being parsed by an earlier version of Python, -leading to possibly subtle semantic bugs. It also means that ambiguity -of what is a decorator and what isn't is removed. of That said, @ is -still a fairly arbitrary choice. Some have suggested using | instead. +There is some history in Java using @ initially as a marker in `Javadoc +comments`_ and later in Java 1.5 for `annotations`_, which are similar +to Python decorators. The fact that @ was previously unused as a token +in Python also means it's clear there is no possibility of such code +being parsed by an earlier version of Python, leading to possibly subtle +semantic bugs. It also means that ambiguity of what is a decorator +and what isn't is removed. of That said, @ is still a fairly arbitrary +choice. Some have suggested using | instead. For syntax options which use a list-like syntax (no matter where it appears) to specify the decorators a few alternatives were proposed: -``[|...|]``, ``*[...]*``, and ``<...>``. +``[|...|]``, ``*[...]*``, and ``<...>``. .. _Javadoc comments: http://java.sun.com/j2se/javadoc/writingdoccomments/ @@ -545,8 +573,8 @@ =============================== Guido asked for a volunteer to implement his preferred syntax, and Mark -Russell stepped up and posted a `patch`_ to SF. The syntax accepted -for 2.4a2 is:: +Russell stepped up and posted a `patch`_ to SF. This new syntax was +available in 2.4a2. :: @dec2 @dec1 @@ -561,6 +589,10 @@ though without the intermediate creation of a variable named ``func``. +The version implemented in 2.4a2 allowed multiple ``@decorator`` clauses +on a single line. In 2.4a3, this was tightened up to only allowing one +decorator per line. + A `previous patch`_ from Michael Hudson which implements the list-after-def syntax is also still kicking around. @@ -572,19 +604,44 @@ could come up with a community consensus, a decent proposal, and an implementation. After an amazing number of posts, collecting a vast number of alternatives in the `Python wiki`_, a community consensus -emerged (below). As at time of writing, we're waiting for Guido's -decision. +emerged (below). Guido `subsequently rejected`_ this alternate form, +but added: + + In Python 2.4a3 (to be released this Thursday), everything remains + as currently in CVS. For 2.4b1, I will consider a change of @ to + some other single character, even though I think that @ has the + advantage of being the same character used by a similar feature + in Java. It's been argued that it's not quite the same, since @ + in Java is used for attributes that don't change semantics. But + Python's dynamic nature makes that its syntactic elements never mean + quite the same thing as similar constructs in other languages, and + there is definitely significant overlap. Regarding the impact on + 3rd party tools: IPython's author doesn't think there's going to be + much impact; Leo's author has said that Leo will survive (although + it will cause him and his users some transitional pain). I actually + expect that picking a character that's already used elsewhere in + Python's syntax might be harder for external tools to adapt to, + since parsing will have to be more subtle in that case. But I'm + frankly undecided, so there's some wiggle room here. I don't want + to consider further syntactic alternatives at this point: the buck + has to stop at some point, everyone has had their say, and the show + must go on. .. _Python wiki: http://www.python.org/moin/PythonDecorators +.. _subsequently rejected: + http://mail.python.org/pipermail/python-dev/2004-September/048518.html Community Consensus ------------------- -The consensus that emerged was for the proposed J2 syntax: the new -keyword ``using`` prefixing a block of decorators before the ``def`` -statement. For example:: +[editor's note: should this section be removed now?] + +The consensus that emerged on comp.lang.python was the proposed J2 +syntax (the "J2" was how it was referenced on the PythonDecorators wiki +page): the new keyword ``using`` prefixing a block of decorators before +the ``def`` statement. For example:: using: classmethod @@ -613,15 +670,21 @@ .. _a patch: http://www.python.org/sf/1013835 +As noted previously, Guido rejected this form, outlining his problems +with it in `a message`_ to python-dev and comp.lang.python. + +.. _a message: + http://mail.python.org/pipermail/python-dev/2004-September/048518.html + Examples ======== Much of the discussion on ``comp.lang.python`` and the ``python-dev`` mailing list focuses on the use of decorators as a cleaner way to use -the ``staticmethod()`` and ``classmethod()`` builtins. This -capability is much more powerful than that. This section presents -some examples of use. +the ``staticmethod()`` and ``classmethod()`` builtins. This capability +is much more powerful than that. This section presents some examples of +use. 1. Define a function to be executed at exit. Note that the function isn't actually "wrapped" in the usual sense. :: @@ -639,9 +702,8 @@ is for example purposes only. 2. Define a class with a singleton instance. Note that once the class - disappears enterprising programmers would have to be more creative - to create more instances. (From Shane Hathaway on ``python-dev``.) - :: + disappears enterprising programmers would have to be more creative to + create more instances. (From Shane Hathaway on ``python-dev``.) :: def singleton(cls): instances = {} @@ -734,14 +796,17 @@ =========== 1. It's not yet certain that class decorators will be incorporated - into the language at this point. Guido expressed skepticism about + into the language at a future point. Guido expressed skepticism about the concept, but various people have made some `strong arguments`_ (search for ``PEP 318 -- posting draft``) on their behalf in - ``python-dev``. + ``python-dev``. It's exceedingly unlikely that class decorators + will be in Python 2.4. .. _strong arguments: http://mail.python.org/pipermail/python-dev/2004-March/thread.html +2. The choice of the ``@`` character will be re-examined before + Python 2.4b1. Copyright =========

3 2

python/nondist/peps pep-0318.txt,1.31,1.32
by akuchling＠users.sourceforge.net Sept. 1, 2004

Sept. 1, 2004

Update of /cvsroot/python/python/nondist/peps In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv8465 Modified Files: pep-0318.txt Log Message: Minor polishing of words Index: pep-0318.txt =================================================================== RCS file: /cvsroot/python/python/nondist/peps/pep-0318.txt,v retrieving revision 1.31 retrieving revision 1.32 diff -u -d -r1.31 -r1.32 --- pep-0318.txt 1 Sep 2004 15:02:22 -0000 1.31 +++ pep-0318.txt 1 Sep 2004 15:44:33 -0000 1.32 @@ -37,7 +37,7 @@ ========== The current method of applying a transformation to a function or method -places the actual translation after the function body. For large +places the actual transformation after the function body. For large functions this separates a key component of the function's behavior from the definition of the rest of the function's external interface. For example:: @@ -84,7 +84,7 @@ have raged off-and-on at times in both comp.lang.python and the python-dev mailing list about how best to implement function decorators. There is no one clear reason why this should be so, but a few problems -seem to be most problematic. +seem to be most divisive. * Disagreement about where the "declaration of intent" belongs. Almost everyone agrees that decorating/transforming a function at the @@ -293,11 +293,11 @@ There have been a number of objections raised to this location -- the primary one is that it's the first real Python case where a line of code -has a result on a following line. The syntax available for in 2.4a3 +has an effect on a following line. The syntax available in 2.4a3 requires one decorator per line (in a2, multiple decorators could be specified on the same line). -People also complained that the syntax got unworldly quickly when +People also complained that the syntax quickly got unwieldy when multiple decorators were used. The point was made, though, that the chances of a large number of decorators being used on a single function were small and thus this was not a large worry. @@ -306,9 +306,9 @@ the method body -- they are obviously executed at the time the function is defined. -Another advantage is that being prefix to the function definition fit +Another advantage is that a prefix to the function definition fits the idea of knowing about a change to the semantics of the code before -the code itself, thus knowing how to interpret the code's semantics +the code itself, thus you know how to interpret the code's semantics properly without having to go back and change your initial perceptions if the syntax did not come before the function definition. @@ -365,7 +365,7 @@ .. _summarized the arguments: http://mail.python.org/pipermail/python-dev/2004-August/047112.html -The next form is that the decorator syntax go inside the method body at +The next form is that the decorator syntax goes inside the method body at the start, in the same place that docstrings currently live: def foo(arg1,arg2): @@ -556,7 +556,7 @@ in Python also means it's clear there is no possibility of such code being parsed by an earlier version of Python, leading to possibly subtle semantic bugs. It also means that ambiguity of what is a decorator -and what isn't is removed. of That said, @ is still a fairly arbitrary +and what isn't is removed. That said, @ is still a fairly arbitrary choice. Some have suggested using | instead. For syntax options which use a list-like syntax (no matter where it

1 0

python/dist/src/Tools/msi msi.py,1.4,1.5
by loewis＠users.sourceforge.net Sept. 1, 2004

Sept. 1, 2004

Update of /cvsroot/python/python/dist/src/Tools/msi In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv29422 Modified Files: msi.py Log Message: Conditionalize Tcl feature Index: msi.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Tools/msi/msi.py,v retrieving revision 1.4 retrieving revision 1.5 diff -u -d -r1.4 -r1.5 --- msi.py 30 Aug 2004 09:22:30 -0000 1.4 +++ msi.py 1 Sep 2004 14:51:06 -0000 1.5 @@ -22,6 +22,8 @@ # goes into file name and ProductCode. Defaults to # current_version.day for Snapshot, current_version otherwise full_current_version = None +# Is Tcl available at all? +have_tcl = True try: from config import * @@ -762,7 +764,8 @@ ext_feature = Feature(db, "Extensions", "Register Extensions", "Make this Python installation the default Python installation", 3, parent = default_feature) - tcltk = Feature(db, "TclTk", "Tcl/Tk", "Tkinter, IDLE, pydoc", 5, + if have_tcl: + tcltk = Feature(db, "TclTk", "Tcl/Tk", "Tkinter, IDLE, pydoc", 5, parent = default_feature, attributes=2) htmlfiles = Feature(db, "Documentation", "Documentation", "Python HTMLHelp File", 7, parent = default_feature) @@ -811,7 +814,8 @@ # Add all executables, icons, text files into the TARGETDIR component root = PyDirectory(db, cab, None, srcdir, "TARGETDIR", "SourceDir") default_feature.set_current() - root.add_file("PCBuild/w9xpopen.exe") + if not msilib.Win64: + root.add_file("PCBuild/w9xpopen.exe") root.add_file("PC/py.ico") root.add_file("PC/pyc.ico") root.add_file("README.txt", src="README") @@ -851,6 +855,8 @@ if dir == "CVS" or dir.startswith("plat-"): continue elif dir in ["lib-tk", "idlelib", "Icons"]: + if not have_tcl: + continue tcltk.set_current() elif dir in ['test', 'output']: testsuite.set_current() @@ -913,15 +919,16 @@ continue dlls.append(f) lib.add_file(f) - if not os.path.exists(srcdir+"/PCBuild/_tkinter.pyd"): - print "WARNING: Missing _tkinter.pyd" - else: - lib.start_component("TkDLLs", tcltk) - lib.add_file("_tkinter.pyd") - dlls.append("_tkinter.pyd") - tcldir = os.path.normpath(srcdir+"/../tcltk/bin") - for f in glob.glob1(tcldir, "*.dll"): - lib.add_file(f, src=os.path.join(tcldir, f)) + if have_tcl: + if not os.path.exists(srcdir+"/PCBuild/_tkinter.pyd"): + print "WARNING: Missing _tkinter.pyd" + else: + lib.start_component("TkDLLs", tcltk) + lib.add_file("_tkinter.pyd") + dlls.append("_tkinter.pyd") + tcldir = os.path.normpath(srcdir+"/../tcltk/bin") + for f in glob.glob1(tcldir, "*.dll"): + lib.add_file(f, src=os.path.join(tcldir, f)) # check whether there are any unknown extensions for f in glob.glob1(srcdir+"/PCBuild", "*.pyd"): if f.endswith("_d.pyd"): continue # debug version @@ -938,19 +945,20 @@ for f in dlls: lib.add_file(f.replace('pyd','lib')) lib.add_file('python%s%s.lib' % (major, minor)) - # Add Tcl/Tk - tcldirs = [(root, '../tcltk/lib', 'tcl')] - tcltk.set_current() - while tcldirs: - parent, phys, dir = tcldirs.pop() - lib = PyDirectory(db, cab, parent, phys, dir, "%s|%s" % (parent.make_short(dir), dir)) - if not os.path.exists(lib.absolute): - continue - for f in os.listdir(lib.absolute): - if os.path.isdir(os.path.join(lib.absolute, f)): - tcldirs.append((lib, f, f)) - else: - lib.add_file(f) + if have_tcl: + # Add Tcl/Tk + tcldirs = [(root, '../tcltk/lib', 'tcl')] + tcltk.set_current() + while tcldirs: + parent, phys, dir = tcldirs.pop() + lib = PyDirectory(db, cab, parent, phys, dir, "%s|%s" % (parent.make_short(dir), dir)) + if not os.path.exists(lib.absolute): + continue + for f in os.listdir(lib.absolute): + if os.path.isdir(os.path.join(lib.absolute, f)): + tcldirs.append((lib, f, f)) + else: + lib.add_file(f) # Add tools tools.set_current() tooldir = PyDirectory(db, cab, root, "Tools", "Tools", "TOOLS|Tools") @@ -965,8 +973,9 @@ x.glob("*.txt") if f == 'Scripts': lib.add_file("README.txt", src="README") - lib.start_component("pydocgui.pyw", tcltk, keyfile="pydocgui.pyw") - lib.add_file("pydocgui.pyw") + if have_tcl: + lib.start_component("pydocgui.pyw", tcltk, keyfile="pydocgui.pyw") + lib.add_file("pydocgui.pyw") # Add documentation htmlfiles.set_current() lib = PyDirectory(db, cab, root, "Doc", "Doc", "DOC|Doc") @@ -984,25 +993,32 @@ # IDLE verbs depend on the tcltk feature. # msidbComponentAttributesRegistryKeyPath = 4 # -1 for Root specifies "dependent on ALLUSERS property" + tcldata = [] + if have_tcl: + tcldata = [ + ("REGISTRY.tcl", msilib.gen_uuid(), "TARGETDIR", 4, + "&%s <> 2" % ext_feature.id, "py.IDLE")] add_data(db, "Component", # msidbComponentAttributesRegistryKeyPath = 4 [("REGISTRY", msilib.gen_uuid(), "TARGETDIR", 4, None, "InstallPath"), ("REGISTRY.def", msilib.gen_uuid(), "TARGETDIR", 4, - None, None), - ("REGISTRY.tcl", msilib.gen_uuid(), "TARGETDIR", 4, - "&%s <> 2" % ext_feature.id, "py.IDLE")]) + None, None)] + tcldata) # See "FeatureComponents Table". # The association between TclTk and pythonw.exe is necessary to make ICE59 # happy, because the installer otherwise believes that the IDLE and PyDoc # shortcuts might get installed without pythonw.exe being install. This # is not true, since installing TclTk will install the default feature, which # will cause pythonw.exe to be installed. + tcldata = [] + if have_tcl: + tcltkdata = [(tcltk.id, "REGISTRY.tcl"), + (tcltk.id, "pythonw.exe")] add_data(db, "FeatureComponents", [(default_feature.id, "REGISTRY"), - (ext_feature.id, "REGISTRY.def"), - (tcltk.id, "REGISTRY.tcl"), - (tcltk.id, "pythonw.exe")]) + (ext_feature.id, "REGISTRY.def")] + + tcldata + ) pat = r"Software\Classes\%sPython.%sFile\shell\%s\command" ewi = "Edit with IDLE" @@ -1028,7 +1044,8 @@ # Non-advertised verbs: for advertised verbs, we would need to invoke the same # executable for both open and "Edit with IDLE". This cannot work, as we want # to use pythonw.exe in either case - add_data(db, "Registry", + if have_tcl: + add_data(db, "Registry", [#Verbs ("py.IDLE", -1, pat % (testprefix, "", ewi), "", r'"[TARGETDIR]pythonw.exe" "[TARGETDIR]Lib\idlelib\idle.pyw" -n -e "%1"', @@ -1058,12 +1075,17 @@ ("MenuDir", "ProgramMenuFolder", "PY%s%s|%sPython %s.%s" % (major,minor,testprefix,major,minor))]) add_data(db, "RemoveFile", [("MenuDir", "TARGETDIR", None, "MenuDir", 2)]) - add_data(db, "Shortcut", - [# Advertised shortcuts: targets are features, not files + tcltkshortcuts = [] + if have_tcl: + tcltkshortcuts = [ ("IDLE", "MenuDir", "IDLE|IDLE (Python GUI)", "pythonw.exe", tcltk.id, r"[TARGETDIR]Lib\idlelib\idle.pyw", None, None, "python_icon.exe", 0, None, "TARGETDIR"), ("PyDoc", "MenuDir", "MODDOCS|Module Docs", "pythonw.exe", tcltk.id, r"[TARGETDIR]Tools\scripts\pydocgui.pyw", None, None, "python_icon.exe", 0, None, "TARGETDIR"), + ] + add_data(db, "Shortcut", + tcltkshortcuts + + [# Advertised shortcuts: targets are features, not files ("Python", "MenuDir", "PYTHON|Python (command line)", "python.exe", default_feature.id, None, None, None, "python_icon.exe", 2, None, "TARGETDIR"), ("Manual", "MenuDir", "MANUAL|Python Manuals", "documentation",

1 0

python/dist/src/Lib asyncore.py,1.60,1.61
by akuchling＠users.sourceforge.net Sept. 1, 2004

Sept. 1, 2004

Update of /cvsroot/python/python/dist/src/Lib In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20591 Modified Files: asyncore.py Log Message: [Bug #1011606] Only check file descriptors for exceptional conditions if the fd is readable or writable Index: asyncore.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/asyncore.py,v retrieving revision 1.60 retrieving revision 1.61 diff -u -d -r1.60 -r1.61 --- asyncore.py 13 Aug 2004 20:06:57 -0000 1.60 +++ asyncore.py 1 Sep 2004 14:04:51 -0000 1.61 @@ -107,11 +107,14 @@ if map: r = []; w = []; e = [] for fd, obj in map.items(): - e.append(fd) - if obj.readable(): + is_r = obj.readable() + is_w = obj.writable() + if is_r: r.append(fd) - if obj.writable(): + if is_w: w.append(fd) + if is_r or is_w: + e.append(fd) if [] == r == w == e: time.sleep(timeout) else: @@ -151,12 +154,15 @@ pollster = select.poll() if map: for fd, obj in map.items(): - flags = select.POLLERR | select.POLLHUP | select.POLLNVAL + flags = 0 if obj.readable(): flags |= select.POLLIN | select.POLLPRI if obj.writable(): flags |= select.POLLOUT if flags: + # Only check for exceptions if object was either readable + # or writable. + flags |= select.POLLERR | select.POLLHUP | select.POLLNVAL pollster.register(fd, flags) try: r = pollster.poll(timeout)

1 0

python/nondist/peps pep-0333.txt,1.5,1.6
by pje＠users.sourceforge.net Sept. 1, 2004

Sept. 1, 2004

Update of /cvsroot/python/python/nondist/peps In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv17715 Modified Files: pep-0333.txt Log Message: Move 'fileno()' support to a separate section, where it should be easier to see it's an optional and platform-specific extension, not an excuse to return "file-like" objects instead of iterables. Index: pep-0333.txt =================================================================== RCS file: /cvsroot/python/python/nondist/peps/pep-0333.txt,v retrieving revision 1.5 retrieving revision 1.6 diff -u -d -r1.5 -r1.6 --- pep-0333.txt 1 Sep 2004 04:59:21 -0000 1.5 +++ pep-0333.txt 1 Sep 2004 13:44:07 -0000 1.6 @@ -281,24 +281,6 @@ returned by the application provides a working ``__len__()`` method, it **must** return an accurate result. -If the returned iterable has a ``fileno`` attribute, the server **may** -assume that this is a ``fileno()`` method returning an operating -system file descriptor, and that it is allowed to read directly from -that descriptor up to the end of the file, and/or use any appropriate -operating system facilities (e.g. the ``sendfile()`` system call) to -transmit the file's contents. If the server does this, it must begin -transmission with the file's current position, and end at the end of -the file. - -Note that an application **must not** return an iterable with a -``fileno`` attribute if it is anything other than a method returning -an **operating system file descriptor**. "File-like" objects -that do not possess a true operating system file descriptor number -are expressly forbidden. Servers running on platforms where file -descriptors do not exist, or where there is no meaningful API for -accelerating transmission from a file descriptor should ignore the -``fileno`` attribute. - If the iterable returned by the application has a ``close()`` method, the server or gateway **must** call that method upon completion of the current request, whether the request was completed normally, or @@ -865,6 +847,41 @@ being bypassed by applications using those extensions! +Optional Platform-Specific File Handling +---------------------------------------- + +If the application-returned iterable has a ``fileno`` attribute, +the server or gateway **may** assume that this is a ``fileno()`` +method returning an operating system file descriptor, and that it is +allowed to read directly from that descriptor up to the end of the +file, and/or use any appropriate operating system facilities (e.g. +the ``sendfile()`` system call) to transmit the file's contents. If +the server does this, it must begin transmission with the file's +current position, and end at the end of the file. + +Note that an application **must not** return an iterable with a +``fileno`` attribute if it is anything other than a method returning +an **operating system file descriptor**. "File-like" objects +that do not possess a true operating system file descriptor number +are expressly. Servers running on platforms where file +descriptors do not exist, or where there is no meaningful API for +accelerating transmission from a file descriptor should ignore the +``fileno`` attribute. + +On platforms that possess some analagous mechanism for fast +transmission of static files or pipes, a server or gateway **may** +offer a similar extension using a different method name, returning +an object of the appropriate type for that platform. Such servers +**should** document the method name to be used and the type of +object that it should return. + +Please note that this optional extension does not excuse the +application from returning an iterable object. Returning an object +that is not iterable -- even if it implements ``fileno()`` or is +"file-like" -- is not acceptable, and will be rejected by servers +and gateways that do not support this optional extension. + + HTTP 1.1 Expect/Continue ------------------------

1 0

python/dist/src/Lib _MozillaCookieJar.py, 1.2, 1.3 os.py, 1.80, 1.81
by tim_one＠users.sourceforge.net Sept. 1, 2004

Sept. 1, 2004

Update of /cvsroot/python/python/dist/src/Lib In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv11454/Lib Modified Files: _MozillaCookieJar.py os.py Log Message: Whitespace normalization. Index: _MozillaCookieJar.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/_MozillaCookieJar.py,v retrieving revision 1.2 retrieving revision 1.3 diff -u -d -r1.2 -r1.3 --- _MozillaCookieJar.py 31 Aug 2004 11:38:12 -0000 1.2 +++ _MozillaCookieJar.py 1 Sep 2004 13:10:31 -0000 1.3 @@ -2,7 +2,7 @@ import re, time, logging -from cookielib import (reraise_unmasked_exceptions, FileCookieJar, Cookie, +from cookielib import (reraise_unmasked_exceptions, FileCookieJar, Cookie, MISSING_FILENAME_TEXT) class MozillaCookieJar(FileCookieJar): Index: os.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/os.py,v retrieving revision 1.80 retrieving revision 1.81 diff -u -d -r1.80 -r1.81 --- os.py 31 Aug 2004 11:38:12 -0000 1.80 +++ os.py 1 Sep 2004 13:10:31 -0000 1.81 @@ -130,7 +130,7 @@ raise ImportError, 'no os specific module found' sys.modules['os.path'] = path -from os.path import (curdir, pardir, sep, pathsep, defpath, extsep, altsep, +from os.path import (curdir, pardir, sep, pathsep, defpath, extsep, altsep, devnull) del _names

1 0

python/dist/src/Lib/test test_optparse.py, 1.7, 1.8
by tim_one＠users.sourceforge.net Sept. 1, 2004

Sept. 1, 2004

Update of /cvsroot/python/python/dist/src/Lib/test In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv11454/Lib/test Modified Files: test_optparse.py Log Message: Whitespace normalization. Index: test_optparse.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_optparse.py,v retrieving revision 1.7 retrieving revision 1.8 diff -u -d -r1.7 -r1.8 --- test_optparse.py 31 Aug 2004 11:38:12 -0000 1.7 +++ test_optparse.py 1 Sep 2004 13:10:32 -0000 1.8 @@ -17,9 +17,9 @@ from pprint import pprint from test import test_support -from optparse import (make_option, Option, IndentedHelpFormatter, - TitledHelpFormatter, OptionParser, OptionContainer, OptionGroup, - SUPPRESS_HELP, SUPPRESS_USAGE, OptionError, OptionConflictError, +from optparse import (make_option, Option, IndentedHelpFormatter, + TitledHelpFormatter, OptionParser, OptionContainer, OptionGroup, + SUPPRESS_HELP, SUPPRESS_USAGE, OptionError, OptionConflictError, BadOptionError, OptionValueError, _match_abbrev) class BaseTest(unittest.TestCase):

1 0