Mailman 3 February 2012 - Python-Dev

Summary of Python tracker Issues
by Python tracker Feb. 3, 2012

Feb. 3, 2012

ACTIVITY SUMMARY (2012-01-27 - 2012-02-03) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 3248 (+14) closed 22466 (+29) total 25714 (+43) Open issues with patches: 1392 Issues opened (30) ================== #13892: distutils handling of windows manifest isn't optimal http://bugs.python.org/issue13892 opened by jackjansen #13893: Make … [View More]

1 0

Python 3 optimizations, continued, continued again...
by stefan brunthaler Feb. 3, 2012

Feb. 3, 2012

Hi guys, while there is at least some interest in incorporating my optimizations, response has still been low. I figure that the changes are probably too much for a single big incorporation step. On a recent flight, I thought about cutting it down to make it more easily digestible. The basic idea is to remove the optimized interpreter dispatch loop and advanced instruction format and use the existing ones. Currently (rev. ca8a0dfb2176), opcode.h uses 109 of potentially available 255 … [View More]

11 23

open issues on accepted PEPs
by Ethan Furman Feb. 2, 2012

Feb. 2, 2012

I was looking at the other Open Issues on PEP 3134, think I might try to resolve them as well, and discovered via testing that they have already been taken care of. Is there an established way to get information like that? I realize that PEPs are partly historical documents, but it would it make sense to add a note after an Open Issue (or any other section) that was refined, resolved, or whatever in a later PEP or bug or patch or ...* ~Ethan~ *Yes, I am volunteering to tackle that project.

2 2

Switching to Visual Studio 2010
by "Martin v. Löwis" Feb. 1, 2012

Feb. 1, 2012

It seems a number of people are interested that the Python trunk switches to Visual Studio 2010 *now*. I've been hesitant to agree to such a change, as I still hope that Python can skip over VS 2010 (a.k.a. VS 10), and go straight to VS 11. However, I just learned that VS 11 supposed ready VS 10 project files just fine, with no need of conversion. So I'd be willing to agree to converting the Python trunk now. It will surely cause all kinds of issues, as any switching of Visual Studio … [View More]

5 12

docs fixes and PEP 409
by Ethan Furman Jan. 31, 2012

Jan. 31, 2012

I'm looking at the docs to make the relevant changes due to PEP 409, and I'm noticing some problems. E.g. The PyException_Get|Set_Context|Cause all talk about using NULL to clear the related attribute, when actually in should be Py_None. Only PyException_GetCause is directly related to PEP 409 -- should I only fix that one, and open up a new issue on the tracker for the other three, or should I fix all four now? ~Ethan~

2 2

PEP 409 - now properly formatted (sorry for the noise)
by Ethan Furman Jan. 31, 2012

Jan. 31, 2012

PEP: 409 Title: Suppressing exception context Version: $Revision$ Last-Modified: $Date$ Author: Ethan Furman <ethan(a)stoneleaf.us> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 26-Jan-2012 Post-History: 30-Aug-2002, 01-Feb-2012 Abstract ======== One of the open issues from PEP 3134 is suppressing context: currently there is no way to do it. This PEP proposes one. Rationale ========= There are two basic ways to generate exceptions: 1) Python does it (… [View More]buggy code, missing resources, ending loops, etc.) 2) manually (with a raise statement) When writing libraries, or even just custom classes, it can become necessary to raise exceptions; moreover it can be useful, even necessary, to change from one exception to another. To take an example from my dbf module:: try: value = int(value) except Exception: raise DbfError(...) Whatever the original exception was (``ValueError``, ``TypeError``, or something else) is irrelevant. The exception from this point on is a ``DbfError``, and the original exception is of no value. However, if this exception is printed, we would currently see both. Alternatives ============ Several possibilities have been put forth: * ``raise as NewException()`` Reuses the ``as`` keyword; can be confusing since we are not really reraising the originating exception * ``raise NewException() from None`` Follows existing syntax of explicitly declaring the originating exception * ``exc = NewException(); exc.__context__ = None; raise exc`` Very verbose way of the previous method * ``raise NewException.no_context(...)`` Make context suppression a class method. All of the above options will require changes to the core. Proposal ======== I proprose going with the second option:: raise NewException from None It has the advantage of using the existing pattern of explicitly setting the cause:: raise KeyError() from NameError() but because the 'cause' is ``None`` the previous context, while retained, is not displayed by the default exception printing routines. Language Details ================ Currently, ``__context__`` and ``__cause__`` start out as None, and then get set as exceptions occur. To support ``from None``, ``__context__`` will stay as it is, but ``__cause__`` will start out as ``False``, and will change to ``None`` when the ``raise ... from None`` method is used. The default exception printing routine will then: * If ``__cause__`` is ``False`` the ``__context__`` (if any) will be printed. * If ``__cause__`` is ``None`` the ``__context__`` will not be printed. * if ``__cause__`` is anything else, ``__cause__`` will be printed. This has the benefit of leaving the ``__context__`` intact for future logging, querying, etc., while suppressing its display if it is not caught. This is important for those times when trying to debug poorly written libraries with `bad error messages`_. Patches ======= There is a patch for CPython implementing this attached to `Issue 6210`_. References ========== Discussion and refinements in this `thread on python-dev`_. .. _bad error messages: http://bugs.python.org/msg152294 .. _Issue 6210: http://bugs.python.org/issue6210 .. _thread on python-dev: http://mail.python.org/pipermail/python-dev/2012-January/115838.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: [View Less]

1 1