Mailman 3 January 2009 - Python-checkins

r68914 - peps/trunk/pep-0374.txt
by brett.cannon Feb. 16, 2009

Feb. 16, 2009

Author: brett.cannon Date: Sun Jan 25 00:06:31 2009 New Revision: 68914 Log: Thoroughly clean up what impressions I have written so far. Modified: peps/trunk/pep-0374.txt Modified: peps/trunk/pep-0374.txt ============================================================================== --- peps/trunk/pep-0374.txt (original) +++ peps/trunk/pep-0374.txt Sun Jan 25 00:06:31 2009 @@ -1344,120 +1344,136 @@ is likely to shock a veteran CVS user. -Impressions -=========== +Tests/Impressions +================= + As I (Brett Cannon) am left with the task of of making the final decision of which/any DVCS to go with and not my co-authors, I felt -it only fair to write down my impressions as I evaluate the various -tools so as to be as transparent as possible. +it only fair to write down what tests I ran and my impressions as I +evaluate the various tools so as to be as transparent as possible. + + +Barrier to Entry +---------------- -To begin, I measured the checking out of code as if I was a non-core -developer. This is important as this is the first impression -developers have when they decide they wish to contribute a patch to -Python. Timings were done using the ``time`` command in zsh and +The amount of time and effort it takes to get a checkout of Python's +repository is critical. If the difficulty or time is too great then a +person wishing to contribute to Python may very well give up. That +cannot be allowed to happen. + +I measured the checking out of code as if I was a non-core +developer. Timings were done using the ``time`` command in zsh and space was calculated with ``du -c -h``. ======= ================ ============== DVCS Time Space ------- ---------------- -------------- -svn 1:04 139 M -bzr 2:29:24 or 8:46 275 M or 596 M -hg 2:30 171 M -git 2:54 134 M +svn 1:04 139 M +bzr 1 2:29:24 275 M +bzr 2 8:46 596 M +hg 2:30 171 M +git 2:54 134 M ======= ================ ============== -The svn measurements are not exactly a 1:1 comparison to the DVCSs. -For one, svn does not download the entire revision history, and thus -(should) have the least amount to download. And two, because various -calculation steps are left up to the server the entire process of -checking out code (should) be faster. - -But the svn measurements should be considered as what developers are -used to. Thus they act as a reference point for what people tend to -expect in terms of performance. - -Looking at bzr, I have listed two numbers. The first values are for -running ``bzr branch`` as outlined in the `One-Off Checkout`_ -scenario. When the -timings came back in hours (I used Launchpad as code.python.org is -not running the newest version of bzr and I wanted to use its latest -networking protocol), I decided to try using the steps outlined when -the experimental bzr branches were first created. That second -approach is what the second set of values for bzr represent. - -While both the hg and git numbers are perfectly acceptable, the bzr -numbers not necessarily. The raw ``bzr branch`` approach is entirely -not acceptable as no one wants to wait over two hours to write a -potentially one line change to some code for the benefit of Python. -Assuming 8:46 is a reasonable amount of time (I believe it in -general is, but it is teetering on not), the 596 M space requirement -could be an issue for some. While we typically view disk space as -cheap, for some people it might be an issue (e.g. the person who did -the schedule for PyCon 2008 did it over a connection so badly that -Google Spreadsheets didn't work for him and he had to submit the -schedule in another form than the one original used). Once again I -think the space usage is acceptable, but it is close to being too -much. - -To see if bzr's performance would be acceptable once at least the -branch was downloaded, I decided to see how long it would take to -get the change log for a file. I chose the README file as it sees -regular changes for every release and has a revision history going -back to 1993 and thus would have a fair number of revisions. -It should be mentioned that while git had the nicest output thanks to -its color terminal output, it also took a while to find the -``--no-pager`` flag in order to get just a stream of text instead of -having the output sent to the pager. - -Overall the numbers were all acceptable: - -* bzr: 4.5 seconds -* hg: 1.1 seconds -* git: 1.5 seconds - -While having bzr be over 3x slower than its nearest neighbor, it -must be kept in mind that the total performance time is still -acceptable, regardless of the multiplier. - -Because a DVCS keeps its revision history on disk, it also means -that typically they can be zipped up for direct downloading. At -least in bzr's case that would solve the performance issue for -initial checkout if the zip file could be generate constantly. But -that didn't address the cost of pulling in new revisions when a -checkout has gone stale. To measure this I decided I would check out -the repositories back about 700 revisions which represented the -amount of change made since the beginning of the month and time how -long they took to update. - -For this to happen I first had to remember the URLs for the -repositories. Instead of simply looking in this PEP, though, I -decided to try to figure it out from the command-line help for each -tool or simply guessing. Bzr worked out great with ``bzr info``. Git -took a little poking around, but I figured out ``git remote show -origin`` told me what I needed. For hg, though, I couldn't figure it -out short of running ``hg pull`` and denoting the status information -during the pull (turns out ``hg paths`` is what I was looking for). - -With the repository locations known I then had to perform a checkout -to a certain revision. Turns out that git will not clone a -repository to only a specific revision, although from personal -experience git's pull facility is very fast. Bzr was able to perform -its update in just over 39 seconds. Hg did its update in just over -17 seconds. Much like the log test, while the multiplier of slowness -seems high, in real life terms al DVCSs performed within reason. - -In my mind this means that bzr is only an acceptable candidate as -long as an fairly up-to-date archive of Python's key branches are -made available for people to download to avoid bzr's very so remote -branching. +.. note:: + The *bzr 1* entry is for + following the instructions in the `One-Off Checkout`_ scenario + instructions pulling from Launchpad_ in mid-January. + The *bzr 2* entry is based on following the instructions + for the `experimental Bazaar branches + <http://www.python.org/dev/bazaar/>`_ and pulling from + http://code.python.org/python/trunk/. + +When comparing these numbers to svn, it is important to realize that +it is not a 1:1 comparison. Svn does not pull down the entire revision +history like all of the DVCSs do. That means svn can perform an +initial checkout much faster than the DVCS purely based on the fact +that it has less information to worry about. + + +Performance of basic information functionality +---------------------------------------------- + +To see how the tools did for performing a command that required +querying the history, the log for the ``README`` file was timed. + +==== ===== +DVCS Time +---- ----- +bzr 4.5 s +hg 1.1 s +git 1.5 s +==== ===== + +One thing of note during this test was that git took longer than the +other three tools to figure out how to get the log without it using a +pager. While the pager use is a nice touch in general, not having it +automatically turn on took some time (turns out the main ``git`` +command has a ``--no-pager`` flag to disable use of the pager). + + +Figuring out what command to use from built-in help +---------------------------------------------------- + +I ended up trying to find out what the command was to see what URL the +repository was cloned from. To do this I used nothing more than the +help provided by the tool itself or its man pages. + +Bzr was the easiest: ``bzr info``. Running ``bzr help`` didn't show +what I wanted, but mentioned ``bzr help commands``. That list had the +command with a description that made sense. + +Git was the second easiest. The command ``git help`` didn't show much +and did not have a way of listing all commands. That is when I viewed +the man page. Reading through the various commands I discovered ``git +remote``. The command itself spit out nothing more than ``origin``. +Trying ``git remote origin`` said it was an error and printed out the +command usage. That is when I noticed ``git remote show``. Running +``git remote show origin`` gave me the information I wanted. + +For hg, I never found the information I wanted on my own. It turns out +I wanted ``hg paths``, but that was not obvious from the description +of "show definition of symbolic path names" as printed by ``hg help``. + + +Updating a checkout +--------------------- + +To see how long it takes to update an outdated repository I timed both +updating a repository 700 commits behind and 50 commits behind (three +weeks stale and 1 week stale, respectively). + +==== =========== ========== +DVCS 700 commits 50 commits +---- ----------- ---------- +bzr 39 s 7 s +hg 17 s 3 s +git N/A 4 s +==== =========== ========== + +.. note:: + Git lacks a value for the *700 commits* scenario as it does + not seem to allow checking out a repository at a specific + revision. + +Git deserves special mention for its output from ``git pull``. It +not only lists the delta change information for each file but also +color-codes the information. + + +XXX ... usage on top of svn, filling in `Coordinated Development of a +New Feature`_ scenario -XXX ... to be continued Chosen DVCS =========== XXX +:: + + import random + print(random.choice(['svn', 'bzr', 'hg', 'git'])) Transition Plan

