Mailman 3 April 2007 - Python-checkins

r55021 - python/trunk/Misc/build.sh
by neal.norwitz April 29, 2007

April 29, 2007

Author: neal.norwitz Date: Mon Apr 30 01:53:24 2007 New Revision: 55021 Modified: python/trunk/Misc/build.sh Log: There really are some tests that are problematic. Modified: python/trunk/Misc/build.sh ============================================================================== --- python/trunk/Misc/build.sh (original) +++ python/trunk/Misc/build.sh Mon Apr 30 01:53:24 2007 @@ -67,7 +67,7 @@ # Note: test_XXX (none currently) really leak, but are disabled # so we don't send spam. Any test which really leaks should only # be listed here if there are also test cases under Lib/test/leakers. -LEAKY_TESTS="test_(XXX)" # Currently no tests should report spurious leaks. +LEAKY_TESTS="test_(cmd_line|socket)" # Skip these tests altogether when looking for leaks. These tests # do not need to be stored above in LEAKY_TESTS too.

1 0

r55020 - peps/trunk/pep-0302.txt
by brett.cannon April 29, 2007

April 29, 2007

Author: brett.cannon Date: Sun Apr 29 22:19:50 2007 New Revision: 55020 Modified: peps/trunk/pep-0302.txt Log: Specify that load_module is to raise ImportError if an error has occurred and no exceptino is being propagated or it has been asked to load a module that it cannot. Also specify that __name__ must be set on all loaded modules. Modified: peps/trunk/pep-0302.txt ============================================================================== --- peps/trunk/pep-0302.txt (original) +++ peps/trunk/pep-0302.txt Sun Apr 29 22:19:50 2007 @@ -223,9 +223,13 @@ loader.load_module(fullname) - This method returns the loaded module. In many cases the importer - and loader can be one and the same object: importer.find_module() - would just return self. + This method returns the loaded module or raises and exception, + preferably ImportError if an existing exception is not being + propagated. If load_module() is asked to laod a module that it + cannot, ImportError is to be raised. + + In many cases the importer and loader can be one and the same + object: importer.find_module() would just return self. The 'fullname' argument of both methods is the fully qualified module name, for example "spam.eggs.ham". As explained above, when @@ -267,6 +271,9 @@ not having a __file__ attribute at all is reserved for built-in modules. + - The __name__ attribute must be set. If one uses + imp.new_module() then the attribute is set automatically. + - If it's a package, the __path__ variable must be set. This must be a list, but may be empty if __path__ has no further significance to the importer (more on this later).

1 0

r55019 - peps/trunk/pep-3108.txt
by brett.cannon April 29, 2007

April 29, 2007

Author: brett.cannon Date: Sun Apr 29 22:03:44 2007 New Revision: 55019 Modified: peps/trunk/pep-3108.txt Log: Add bsddb185 to the list of modules to go. Modified: peps/trunk/pep-3108.txt ============================================================================== --- peps/trunk/pep-3108.txt (original) +++ peps/trunk/pep-3108.txt Sun Apr 29 22:03:44 2007 @@ -267,6 +267,13 @@ + Turned off in Python 2.3. + Modules deemed unsafe. +* bsddb185 + + + Superceded by bsddb3 + + Not built by default. + + Documentation specifies that the "module should never be used + directly in new code". + * commands/popen2 + subprocess module replaces them [#pep-0324]_.

1 0

r55018 - peps/trunk/pep-3121.txt
by martin.v.loewis April 29, 2007

April 29, 2007

Author: martin.v.loewis Date: Sun Apr 29 16:17:02 2007 New Revision: 55018 Modified: peps/trunk/pep-3121.txt Log: Add edits suggested by Brett. Modified: peps/trunk/pep-3121.txt ============================================================================== --- peps/trunk/pep-3121.txt (original) +++ peps/trunk/pep-3121.txt Sun Apr 29 16:17:02 2007 @@ -19,8 +19,11 @@ multiple interpreters are not supported well. This PEP addresses these issues. +Problems +======== + Module Finalization -=================== +------------------- Currently, C modules are initialized usually once and then "live" forever. The only exception is when Py_Finalize() is called: then @@ -31,7 +34,7 @@ way to completely release all resources Python has allocated. Entry point name conflicts -========================== +-------------------------- The entry point is currently called init<module>. This might conflict with other symbols also called init<something>. In particular, @@ -40,7 +43,7 @@ _socket). Entry point signature -===================== +--------------------- The entry point is currently a procedure (returning void). This deviates from the usual calling conventions; callers can find out @@ -49,7 +52,7 @@ be the module created, or NULL in case of an exception. Multiple Interpreters -===================== +--------------------- Currently, extension modules share their state across all interpreters. This allows for undesirable information leakage across @@ -97,7 +100,7 @@ PyModuleDef*. The module state will be null-initialized. -Each module method with be passed the module object +Each module method will be passed the module object as the first parameter. To access the module data, a function::

