[Python-Dev] Exception and ABCs / issue #12029
As per http://bugs.python.org/issue12029 , ABC registration cannot be used for exceptions. This was introduced in a commit that fixed a recursion limit problem back in 2008 (http://hg.python.org/cpython/rev/d6e86a96f9b3/#l8.10). This was later fixed in a different way and improved upon in the 2.x branch in http://hg.python.org/cpython/rev/7e86fa255fc2 and http://hg.python.org/cpython/rev/57de1ad15c54 respectively. Applying the fix from the 2.x branch for doesn't make any tests fail, and it fixes the problem described in the bug report. There are, however, two questions about this: * Is this a feature, or a bug? I would say that it's a bug, but even if it's not, it has to be documented, since one generally assumes that it will work. * Even so, is it worth fixing, considering the limited use cases for it? This slows exception type checking 3 times. I added a new test to pybench: before: TryRaiseExceptClass: 25ms 25ms0.39us0.216ms after: TryRaiseExceptException: 31ms 31ms0.48us0.214ms However, that doesn't tell the whole story, since there's overhead from raising the exception. In order to find out how much actually checking slows down the checking, I ran three timeits, with the following code: 1) try: raise ValueError() except NameError: pass except NameError: pass except ValueError: pass 2) try: raise ValueError() except NameError: pass except ValueError: pass 3) try: raise ValueError() except ValueError: pass Times are in ms: before after 1 528.69 825.38 2 473.73 653.39 3 416.29 496.80 avgdiff 56.23 164.29 The numbers don't change significantly for more exception tests. -- George-Cristian Bîrzan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
On 5/11/2012 2:21 AM, Mark Shannon wrote: Nick Coghlan wrote: The question now moves to the implementation strategy - whether we redirect to the C machinery as originally proposed (either via __build_class__ or a new _types module) or just reimplement the algorithm in pure Python. The latter is actually quite an appealing concept, since it becomes a cross-check on the native C version. I assume types.new_class would eventually call type(). This would make it available to any implementation with a conforming type(). +1 to a pure Python version. Since new_class would be used rarely and not in inner loops, and (if I understand) should mostly contain branching logic rather than looping, speed hardly seems an issue. --- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
On Fri, 11 May 2012 10:16:42 -0400, Terry Reedy wrote: > On 5/11/2012 2:21 AM, Mark Shannon wrote: > > +1 to a pure Python version. > > Since new_class would be used rarely and not in inner loops, and (if I > understand) should mostly contain branching logic rather than looping, > speed hardly seems an issue. Well, actually, the proposed new email policy is doing dynamic class construction for any header accessed by the application, which could potentially be every header in every message processed by an application if refold_source is set true. That's not quite an "inner loop", but it isn't an outer one either. That said, the header parsing logic that is also invoked by the process of returning a header under the new policy is going to outweigh the class construction overhead, I'm pretty sure. --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2012-05-04 - 2012-05-11) 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: open3418 (+19) closed 23143 (+42) total 26561 (+61) Open issues with patches: 1460 Issues opened (38) == #13815: tarfile.ExFileObject can't be wrapped using io.TextIOWrapper http://bugs.python.org/issue13815 reopened by r.david.murray #14724: kill imp.load_dynamic's third argument http://bugs.python.org/issue14724 opened by pitrou #14728: trace function not set, causing some Pdb commands to fail http://bugs.python.org/issue14728 opened by xdegaye #14730: Implementation of the PEP 419: Protecting cleanup statements f http://bugs.python.org/issue14730 opened by tailhook #14731: Enhance Policy framework in preparation for adding email6 poli http://bugs.python.org/issue14731 opened by r.david.murray #14732: PEP 3121 Refactoring applied to _csv module http://bugs.python.org/issue14732 opened by Robin.Schreiber #14733: Custom commands don't work http://bugs.python.org/issue14733 opened by LEW21 #14734: Use binascii.b2a_qp/a2b_qp in email package header handling? http://bugs.python.org/issue14734 opened by r.david.murray #14735: Version 3.2.3 IDLE CTRL-Z plus Carriage Return to end does not http://bugs.python.org/issue14735 opened by ewodrich #14739: Add PyArg_Parse format unit like O& but providing context http://bugs.python.org/issue14739 opened by larry #14742: test_tools very slow http://bugs.python.org/issue14742 opened by pitrou #14743: on terminating, Pdb debugs itself http://bugs.python.org/issue14743 opened by xdegaye #14744: Use _PyUnicodeWriter API in str.format() internals http://bugs.python.org/issue14744 opened by haypo #14747: Classifiers are missing from distutils2-generated metadata http://bugs.python.org/issue14747 opened by agronholm #14748: spwd.getspall() is returning LDAP (non local) users too http://bugs.python.org/issue14748 opened by halfie #14750: Tkinter application doesn't run from source build on Windows http://bugs.python.org/issue14750 opened by vinay.sajip #14751: Pdb does not stop at a breakpoint http://bugs.python.org/issue14751 opened by xdegaye #14755: Distutils2 doesn't have a Python 3 version on PyPI http://bugs.python.org/issue14755 opened by njwilson #14757: INCA: Inline Caching meets Quickening in Python 3.3 http://bugs.python.org/issue14757 opened by sbrunthaler #14758: SMTPServer of smptd does not support binding to an IPv6 addres http://bugs.python.org/issue14758 opened by vsergeev #14759: BSDDB license missing from liscense page in 2.7. http://bugs.python.org/issue14759 opened by Jeff.Laing #14766: Non-naive time comparison throws naive time error http://bugs.python.org/issue14766 opened by Chris.Bergstresser #14767: urllib.request.HTTPRedirectHandler raises HTTPError when Locat http://bugs.python.org/issue14767 opened by jspenguin #14769: Add test to automatically detect missing format units in skipi http://bugs.python.org/issue14769 opened by larry #14770: Minor documentation fixes http://bugs.python.org/issue14770 opened by michael.foord #14771: Occasional failure in test_ioctl http://bugs.python.org/issue14771 opened by pitrou #14772: Return destination values in some shutil functions http://bugs.python.org/issue14772 opened by brian.curtin #14773: fwalk breaks on dangling symlinks http://bugs.python.org/issue14773 opened by hynek #14774: _sysconfigdata.py doesn't support multiple build configuration http://bugs.python.org/issue14774 opened by dmalcolm #14775: Slow unpickling of certain dictionaries in python 2.7 vs pytho http://bugs.python.org/issue14775 opened by stw #14776: Add SystemTap static markers http://bugs.python.org/issue14776 opened by dmalcolm #14777: Tkinter clipboard_get() decodes characters incorrectly http://bugs.python.org/issue14777 opened by takluyver #14778: IrrationalVersionError should include the project name http://bugs.python.org/issue14778 opened by njwilson #14779: test_buffer fails on OS X universal 64-/32-bit builds http://bugs.python.org/issue14779 opened by ned.deily #14780: SSL should use OpenSSL-defined default certificate store if ca http://bugs.python.org/issue14780 opened by jfunk #14781: Default to year 1 in strptime if year 0 has been specified http://bugs.python.org/issue14781 opened by Matthias.Meyer #14782: Tabcompletion of classes with static methods and __call__ has http://bugs.python.org/issue14782 opened by wpettersson #14783: Update int() docstring from manual http://bugs.python.org/issue14783 opened by terry.reedy Most recent 15 issues with no replies (15) == #14783: Update int() docstring from manual http://bugs.python.org/issue14783 #14782: Tabcompletion of classes with static methods and __call__ has http://bugs.python.org/issue14782 #14773: fwal
Re: [Python-Dev] Exception and ABCs / issue #12029
Thanks for bringing this up. I've added my opinion to the tracker issue -- I think it's a bug and should be fixed. We should have a uniform way of checking for issubclass/isinstance. --Guido On Fri, May 11, 2012 at 3:33 AM, George-Cristian Bîrzan wrote: > As per http://bugs.python.org/issue12029 , ABC registration cannot be > used for exceptions. This was introduced in a commit that fixed a > recursion limit problem back in 2008 > (http://hg.python.org/cpython/rev/d6e86a96f9b3/#l8.10). This was later > fixed in a different way and improved upon in the 2.x branch in > http://hg.python.org/cpython/rev/7e86fa255fc2 and > http://hg.python.org/cpython/rev/57de1ad15c54 respectively. > > Applying the fix from the 2.x branch for doesn't make any tests fail, > and it fixes the problem described in the bug report. There are, > however, two questions about this: > > * Is this a feature, or a bug? I would say that it's a bug, but even > if it's not, it has to be documented, since one generally assumes that > it will work. > * Even so, is it worth fixing, considering the limited use cases for > it? This slows exception type checking 3 times. I added a new test to > pybench: > > before: > TryRaiseExceptClass: 25ms 25ms 0.39us 0.216ms > after: > TryRaiseExceptException: 31ms 31ms 0.48us 0.214ms > > However, that doesn't tell the whole story, since there's overhead > from raising the exception. In order to find out how much actually > checking slows down the checking, I ran three timeits, with the > following code: > > 1) > try: raise ValueError() > except NameError: pass > except NameError: pass > except ValueError: pass > > 2) > try: raise ValueError() > except NameError: pass > except ValueError: pass > > 3) > try: raise ValueError() > except ValueError: pass > > Times are in ms: > before after > 1 528.69 825.38 > 2 473.73 653.39 > 3 416.29 496.80 > avgdiff 56.23 164.29 > > The numbers don't change significantly for more exception tests. > > -- > George-Cristian Bîrzan > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On Thu, May 10, 2012 at 3:39 PM, Steven D'Aprano wrote: >> Aye. Add a rule that all implementation specific (i.e. not defined in >> the PEP) keys must be prefixed with an underscore and I'm sold. > > > So now we're adding a new convention to single underscore names? Single > underscore names are implementation-specific details that you shouldn't use > or rely on, except in sys.implementation, where they are an optional part of > the public interface. I've always seen _names as less implementation details and more 'here be dragons; tread carefully'. I don't think adding a different convention really changes that at all. The underscore ones would (mostly) be implementation-specific anyway. _clr_version is something only IronPython is going to have, for example. If more than one implementation has something it can be promoted to a non-underscore name, but I think that will be rare. Some of the suggested metadata (like vcs_revision and build date) could actually be required right out of the gate, and cache_tag should be optional. - Jeff ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
The specific reason cache_tag is mandatory is so that importlib can rely on it. Setting it to None for a given implementation will automatically disable caching of bytecode files. -- Sent from my phone, thus the relative brevity :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On Thu, May 10, 2012 at 2:57 AM, Antoine Pitrou wrote: > sys.implementation.metadata looks like a completely over-engineered > concept. Please, let's just make sys.implementation a dict and stop > bothering about ordering and iterability. I'm fine with ditching "metadata". The PEP will say sys.implementation must have the required attributes and leave it at that. However, my preference is still for dotted access rather than a dict. The type doesn't really matter to me otherwise. Immutability isn't a big concern nor is sequence-ness. I'll tone the type discussion accordingly. If anyone has strong feelings for item-access over attribute-access, please elaborate. I'm just not seeing it as that important and would rather finish up the PEP as simply as possible. -eric ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