8 11

r69038 - in python/trunk: PC/dl_nt.c Python/dynload_win.c
by mark.hammond Feb. 14, 2009

Feb. 14, 2009

Author: mark.hammond Date: Wed Jan 28 00:12:23 2009 New Revision: 69038 Log: On Windows, use the Python 'Activation Context' when loading extensions to avoid problems loading the CRT from a private assembly. Via bug 4566. Modified: python/trunk/PC/dl_nt.c python/trunk/Python/dynload_win.c Modified: python/trunk/PC/dl_nt.c ============================================================================== --- python/trunk/PC/dl_nt.c (original) +++ python/trunk/PC/dl_nt.c Wed Jan 28 00:12:23 2009 @@ -18,6 +18,63 @@ HMODULE PyWin_DLLhModule = NULL; const char *PyWin_DLLVersionString = dllVersionBuffer; +// Windows "Activation Context" work: +// Our .pyd extension modules are generally built without a manifest (ie, +// those included with Python and those built with a default distutils. +// This requires we perform some "activation context" magic when loading our +// extensions. In summary: +// * As our DLL loads we save the context being used. +// * Before loading our extensions we re-activate our saved context. +// * After extension load is complete we restore the old context. +// As an added complication, this magic only works on XP or later - we simply +// use the existence (or not) of the relevant function pointers from kernel32. +// See bug 4566 (http://python.org/sf/4566) for more details. + +typedef BOOL (WINAPI * PFN_GETCURRENTACTCTX)(HANDLE *); +typedef BOOL (WINAPI * PFN_ACTIVATEACTCTX)(HANDLE, ULONG_PTR *); +typedef BOOL (WINAPI * PFN_DEACTIVATEACTCTX)(DWORD, ULONG_PTR); +typedef BOOL (WINAPI * PFN_ADDREFACTCTX)(HANDLE); +typedef BOOL (WINAPI * PFN_RELEASEACTCTX)(HANDLE); + +// locals and function pointers for this activation context magic. +static HANDLE PyWin_DLLhActivationContext = NULL; // one day it might be public +static PFN_GETCURRENTACTCTX pfnGetCurrentActCtx = NULL; +static PFN_ACTIVATEACTCTX pfnActivateActCtx = NULL; +static PFN_DEACTIVATEACTCTX pfnDeactivateActCtx = NULL; +static PFN_ADDREFACTCTX pfnAddRefActCtx = NULL; +static PFN_RELEASEACTCTX pfnReleaseActCtx = NULL; + +void _LoadActCtxPointers() +{ + HINSTANCE hKernel32 = GetModuleHandleW(L"kernel32.dll"); + if (hKernel32) + pfnGetCurrentActCtx = (PFN_GETCURRENTACTCTX) GetProcAddress(hKernel32, "GetCurrentActCtx"); + // If we can't load GetCurrentActCtx (ie, pre XP) , don't bother with the rest. + if (pfnGetCurrentActCtx) { + pfnActivateActCtx = (PFN_ACTIVATEACTCTX) GetProcAddress(hKernel32, "ActivateActCtx"); + pfnDeactivateActCtx = (PFN_DEACTIVATEACTCTX) GetProcAddress(hKernel32, "DeactivateActCtx"); + pfnAddRefActCtx = (PFN_ADDREFACTCTX) GetProcAddress(hKernel32, "AddRefActCtx"); + pfnReleaseActCtx = (PFN_RELEASEACTCTX) GetProcAddress(hKernel32, "ReleaseActCtx"); + } +} + +ULONG_PTR _Py_ActivateActCtx() +{ + ULONG_PTR ret = 0; + if (PyWin_DLLhActivationContext && pfnActivateActCtx) + if (!(*pfnActivateActCtx)(PyWin_DLLhActivationContext, &ret)) { + OutputDebugString("Python failed to activate the activation context before loading a DLL\n"); + ret = 0; // no promise the failing function didn't change it! + } + return ret; +} + +void _Py_DeactivateActCtx(ULONG_PTR cookie) +{ + if (cookie && pfnDeactivateActCtx) + if (!(*pfnDeactivateActCtx)(0, cookie)) + OutputDebugString("Python failed to de-activate the activation context\n"); +} BOOL WINAPI DllMain (HANDLE hInst, ULONG ul_reason_for_call, @@ -29,9 +86,18 @@ PyWin_DLLhModule = hInst; // 1000 is a magic number I picked out of the air. Could do with a #define, I spose... LoadString(hInst, 1000, dllVersionBuffer, sizeof(dllVersionBuffer)); - //initall(); + + // and capture our activation context for use when loading extensions. + _LoadActCtxPointers(); + if (pfnGetCurrentActCtx && pfnAddRefActCtx) + if ((*pfnGetCurrentActCtx)(&PyWin_DLLhActivationContext)) + if (!(*pfnAddRefActCtx)(PyWin_DLLhActivationContext)) + OutputDebugString("Python failed to load the default activation context\n"); break; + case DLL_PROCESS_DETACH: + if (pfnReleaseActCtx) + (*pfnReleaseActCtx)(PyWin_DLLhActivationContext); break; } return TRUE; Modified: python/trunk/Python/dynload_win.c ============================================================================== --- python/trunk/Python/dynload_win.c (original) +++ python/trunk/Python/dynload_win.c Wed Jan 28 00:12:23 2009 @@ -11,6 +11,10 @@ #include "importdl.h" #include <windows.h> +// "activation context" magic - see dl_nt.c... +extern ULONG_PTR _Py_ActivateActCtx(); +void _Py_DeactivateActCtx(ULONG_PTR cookie); + const struct filedescr _PyImport_DynLoadFiletab[] = { #ifdef _DEBUG {"_d.pyd", "rb", C_EXTENSION}, @@ -172,6 +176,7 @@ char pathbuf[260]; LPTSTR dummy; unsigned int old_mode; + ULONG_PTR cookie = 0; /* We use LoadLibraryEx so Windows looks for dependent DLLs in directory of pathname first. However, Windows95 can sometimes not work correctly unless the absolute @@ -184,10 +189,13 @@ if (GetFullPathName(pathname, sizeof(pathbuf), pathbuf, - &dummy)) + &dummy)) { + ULONG_PTR cookie = _Py_ActivateActCtx(); /* XXX This call doesn't exist in Windows CE */ hDLL = LoadLibraryEx(pathname, NULL, LOAD_WITH_ALTERED_SEARCH_PATH); + _Py_DeactivateActCtx(cookie); + } /* restore old error mode settings */ SetErrorMode(old_mode);