1 0

r55017 - peps/trunk/pep-3123.txt
by martin.v.loewis April 29, 2007

April 29, 2007

Author: martin.v.loewis Date: Sun Apr 29 15:46:08 2007 New Revision: 55017 Modified: peps/trunk/pep-3123.txt Log: Add Brett's suggested changes. Modified: peps/trunk/pep-3123.txt ============================================================================== --- peps/trunk/pep-3123.txt (original) +++ peps/trunk/pep-3123.txt Sun Apr 29 15:46:08 2007 @@ -45,8 +45,8 @@ The problem here is that the storage is both accessed as if it where struct PyObject, and as struct FooObject. -Historically, compilers did not cause any problems with this -code. However, modern compiler use that clause as an +Historically, compilers did not have any problems with this +code. However, modern compilers use that clause as an optimization opportunity, finding that f->ob_refcnt and o->ob_refcnt cannot possibly refer to the same memory, and that therefore the function should return 0, without having @@ -110,7 +110,18 @@ #define Py_Type(o) (((PyObject*)o)->ob_type) -is added. +is added. E.g. the code blocks:: + + #define PyList_CheckExact(op) ((op)->ob_type == &PyList_Type) + + return func->ob_type->tp_name; + +needs to be changed to:: + + #define PyList_CheckExact(op) (Py_Type(op) == &PyList_Type) + + return Py_Type(func)->tp_name; + Compatibility with Python 2.6 =============================

1 0

r55016 - peps/trunk/pep-0000.txt peps/trunk/pep-3123.txt
by martin.v.loewis April 29, 2007

April 29, 2007

