Re: [Python-Dev] [Python-ideas] Coroutines and PEP 380
Nick Coghlan wrote: (redirecting to python-ideas - coroutine proposals are nowhere near mature enough for python-dev) On Wed, Jan 25, 2012 at 5:35 PM, Matt Joiner wrote: If someone can explain what's stopping real coroutines being into Python (3.3), that would be great. The general issues with that kind of idea: - the author hasn't offered the code for inclusion and relicensing under the PSF license (thus we legally aren't allowed to do it) If by the author you mean me, then of course it can be included. Since it is a fork of CPython and I haven't changed the licence I assumed it already was under the PSF licence. - complexity - maintainability Hard to measure, but it adds about 200 lines of code. - platform support Its all fully portable standard C. In the specific case of coroutines, you have the additional hurdle of convincing people whether or not they're a good idea at all. That may well be the biggest obstacle :) One other obstacle (and this may be a killer) is that it may not be practical to refactor Jython to use coroutines since Jython compiles Python direct to JVM bytecodes and the JVM doesn't support coroutines. Jython should be able to support yield-from much more easily. Cheers, Mark. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switching to Visual Studio 2010
On Tue, Jan 17, 2012 at 15:11, Brian Curtin wrote: > On Tue, Jan 17, 2012 at 15:01, "Martin v. Löwis" wrote: >>> I previously completed the port at my old company (but could not >>> release it), and I have a good bit of it completed for us at >>> http://hg.python.org/sandbox/vs2010port/. That repo is a little bit >>> behind 'default' but updating it shouldn't pose any problems. >> >> So: do you agree that we switch? Do you volunteer to drive the change? > > I do, and I'll volunteer. Is this considered a new feature that has to be in by the first beta? I'm hoping to have it completed much sooner than that so we can get mileage on it, but is there a cutoff for changing the compiler? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switching to Visual Studio 2010
Is this considered a new feature that has to be in by the first beta? I'm hoping to have it completed much sooner than that so we can get mileage on it, but is there a cutoff for changing the compiler? At some point, I'll start doing this myself if it hasn't been done by then, and I would certainly want the build process adjusted (with all buildbots updated) before beta 1. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP for allowing 'raise NewException from None'
PEP: XXX Title: Interpreter support for concurrent programming Version: $Revision$ Last-Modified: $Date$ Author: Ethan Furman Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 26-Jan-2012 Python-Version: 3.3 Post-History: Abstract One of the open issues from PEP 3134 is suppressing context: currently there is no way to do it. This PEP proposes one. Motivation == There are two basic ways to generate exceptions: 1) Python does it (buggy code, missing resources, ending loops, etc.); and, 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 is discarded. There is a patch to this effect attached to Issue6210 (http://bugs.python.org/issue6210). 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: ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for allowing 'raise NewException from None'
2012/1/26 Ethan Furman : > PEP: XXX > Title: Interpreter support for concurrent programming mm? > Version: $Revision$ > Last-Modified: $Date$ > Author: Ethan Furman > Status: Draft > Type: Standards Track > Content-Type: text/x-rst > Created: 26-Jan-2012 > Python-Version: 3.3 > Post-History: BTW, I don't really think this needs a PEP. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for allowing 'raise NewException from None'
On Jan 26, 2012, at 10:54 PM, Benjamin Peterson wrote: >2012/1/26 Ethan Furman : >> PEP: XXX >> Title: Interpreter support for concurrent programming > >mm? > >> Version: $Revision$ >> Last-Modified: $Date$ >> Author: Ethan Furman >> Status: Draft >> Type: Standards Track >> Content-Type: text/x-rst >> Created: 26-Jan-2012 >> Python-Version: 3.3 >> Post-History: > >BTW, I don't really think this needs a PEP. I think a PEP is appropriate, but the title is certainly misnamed. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for allowing 'raise NewException from None'
Benjamin Peterson wrote: 2012/1/26 Ethan Furman : PEP: XXX Title: Interpreter support for concurrent programming mm? Oops! Version: $Revision$ Last-Modified: $Date$ Author: Ethan Furman Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 26-Jan-2012 Python-Version: 3.3 Post-History: BTW, I don't really think this needs a PEP. I was surprised, but Nick seems to think it is. If somebody could fix that oopsie, and any others ;) and then commit it (if necessary) I would appreciate it. ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for allowing 'raise NewException from None'
2012/1/26 Ethan Furman : >> BTW, I don't really think this needs a PEP. Obviously it doesn't hurt. And I see from the issue that the change was not as uncontroversial as I originally thought, so it's likely for the better. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for allowing 'raise NewException from None'
On Fri, Jan 27, 2012 at 1:54 PM, Benjamin Peterson wrote:
> BTW, I don't really think this needs a PEP.
That's largely my influence - the discussion in the relevant tracker
item (http://bugs.python.org/issue6210) had covered enough ground that
I didn't notice that Ethan's specific proposal *isn't* a syntax
change, but is rather just a matter of giving some additional
semantics to the "raise X from Y" syntax (some of the other
suggestions like "raise as " really were syntax changes).
So I've changed my mind to being +1 on the idea and proposed syntax of
the draft PEP, but I think there are still some details to be worked
through in terms of the detailed semantics. (The approach in Ethan's
patch actually *clobbers* the context info when "from None" is used,
and I don't believe that's a good idea. My own suggestions in the
tracker item aren't very good either, for exactly the same reason)
Currently, the raise from syntax is just syntactic sugar for setting
__cause__ manually:
>>> try:
... 1/0
... except ZeroDivisionError as ex:
... new_exc = ValueError("Denominator is zero")
... new_exc.__cause__ = ex
... raise new_exc
...
Traceback (most recent call last):
File "", line 2, in
ZeroDivisionError: division by zero
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "", line 6, in
ValueError: Denominator is zero
The context information isn't lost in that case, the display of it is
simply suppressed when an explicit cause is set:
>>> try:
... try:
... 1/0
... except ZeroDivisionError as ex:
... new_exc = ValueError()
... new_exc.__cause__ = ex
... raise new_exc
... except ValueError as ex:
... saved = ex
...
>>> saved.__context__
ZeroDivisionError('division by zero',)
>>> saved.__cause__
ZeroDivisionError('division by zero',)
This behaviour (i.e. preserving the context, but not displaying it by
default) is retained when using the dedicated syntax:
>>> try:
... try:
... 1/0
... except ZeroDivisionError as ex:
... raise ValueError() from ex
... except ValueError as ex:
... saved = ex
...
>>> saved.__context__
ZeroDivisionError('division by zero',)
>>> saved.__cause__
ZeroDivisionError('division by zero',)
However, if you try to set the __cause__ to None explicitly, then the
display falls back to showing the context:
>>> try:
... 1/0
... except ZeroDivisionError as ex:
... new_exc = ValueError("Denominator is zero")
... new_exc.__cause__ = None
... raise new_exc
...
Traceback (most recent call last):
File "", line 2, in
ZeroDivisionError: division by zero
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "", line 6, in
ValueError: Denominator is zero
This happens because None is used by the exception display logic to
indicate "no specific cause, so report the context if that is set".
My proposal would be that instead of using None as the "not set"
sentinel value for __cause__, we instead use a dedicated sentinel
object (exposed to Python at least as "BaseException().__cause__", but
potentially being given its own name somewhere).
Then the display logic for exceptions would be changed to be:
- if the __cause__ is None, then don't report a cause or exception
context at all
- if the __cause__ is BaseException().__cause__, report the exception
context (from __context__)
- otherwise report __cause__ as the specific cause of the raised exception
That way we make it easy to emit nicer default tracebacks when
replacing exceptions without completely hiding the potentially useful
data that can be provided by retaining information in __context__.
I've been burnt by too much code that replaces detailed, informative
and useful error messages that tell me exactly what is going wrong
with bland, useless garbage to be in favour of an approach that
doesn't even set the __context__ attribute in the first place. If
__context__ is always set regardless, and then __cause__ is used to
control whether or not __context__ gets displayed in the standard
tracebacks, that's a much more flexible approach.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for allowing 'raise NewException from None'
On Thu, Jan 26, 2012 at 9:18 PM, Nick Coghlan wrote: > I've been burnt by too much code that replaces detailed, informative > and useful error messages that tell me exactly what is going wrong > with bland, useless garbage to be in favour of an approach that > doesn't even set the __context__ attribute in the first place. Ditto here. > If __context__ is always set regardless, and then __cause__ is used > to control whether or not __context__ gets displayed in the standard > tracebacks, that's a much more flexible approach. Well, but usually all you see is the printed traceback, so it might as well be lost, right? (It gives full control to programmatic handlers, of course, but that's usually not where the problem lies. It's when things go horribly wrong in the hash function and all you see in the traceback is a lousy KeyError. :-) Did you consider to just change the words so users can ignore it more easily? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [issue13703] Hash collision security issue
On 1/26/2012 10:25 PM, Gregory P. Smith wrote: (and on top of all of this I believe we're all settled on having per interpreter hash randomization_as well_ in 3.3; but this AVL tree approach is one nice option for a backport to fix the major vulnerability) If the tree code cures the problem, then randomization just makes debugging harder. I think if it is included in 3.3, it needs to have a switch to turn it on/off (whichever is not default). I'm curious why AVL tree rather than RB tree, simpler implementation? C++ stdlib includes RB tree, though, for even simpler implementation :) Can we have a tree type in 3.3, independent of dict? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