2 1

r69131 - python/trunk/Doc/library/ttk.rst
by andrew.kuchling Feb. 1, 2009

Feb. 1, 2009

Author: andrew.kuchling Date: Sat Jan 31 04:26:02 2009 New Revision: 69131 Log: Text edits and markup fixes Modified: python/trunk/Doc/library/ttk.rst Modified: python/trunk/Doc/library/ttk.rst ============================================================================== --- python/trunk/Doc/library/ttk.rst (original) +++ python/trunk/Doc/library/ttk.rst Sat Jan 31 04:26:02 2009 @@ -44,9 +44,9 @@ And then several :mod:`ttk` widgets (:class:`Button`, :class:`Checkbutton`, :class:`Entry`, :class:`Frame`, :class:`Label`, :class:`LabelFrame`, :class:`Menubutton`, :class:`PanedWindow`, :class:`Radiobutton`, :class:`Scale` -and :class:`Scrollbar`) will automatically substitute the Tk widgets. +and :class:`Scrollbar`) will automatically substitute for the Tk widgets. -This has the direct benefit of using the new widgets which gives better +This has the direct benefit of using the new widgets, giving better look & feel across platforms, but you should be aware that they are not totally compatible. The main difference you will find out is that widget options such as "fg", "bg" and others related to widget styling are no @@ -57,21 +57,22 @@ `Converting existing applications to use the Tile widgets <http://tktable.sourceforge.net/tile/doc/converting.txt>`_ A text which talks in Tcl terms about differences typically found when - moving applications to use the new widgets. + converting applications to use the new widgets. Ttk Widgets ----------- -Ttk comes with 17 widgets, where 11 of these already existed in Tkinter: +Ttk comes with 17 widgets, 11 of which already exist in Tkinter: :class:`Button`, :class:`Checkbutton`, :class:`Entry`, :class:`Frame`, -:class:`Label`, :class:`LabelFrame`, :class:`Menubutton`, :class:`PanedWindow`, -:class:`Radiobutton`, :class:`Scale` and :class:`Scrollbar`. The others 6 are -new: :class:`Combobox`, :class:`Notebook`, :class:`Progressbar`, -:class:`Separator`, :class:`Sizegrip` and :class:`Treeview`. And all them are +:class:`Label`, :class:`LabelFrame`, :class:`Menubutton`, +:class:`PanedWindow`, :class:`Radiobutton`, :class:`Scale` and +:class:`Scrollbar`. The 6 new widget classes are: :class:`Combobox`, +:class:`Notebook`, :class:`Progressbar`, :class:`Separator`, +:class:`Sizegrip` and :class:`Treeview`. All of these classes are subclasses of :class:`Widget`. -Like it was told before, you will notice changes in look & feel as well in the +As said previously, you will notice changes in look-and-feel as well in the styling code. To demonstrate the latter, a very simple example is shown below. Tk code:: @@ -80,7 +81,7 @@ l2 = Tkinter.Label(text="Test", fg="black", bg="white") -Ttk code:: +Corresponding Ttk code:: style = ttk.Style() style.configure("BW.TLabel", foreground="black", background="white") @@ -101,7 +102,7 @@ Standard Options ^^^^^^^^^^^^^^^^ -All the :mod:`ttk` Widgets accepts the following options: +All the :mod:`ttk` widgets accept the following options: +-----------+--------------------------------------------------------------+ | Option | Description | @@ -110,18 +111,19 @@ | | the option database for the window's other options, to | | | determine the default bindtags for the window, and to select | | | the widget's default layout and style. This is a read-only | - | | which may only be specified when the window is created | + | | option which may only be specified when the window is | + | | created. | +-----------+--------------------------------------------------------------+ | cursor | Specifies the mouse cursor to be used for the widget. If set | | | to the empty string (the default), the cursor is inherited | - | | for the parent widget. | + | | from the parent widget. | +-----------+--------------------------------------------------------------+ | takefocus | Determines whether the window accepts the focus during | - | | keyboard traversal. 0, 1 or an empty is return. If 0 is | - | | returned, it means that the window should be skipped entirely| - | | during keyboard traversal. If 1, it means that the window | - | | should receive the input focus as long as it is viewable. And| - | | an empty string means that the traversal scripts make the | + | | keyboard traversal. 0, 1 or an empty string is returned. | + | | If 0, the window should be skipped entirely | + | | during keyboard traversal. If 1, the window | + | | should receive the input focus as long as it is viewable. | + | | An empty string means that the traversal scripts make the | | | decision about whether or not to focus on the window. | +-----------+--------------------------------------------------------------+ | style | May be used to specify a custom widget style. | @@ -137,18 +139,19 @@ +----------------+---------------------------------------------------------+ | option | description | +================+=========================================================+ - | xscrollcommand | Used to comunicate with horizontal scrollbars. | + | xscrollcommand | Used to communicate with horizontal scrollbars. | | | | - | | When the view in the widget's window change, the widget | + | | When the view in the widget's window changes, the widget| | | will generate a Tcl command based on the scrollcommand. | | | | - | | Usually this option consists of the method | - | | :meth:`Scrollbar.set` of some scrollbar. This will cause| + | | Usually this option consists of the | + | | :meth:`Scrollbar.set` method of some scrollbar. This | + | | will cause | | | the scrollbar to be updated whenever the view in the | | | window changes. | +----------------+---------------------------------------------------------+ - | yscrollcommand | Used to comunicate with vertical scrollbars. | - | | For some more information, see above. | + | yscrollcommand | Used to communicate with vertical scrollbars. | + | | For more information, see above. | +----------------+---------------------------------------------------------+ @@ -172,14 +175,14 @@ +--------------+-----------------------------------------------------------+ | image | Specifies an image to display. This is a list of 1 or more| | | elements. The first element is the default image name. The| - | | rest of the list if a sequence of statespec/value pairs as| + | | rest of the list is a sequence of statespec/value pairs as| | | defined by :meth:`Style.map`, specifying different images | | | to use when the widget is in a particular state or a | | | combination of states. All images in the list should have | | | the same size. | +--------------+-----------------------------------------------------------+ | compound | Specifies how to display the image relative to the text, | - | | in the case both text and images options are present. | + | | in the case both text and image options are present. | | | Valid values are: | | | | | | * text: display text only | @@ -190,7 +193,7 @@ | | otherwise the text. | +--------------+-----------------------------------------------------------+ | width | If greater than zero, specifies how much space, in | - | | character widths, to allocate for the text label, if less | + | | character widths, to allocate for the text label; if less | | | than zero, specifies a minimum width. If zero or | | | unspecified, the natural width of the text label is used. | +--------------+-----------------------------------------------------------+ @@ -217,27 +220,27 @@ | flag | description | +============+=============================================================+ | active | The mouse cursor is over the widget and pressing a mouse | - | | button will cause some action to occur | + | | button will cause some action to occur. | +------------+-------------------------------------------------------------+ - | disabled | Widget is disabled under program control | + | disabled | Widget is disabled under program control. | +------------+-------------------------------------------------------------+ - | focus | Widget has keyboard focus | + | focus | Widget has keyboard focus. | +------------+-------------------------------------------------------------+ - | pressed | Widget is being pressed | + | pressed | Widget is being pressed. | +------------+-------------------------------------------------------------+ | selected | "On", "true", or "current" for things like Checkbuttons and | - | | radiobuttons | + | | radiobuttons. | +------------+-------------------------------------------------------------+ | background | Windows and Mac have a notion of an "active" or foreground | | | window. The *background* state is set for widgets in a | | | background window, and cleared for those in the foreground | - | | window | + | | window. | +------------+-------------------------------------------------------------+ - | readonly | Widget should not allow user modification | + | readonly | Widget should not allow user modification. | +------------+-------------------------------------------------------------+ - | alternate | A widget-specific alternate display format | + | alternate | A widget-specific alternate display format. | +------------+-------------------------------------------------------------+ - | invalid | The widget's value is invalid | + | invalid | The widget's value is invalid. | +------------+-------------------------------------------------------------+ A state specification is a sequence of state names, optionally prefixed with @@ -248,7 +251,7 @@ ^^^^^^^^^^ Besides the methods described below, the class :class:`ttk.Widget` supports the -methods :meth:`Tkinter.Widget.cget` and :meth:`Tkinter.Widget.configure`. +:meth:`Tkinter.Widget.cget` and :meth:`Tkinter.Widget.configure` methods. .. class:: Widget @@ -264,14 +267,14 @@ Test the widget's state. If a callback is not specified, returns True if the widget state matches *statespec* and False otherwise. If callback - is specified then it is called with args if widget state matches + is specified then it is called with *args* if widget state matches *statespec*. .. method:: state([statespec=None]) - Modify or inquire widget state. If *statespec* is specified, sets the - widget state according to it and return a new *statespec* indicating + Modify or read widget state. If *statespec* is specified, sets the + widget state accordingly and returns a new *statespec* indicating which flags were changed. If *statespec* is not specified, returns the currently-enabled state flags. @@ -284,39 +287,40 @@ The :class:`ttk.Combobox` widget combines a text field with a pop-down list of values. This widget is a subclass of :class:`Entry`. -Besides the methods inherited from :class:`Widget`: :meth:`Widget.cget`, +Besides the methods inherited from :class:`Widget` (:meth:`Widget.cget`, :meth:`Widget.configure`, :meth:`Widget.identify`, :meth:`Widget.instate` -and :meth:`Widget.state`, and the following inherited from :class:`Entry`: -:meth:`Entry.bbox`, :meth:`Entry.delete`, :meth:`Entry.icursor`, +and :meth:`Widget.state`) and those inherited from :class:`Entry` +(:meth:`Entry.bbox`, :meth:`Entry.delete`, :meth:`Entry.icursor`, :meth:`Entry.index`, :meth:`Entry.inset`, :meth:`Entry.selection`, -:meth:`Entry.xview`, it has some other methods, described at +:meth:`Entry.xview`), this class has some other methods, described at :class:`ttk.Combobox`. Options ^^^^^^^ -This widget accepts the following specific options: +This widget accepts the following options: +-----------------+--------------------------------------------------------+ | option | description | +=================+========================================================+ | exportselection | Boolean value. If set, the widget selection is linked | | | to the Window Manager selection (which can be returned | - | | by invoking Misc.selection_get, for example). | + | | by invoking :meth:`Misc.selection_get`, for example). | +-----------------+--------------------------------------------------------+ | justify | Specifies how the text is aligned within the widget. | | | One of "left", "center", or "right". | +-----------------+--------------------------------------------------------+ | height | Specifies the height of the pop-down listbox, in rows. | +-----------------+--------------------------------------------------------+ - | postcommand | A script (possibly registered with Misc.register) that | + | postcommand | A script (possibly registered with | + | | :meth:`Misc.register`) that | | | is called immediately before displaying the values. It | | | may specify which values to display. | +-----------------+--------------------------------------------------------+ | state | One of "normal", "readonly", or "disabled". In the | | | "readonly" state, the value may not be edited directly,| - | | and the user can only selection of the values from the | + | | and the user can only select one of the values from the| | | dropdown list. In the "normal" state, the text field is| | | directly editable. In the "disabled" state, no | | | interaction is possible. | @@ -338,7 +342,7 @@ Virtual events ^^^^^^^^^^^^^^ -The combobox widgets generates a **<<ComboboxSelected>>** virtual event +The combobox widget generates a **<<ComboboxSelected>>** virtual event when the user selects an element from the list of values. @@ -367,7 +371,7 @@ Notebook -------- -Ttk Notebook widget manages a collection of windows and displays a single +The Ttk Notebook widget manages a collection of windows and displays a single one at a time. Each child window is associated with a tab, which the user may select to change the currently-displayed window. @@ -385,12 +389,12 @@ | | Otherwise, the maximum height of all panes is used. | +---------+----------------------------------------------------------------+ | padding | Specifies the amount of extra space to add around the outside | - | | of the notebook. The padding is a list up to four length | - | | specifications left top right bottom. If fewer than four | + | | of the notebook. The padding is a list of up to four length | + | | specifications: left top right bottom. If fewer than four | | | elements are specified, bottom defaults to top, right defaults | | | to left, and top defaults to left. | +---------+----------------------------------------------------------------+ - | width | If present and greater than zero, specified the desired width | + | width | If present and greater than zero, specifies the desired width | | | of the pane area (not including internal padding). Otherwise, | | | the maximum width of all panes is used. | +---------+----------------------------------------------------------------+ @@ -424,7 +428,7 @@ | | image described in :class:`Widget`. | +-----------+--------------------------------------------------------------+ | compound | Specifies how to display the image relative to the text, in | - | | the case both options text and image are present. See | + | | the case both text and image options are present. See | | | `Label Options`_ for legal values. | +-----------+--------------------------------------------------------------+ | underline | Specifies the index (0-based) of a character to underline in | @@ -437,15 +441,15 @@ Tab Identifiers ^^^^^^^^^^^^^^^ -The tab_id present in several methods of :class:`ttk.Notebook` may take any +The *tab_id* present in several methods of :class:`ttk.Notebook` may take any of the following forms: -* An integer between zero and the number of tabs -* The name of a child window -* A positional specification of the form "@x,y", which identifies the tab -* The literal string "current", which identifies the currently-selected tab +* An integer between zero and the number of tabs. +* The name of a child window. +* A positional specification of the form "@x,y", which identifies the tab. +* The literal string "current", which identifies the currently-selected tab. * The literal string "end", which returns the number of tabs (only valid for - :meth:`Notebook.index`) + :meth:`Notebook.index`). Virtual Events