Author: martin.v.loewis Date: Sun Apr 29 15:42:17 2007 New Revision: 55016 Added: peps/trunk/pep-3123.txt (contents, props changed) Modified: peps/trunk/pep-0000.txt Log: Add PEP 3123. Modified: peps/trunk/pep-0000.txt ============================================================================== --- peps/trunk/pep-0000.txt (original) +++ peps/trunk/pep-0000.txt Sun Apr 29 15:42:17 2007 @@ -119,6 +119,7 @@ S 3119 Introducing Abstract Base Classes GvR, Talin S 3120 Using UTF-8 as the default source encoding von Löwis S 3121 Module Initialization and finalization von Löwis + S 3123 Making PyObject_HEAD conform to standard C von Löwis S 3141 A Type Hierarchy for Numbers Yasskin Finished PEPs (done, implemented in Subversion) @@ -480,6 +481,7 @@ S 3120 Using UTF-8 as the default source encoding von Löwis S 3121 Module Initialization and finalization von Löwis SR 3122 Delineation of the main module Cannon + S 3123 Making PyObject_HEAD conform to standard C von Löwis S 3141 A Type Hierarchy for Numbers Yasskin Added: peps/trunk/pep-3123.txt ============================================================================== --- (empty file) +++ peps/trunk/pep-3123.txt Sun Apr 29 15:42:17 2007 @@ -0,0 +1,138 @@ +PEP: 3123 +Title: Making PyObject_HEAD conform to standard C +Version: $Revision$ +Last-Modified: $Date$ +Author: Martin v. Löwis <martin(a)v.loewis.de> +Status: Draft +Type: Standards Track +Content-Type: text/x-rst +Created: 27-Apr-2007 +Python-Version: 3.0 +Post-History: + +Abstract +======== + +Python currently relies on undefined C behavior, with its +usage of PyObject_HEAD. This PEP proposes to change that +into standard C. + +Rationale +========= + +Standard C defines that an object must be accessed only through a +pointer of its type, and that all other accesses are undefined +behavior, with a few exceptions. In particular, the following +code has undefined behavior:: + + struct FooObject{ + PyObject_HEAD + int data; + }; + + PyObject *foo(struct FooObject*f){ + return (PyObject*)f; + } + + int bar(){ + struct FooObject *f = malloc(sizeof(struct FooObject)); + struct PyObject *o = foo(f); + f->ob_refcnt = 0; + o->ob_refcnt = 1; + return f->ob_refcnt; + } + +The problem here is that the storage is both accessed as +if it where struct PyObject, and as struct FooObject. + +Historically, compilers did not cause any problems with this +code. However, modern compiler use that clause as an +optimization opportunity, finding that f->ob_refcnt and +o->ob_refcnt cannot possibly refer to the same memory, and +that therefore the function should return 0, without having +to fetch the value of ob_refcnt at all in the return +statement. For GCC, Python now uses -fno-strict-aliasing +to work around that problem; with other compilers, it +may just see undefined behavior. Even with GCC, using +-fno-strict-aliasing may pessimize the generated code +unnecessarily. + +Specification +============= + +Standard C has one specific exception to its aliasing rules precisely +designed to support the case of Python: a value of a struct type may +also be accessed through a pointer to the first field. E.g. if a +struct starts with an int, the struct\* may also be cast to an int\*, +allowing to write int values into the first field. + +For Python, PyObject_HEAD and PyObject_VAR_HEAD will be changed +to not list all fields anymore, but list a single field of type +PyObject/PyVarObject:: + + typedef struct _object{ + _PyObject_HEAD_EXTRA + Py_ssize_t ob_refcnt; + struct _typeobject *ob_type; + }PyObject; + + typedef struct { + PyObject ob_base; + Py_ssize_t ob_size; + } PyVarObject; + + #define PyObject_HEAD PyObject ob_base; + #define PyObject_VAR_HEAD PyVarObject ob_base; + +Types defined as fixed-size structure will then include PyObject +as its first field; variable-sized objects PyVarObject. E.g.:: + + typedef struct{ + PyObject ob_base; + PyObject *start, *stop, *step; + } PySliceObject; + + typedef struct{ + PyVarObject ob_base; + PyObject **ob_item; + Py_ssize_t allocated; + } PyListObject; + +The above definitions of PyObject_HEAD is normative, so extension +authors MAY either use the macro, or put the ob_base field explicitly +into their structs. + +As a convention, the base field SHOULD be called ob_base. However, all +accesses to ob_refcnt and ob_type MUST cast the object pointer to +PyObject* (unless the pointer is already known to have that type), and +SHOULD use the respective accessor macros. To simplify access to +ob_type, a macro:: + + #define Py_Type(o) (((PyObject*)o)->ob_type) + +is added. + +Compatibility with Python 2.6 +============================= + +To support modules that compile with both Python 2.6 and Python 3.0, +the Py_Type macro is added to Python 2.6. The macros Py_INCREF +and Py_DECREF will be changed to cast their argument to PyObject\*, +so that module authors can also explicitly declare the ob_base +field in modules designed for Python 2.6. + +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 + coding: utf-8 + End:

1 0

buildbot warnings in alpha Tru64 5.1 2.5
by buildbot＠python.org April 28, 2007

April 28, 2007

The Buildbot has detected a new failure of alpha Tru64 5.1 2.5. Full details are available at: http://www.python.org/dev/buildbot/all/alpha%2520Tru64%25205.1%25202.5/buil… Buildbot URL: http://www.python.org/dev/buildbot/all/ Build Reason: The web-page 'force build' button was pressed by 'nnorwitz': last compile failed, machine moved Build Source Stamp: [branch trunk] HEAD Blamelist: Build had warnings: warnings test Excerpt from the test logfile: sincerely, -The Buildbot

1 0

r55015 - peps/trunk/pep-0000.txt peps/trunk/pep-3122.txt
by brett.cannon April 28, 2007

April 28, 2007