2 1

r69158 - python/trunk/Python/compile.c
by benjamin.peterson Jan. 31, 2009

Jan. 31, 2009

Author: benjamin.peterson Date: Sun Feb 1 00:54:38 2009 New Revision: 69158 Log: more flags which only work for function blocks Modified: python/trunk/Python/compile.c Modified: python/trunk/Python/compile.c ============================================================================== --- python/trunk/Python/compile.c (original) +++ python/trunk/Python/compile.c Sun Feb 1 00:54:38 2009 @@ -3794,13 +3794,11 @@ flags |= CO_NESTED; if (ste->ste_generator) flags |= CO_GENERATOR; + if (ste->ste_varargs) + flags |= CO_VARARGS; + if (ste->ste_varkeywords) + flags |= CO_VARKEYWORDS; } - if (ste->ste_varargs) - flags |= CO_VARARGS; - if (ste->ste_varkeywords) - flags |= CO_VARKEYWORDS; - if (ste->ste_generator) - flags |= CO_GENERATOR; /* (Only) inherit compilerflags in PyCF_MASK */ flags |= (c->c_flags->cf_flags & PyCF_MASK);

1 0

buildbot failure in amd64 gentoo trunk
by buildbot＠python.org Jan. 31, 2009

Jan. 31, 2009

The Buildbot has detected a new failure of amd64 gentoo trunk. Full details are available at: http://www.python.org/dev/buildbot/all/amd64%20gentoo%20trunk/builds/1782 Buildbot URL: http://www.python.org/dev/buildbot/all/ Buildslave for this Build: norwitz-amd64 Build Reason: Build Source Stamp: [branch trunk] HEAD Blamelist: david.goodger,gregory.p.smith BUILD FAILED: failed failed slave lost sincerely, -The Buildbot

1 0

buildbot failure in x86 gentoo 2.6
by buildbot＠python.org Jan. 31, 2009

Jan. 31, 2009

The Buildbot has detected a new failure of x86 gentoo 2.6. Full details are available at: http://www.python.org/dev/buildbot/all/x86%20gentoo%202.6/builds/84 Buildbot URL: http://www.python.org/dev/buildbot/all/ Buildslave for this Build: norwitz-x86 Build Reason: Build Source Stamp: [branch branches/release26-maint] HEAD Blamelist: benjamin.peterson BUILD FAILED: failed test Excerpt from the test logfile: sincerely, -The Buildbot

1 0

r69157 - python/trunk/Python/compile.c
by benjamin.peterson Jan. 31, 2009

Jan. 31, 2009

Author: benjamin.peterson Date: Sun Feb 1 00:43:25 2009 New Revision: 69157 Log: add explanatory comment Modified: python/trunk/Python/compile.c Modified: python/trunk/Python/compile.c ============================================================================== --- python/trunk/Python/compile.c (original) +++ python/trunk/Python/compile.c Sun Feb 1 00:43:25 2009 @@ -3769,6 +3769,8 @@ return NULL; while (PyDict_Next(dict, &pos, &k, &v)) { i = PyInt_AS_LONG(v); + /* The keys of the dictionary are tuples. (see compiler_add_o) + The object we want is always first, though. */ k = PyTuple_GET_ITEM(k, 0); Py_INCREF(k); assert((i - offset) < size);

1 0

buildbot failure in sparc solaris10 gcc 3.x
by buildbot＠python.org Jan. 31, 2009

Jan. 31, 2009

The Buildbot has detected a new failure of sparc solaris10 gcc 3.x. Full details are available at: http://www.python.org/dev/buildbot/all/sparc%20solaris10%20gcc%203.x/builds… Buildbot URL: http://www.python.org/dev/buildbot/all/ Buildslave for this Build: loewis-sun Build Reason: Build Source Stamp: [branch branches/py3k] HEAD Blamelist: benjamin.peterson BUILD FAILED: failed test Excerpt from the test logfile: 2 tests failed: test_distutils test_posix ====================================================================== FAIL: test_get_python_inc (distutils.tests.test_sysconfig.SysconfigTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/distutils/tests/test_sysconfig.py", line 43, in test_get_python_inc self.assert_(os.path.isdir(inc_dir), inc_dir) AssertionError: /home2/buildbot/slave/3.x.loewis-sun/build/(a)test.getcwd/Include ====================================================================== ERROR: test_getcwd_long_pathnames (test.test_posix.PosixTester) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test_posix.py", line 252, in test_getcwd_long_pathnames support.rmtree(base_path) File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/support.py", line 98, in rmtree shutil.rmtree(path) File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/shutil.py", line 225, in rmtree onerror(os.rmdir, path, sys.exc_info()) File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/shutil.py", line 223, in rmtree os.rmdir(path) OSError: [Errno 22] Invalid argument: '/home2/buildbot/slave/3.x.loewis-sun/build/@test.getcwd/@test.getcwd' sincerely, -The Buildbot

1 0

buildbot failure in ia64 Ubuntu 3.x
by buildbot＠python.org Jan. 31, 2009

Jan. 31, 2009

The Buildbot has detected a new failure of ia64 Ubuntu 3.x. Full details are available at: http://www.python.org/dev/buildbot/all/ia64%20Ubuntu%203.x/builds/195 Buildbot URL: http://www.python.org/dev/buildbot/all/ Buildslave for this Build: klose-debian-ia64 Build Reason: Build Source Stamp: [branch branches/py3k] HEAD Blamelist: benjamin.peterson BUILD FAILED: failed test Excerpt from the test logfile: 1 test failed: test_epoll make: *** [buildbottest] Error 1 sincerely, -The Buildbot

1 0

buildbot failure in amd64 gentoo 3.x
by buildbot＠python.org Jan. 31, 2009

Jan. 31, 2009

The Buildbot has detected a new failure of amd64 gentoo 3.x. Full details are available at: http://www.python.org/dev/buildbot/all/amd64%20gentoo%203.x/builds/150 Buildbot URL: http://www.python.org/dev/buildbot/all/ Buildslave for this Build: norwitz-amd64 Build Reason: Build Source Stamp: [branch branches/py3k] HEAD Blamelist: benjamin.peterson BUILD FAILED: failed failed slave lost sincerely, -The Buildbot

1 0