Author: brett.cannon Date: Sat Apr 28 08:48:59 2007 New Revision: 55015 Added: peps/trunk/pep-3122.txt (contents, props changed) Modified: peps/trunk/pep-0000.txt Log: Add PEP 3122: Delineation of the main module. This PEP has already been rejected. Modified: peps/trunk/pep-0000.txt ============================================================================== --- peps/trunk/pep-0000.txt (original) +++ peps/trunk/pep-0000.txt Sat Apr 28 08:48:59 2007 @@ -259,6 +259,7 @@ SR 363 Syntax For Dynamic Attribute Access North SR 666 Reject Foolish Indentation Creighton SR 3103 A Switch/Case Statement GvR + SR 3122 Delineation of the main module Cannon Numerical Index @@ -478,6 +479,7 @@ S 3119 Introducing Abstract Base Classes GvR, Talin S 3120 Using UTF-8 as the default source encoding von Löwis S 3121 Module Initialization and finalization von Löwis + SR 3122 Delineation of the main module Cannon S 3141 A Type Hierarchy for Numbers Yasskin Added: peps/trunk/pep-3122.txt ============================================================================== --- (empty file) +++ peps/trunk/pep-3122.txt Sat Apr 28 08:48:59 2007 @@ -0,0 +1,267 @@ +PEP: 3122 +Title: Delineation of the main module +Version: $Revision$ +Last-Modified: $Date$ +Author: Brett Cannon +Status: Rejected +Type: Standards Track +Content-Type: text/x-rst +Created: 27-Apr-2007 + +.. attention:: + This PEP has been rejected. Guido views running scripts within a + package as an anti-pattern [#guido-rejection]_. + +Abstract +======== + +Because of how name resolution works for relative imports in a world +where PEP 328 is implemented, the ability to execute modules within a +package ceases being possible. This failing stems from the fact that +the module being executed as the "main" module replaces its +``__name__`` attribute with ``"__main__"`` instead of leaving it as +the absolute name of the module. This breaks import's ability +to resolve relative imports from the main module into absolute names. + +In order to resolve this issue, this PEP proposes to change how the +main module is delineated. By leaving the ``__name__`` attribute in +a module alone and setting ``sys.main`` to the name of the main +module this will allow at least some instances of executing a module +within a package that uses relative imports. + +This PEP does not address the idea of introducing a module-level +function that is automatically executed like PEP 299 proposes. + + +The Problem +=========== + +With the introduction of PEP 328, relative imports became dependent on +the ``__name__`` attribute of the module performing the import. This +is because the use of dots in a relative import are used to strip away +parts of the calling module's name to calculate where in the package +hierarchy an import should fall (prior to PEP 328 relative +imports could fail and would fall back on absolute imports which had a +chance of succeeding). + +For instance, consider the import ``from .. import spam`` made from the +``bacon.ham.beans`` module (``bacon.ham.beans`` is not a package +itself, i.e., does not define ``__path__``). Name resolution of the +relative import takes the caller's name (``bacon.ham.beans``), splits +on dots, and then slices off the last n parts based on the level +(which is 2). In this example both ``ham`` and ``beans`` are dropped +and ``spam`` is joined with what is left (``bacon``). This leads to +the proper import of the module ``bacon.spam``. + +This reliance on the ``__name__`` attribute of a module when handling +relative imports becomes an issue when executing a script within a +package. Because the executing script has its name set to +``'__main__'``, import cannot resolve any relative imports, leading to +an ``ImportError``. + +For example, assume we have a package named ``bacon`` with an +``__init__.py`` file containing:: + + from . import spam + +Also create a module named ``spam`` within the ``bacon`` package (it +can be an empty file). Now if you try to execute the ``bacon`` +package (either through ``python bacon/__init__.py`` or +``python -m bacon``) you will get an ``ImportError`` about trying to +do a relative import from within a non-package. Obviously the import +is valid, but because of the setting of ``__name__`` to ``'__main__'`` +import thinks that ``bacon/__init__.py`` is not in a package since no +dots exist in ``__name__``. To see how the algorithm works in more +detail, see ``importlib.Import._resolve_name()`` in the sandbox +[#importlib]_. + +Currently a work-around is to remove all relative imports in the +module being executed and make them absolute. This is unfortunate, +though, as one should not be required to use a specific type of +resource in order to make a module in a package be able to be +executed. + + +The Solution +============ + +The solution to the problem is to not change the value of ``__name__`` +in modules. But there still needs to be a way to let executing code +know it is being executed as a script. This is handled with a new +attribute in the ``sys`` module named ``main``. + +When a module is being executed as a script, ``sys.main`` will be set +to the name of the module. This changes the current idiom of:: + + if __name__ == '__main__': + ... + +to:: + + import sys + if __name__ == sys.main: + ... + +The newly proposed solution does introduce an added line of +boilerplate which is a module import. But as the solution does not +introduce a new built-in or module attribute (as discussed in +`Rejected Ideas`_) it has been deemed worth the extra line. + +Another issue with the proposed solution (which also applies to all +rejected ideas as well) is that it does not directly solve the problem +of discovering the name of a file. Consider ``python bacon/spam.py``. +By the file name alone it is not obvious whether ``bacon`` is a +package. In order to properly find this out both the current +direction must exist on ``sys.path`` as well as ``bacon/__init__.py`` +existing. + +But this is the simple example. Consider ``python ../spam.py``. From +the file name alone it is not at all clear if ``spam.py`` is in a +package or not. One possible solution is to find out what the +absolute name of ``..``, check if a file named ``__init__.py`` exists, +and then look if the directory is on ``sys.path``. If it is not, then +continue to walk up the directory until no more ``__init__.py`` files +are found or the directory is found on ``sys.path``. + +This could potentially be an expensive process. If the package depth +happens to be deep then it could require a large amount of disk access +to discover where the package is anchored on ``sys.path``, if at all. +The stat calls alone can be expensive if the file system the executed +script is on is something like NFS. + +Because of these issues, only when the ``-m`` command-line argument +(introduced by PEP 338) is used will ``__name__`` be set. Otherwise +the fallback semantics of setting ``__name__`` to ``"__main__"`` will +occur. ``sys.main`` will still be set to the proper value, +regardless of what ``__name__`` is set to. + + +Implementation +============== + +When the ``-m`` option is used, ``sys.main`` will be set to the +argument passed in. ``sys.argv`` will be adjusted as it is currently. +Then the equivalent of ``__import__(self.main)`` will occur. This +differs from current semantics as the ``runpy`` module fetches the +code object for the file specified by the module name in order to +explicitly set ``__name__`` and other attributes. This is no longer +needed as import can perform its normal operation in this situation. + +If a file name is specified, then ``sys.main`` will be set to +``"__main__"``. The specified file will then be read and have a code +object created and then be executed with ``__name__`` set to +``"__main__"``. This mirrors current semantics. + + +Transition Plan +=============== + +In order for Python 2.6 to be able to support both the current +semantics and the proposed semantics, ``sys.main`` will always be set +to ``"__main__"``. Otherwise no change will occur for Python 2.6. +This unfortunately means that no benefit from this change will occur +in Python 2.6, but it maximizes compatibility for code that is to +work as much as possible with 2.6 and 3.0. + +To help transition to the new idiom, 2to3 [#2to3]_ will gain a rule to +transform the current ``if __name__ == '__main__': ...`` idiom to the +new one. This will not help with code that checks ``__name__`` +outside of the idiom, though. + + +Rejected Ideas +============== + +``__main__`` built-in +--------------------- + +A counter-proposal to introduce a built-in named ``__main__``. +The value of the built-in would be the name of the module being +executed (just like the proposed ``sys.main``). This would lead to a +new idiom of:: + + if __name__ == __main__: + ... + +A drawback is that the syntactic difference is subtle; the dropping +of quotes around "__main__". Some believe that for existing Python +programmers bugs will be introduced where the quotation marks will be +put on by accident. But one could argue that the bug would be +discovered quickly through testing as it is a very shallow bug. + +While the name of built-in could obviously be different (e.g., +``main``) the other drawback is that it introduces a new built-in. +With a simple solution such as ``sys.main`` being possible without +adding another built-in to Python, this proposal was rejected. + +``__main__`` module attribute +----------------------------- + +Another proposal was to add a ``__main__`` attribute to every module. +For the one that was executing as the main module, the attribute would +have a true value while all other modules had a false value. This has +a nice consequence of simplify the main module idiom to:: + + if __main__: + ... + +The drawback was the introduction of a new module attribute. It also +required more integration with the import machinery than the proposed +solution. + + +Use ``__file__`` instead of ``__name__`` +---------------------------------------- + +Any of the proposals could be changed to use the ``__file__`` +attribute on modules instead of ``__name__``, including the current +semantics. The problem with this is that with the proposed solutions +there is the issue of modules having no ``__file__`` attribute defined +or having the same value as other modules. + +The problem that comes up with the current semantics is you still have +to try to resolve the file path to a module name for the import to +work. + + +Special string subclass for ``__name__`` that overrides ``__eq__`` +------------------------------------------------------------------ + +One proposal was to define a subclass of ``str`` that overrode the +``__eq__`` method so that it would compare equal to ``"__main__"`` as +well as the actual name of the module. In all other respects the +subclass would be the same as ``str``. + +This was rejected as it seemed like too much of a hack. + + +References +========== + +.. [#2to3] 2to3 tool + (http://svn.python.org/view/sandbox/trunk/2to3/) [ViewVC] + +.. [#importlib] importlib + (http://svn.python.org/view/sandbox/trunk/import_in_py/importlib.py?view=mar…) + [ViewVC] + +.. [#guido-rejection] Python-Dev email: "PEP to change how the main module is delineated" + (http://mail.python.org/pipermail/python-3000/2007-April/006793.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 + coding: utf-8 + End:

1 0

buildbot warnings in alpha Debian 2.5
by buildbot＠python.org April 28, 2007

April 28, 2007

The Buildbot has detected a new failure of alpha Debian 2.5. Full details are available at: http://www.python.org/dev/buildbot/all/alpha%2520Debian%25202.5/builds/18 Buildbot URL: http://www.python.org/dev/buildbot/all/ Build Reason: Build Source Stamp: [branch branches/release25-maint] HEAD Blamelist: brett.cannon,fred.drake,georg.brandl Build had warnings: warnings test Excerpt from the test logfile: sincerely, -The Buildbot

1 0

r55014 - peps/trunk/pep-0008.txt peps/trunk/pep-0237.txt peps/trunk/pep-0242.txt peps/trunk/pep-0359.txt peps/trunk/pep-3118.txt
by andrew.kuchling April 28, 2007

April 28, 2007

Author: andrew.kuchling Date: Sat Apr 28 02:36:48 2007 New Revision: 55014 Modified: peps/trunk/pep-0008.txt peps/trunk/pep-0237.txt peps/trunk/pep-0242.txt peps/trunk/pep-0359.txt peps/trunk/pep-3118.txt Log: Fix 'the the' error Modified: peps/trunk/pep-0008.txt ============================================================================== --- peps/trunk/pep-0008.txt (original) +++ peps/trunk/pep-0008.txt Sat Apr 28 02:36:48 2007 @@ -502,7 +502,7 @@ only.) The conventions are about the same as those for functions. Modules that are designed for use via "from M import *" should use the - __all__ mechanism to prevent exporting globals, or use the the older + __all__ mechanism to prevent exporting globals, or use the older convention of prefixing such globals with an underscore (which you might want to do to indicate these globals are "module non-public"). Modified: peps/trunk/pep-0237.txt ============================================================================== --- peps/trunk/pep-0237.txt (original) +++ peps/trunk/pep-0237.txt Sat Apr 28 02:36:48 2007 @@ -276,7 +276,7 @@ import warnings warnings.filterwarnings("default", "", OverflowWarning) - See the python man page for the -W option and the the warnings + See the python man page for the -W option and the warnings module documentation for filterwarnings(). - If the OverflowWarning warning is turned into an error, Modified: peps/trunk/pep-0242.txt ============================================================================== --- peps/trunk/pep-0242.txt (original) +++ peps/trunk/pep-0242.txt Sat Apr 28 02:36:48 2007 @@ -51,7 +51,7 @@ long, and must support at least one kind of floating point number, equivalent to the present float. - The range and precision of the these required kinds are processor + The range and precision of these required kinds are processor dependent, as at present, except for the "long integer" kind, which can hold an arbitrary integer. Modified: peps/trunk/pep-0359.txt ============================================================================== --- peps/trunk/pep-0359.txt (original) +++ peps/trunk/pep-0359.txt Sat Apr 28 02:36:48 2007 @@ -159,7 +159,7 @@ hi_there.pack(side=Tkinter.LEFT) root.mainloop() -could be rewritten to group the the Button's function with its +could be rewritten to group the Button's function with its declaration:: root = Tkinter.Tk() Modified: peps/trunk/pep-3118.txt ============================================================================== --- peps/trunk/pep-3118.txt (original) +++ peps/trunk/pep-3118.txt Sat Apr 28 02:36:48 2007 @@ -947,7 +947,7 @@ /* Optional: if, after processing, we want to copy data from buffer back - into the the object + into the object we could do */

1 0