Benjamin Peterson wrote:
2012/1/26 Ethan Furman et...@stoneleaf.us:
PEP: XXX
Congratulations, you are now PEP 409.
Thanks, Benjamin!
So, how do I make changes to it?
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
For those not on the nosy list, here's the latest post
to http://bugs.python.org/issue6210:
---
It looks like agreement is forming around the
raise ... from None
method. It has been mentioned more than once that having the context
Am 29.01.2012 08:42, schrieb Ethan Furman:
Benjamin Peterson wrote:
2012/1/26 Ethan Furman et...@stoneleaf.us:
PEP: XXX
Congratulations, you are now PEP 409.
Thanks, Benjamin!
So, how do I make changes to it?
Please send PEP updates to the PEP editors at p...@python.org.
Georg
Latest addition for PEP 409 has been sent. Text follows:
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
On Mon, Jan 30, 2012 at 2:51 PM, Ethan Furman et...@stoneleaf.us wrote:
raise ... from ... is not disallowed outside a try block, but this
behavior is not guaranteed to remain.
--
Should that last disclaimer be there? Should it
Nick Coghlan wrote:
On Sat, Jan 28, 2012 at 10:33 AM, Ethan Furman et...@stoneleaf.us wrote:
So the question is:
- should 'raise ... from ...' be legal outside a try block?
- should 'raise ... from None' be legal outside a try block?
Given that it would be quite a bit of work to make it
2012/1/26 Ethan Furman et...@stoneleaf.us:
PEP: XXX
Congratulations, you are now PEP 409.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Guido van Rossum wrote:
Did you consider to just change the
words so users can ignore it more easily?
Yes, that has also been discussed.
Speaking for myself, it would be only slightly better.
Speaking for everyone that wants context suppression (using Steven
D'Aprano's words): chained
On Fri, Jan 27, 2012 at 9:08 AM, Ethan Furman et...@stoneleaf.us wrote:
Guido van Rossum wrote:
Did you consider to just change the
words so users can ignore it more easily?
Yes, that has also been discussed.
Speaking for myself, it would be only slightly better.
Speaking for everyone
On 1/27/2012 2:54 PM, Guido van Rossum wrote:
On Fri, Jan 27, 2012 at 9:08 AM, Ethan Furmanet...@stoneleaf.us wrote:
Guido van Rossum wrote:
Did you consider to just change the
words so users can ignore it more easily?
Yes, that has also been discussed.
Speaking for myself, it would be
Terry Reedy wrote:
On 1/27/2012 2:54 PM, Guido van Rossum wrote:
On Fri, Jan 27, 2012 at 9:08 AM, Ethan Furmanet...@stoneleaf.us wrote:
Guido van Rossum wrote:
Did you consider to just change the
words so users can ignore it more easily?
Yes, that has also been discussed.
Speaking for
Terry Reedy wrote:
The PEP does not address the issue of whether the new variation of raise
is valid outside of an except block. My memory is that it was not to be
and I think it should not be. One advantage of the 'as' form is that it
is clear that raising the default as something else is
On Sat, Jan 28, 2012 at 10:33 AM, Ethan Furman et...@stoneleaf.us wrote:
Because at this point it is possible to do:
raise ValueError from NameError
outside a try block. I don't see it as incredibly useful, but I don't know
that it's worth making it illegal.
So the question is:
-
On Jan 26, 2012, at 7:19 PM, Ethan Furman wrote:
One of the open issues from PEP 3134 is suppressing context: currently there
is no way to do it. This PEP proposes one.
Thanks for proposing fixes to this issue.
It is an annoying problem.
Raymond
PEP: XXX
Title: Interpreter support for concurrent programming
Version: $Revision$
Last-Modified: $Date$
Author: Ethan Furman et...@stoneleaf.us
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
On Jan 26, 2012, at 10:54 PM, Benjamin Peterson wrote:
2012/1/26 Ethan Furman et...@stoneleaf.us:
PEP: XXX
Title: Interpreter support for concurrent programming
mm?
Version: $Revision$
Last-Modified: $Date$
Author: Ethan Furman et...@stoneleaf.us
Status: Draft
Type: Standards Track
Benjamin Peterson wrote:
2012/1/26 Ethan Furman et...@stoneleaf.us:
PEP: XXX
Title: Interpreter support for concurrent programming
mm?
Oops!
Version: $Revision$
Last-Modified: $Date$
Author: Ethan Furman et...@stoneleaf.us
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
2012/1/26 Ethan Furman et...@stoneleaf.us:
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
On Fri, Jan 27, 2012 at 1:54 PM, Benjamin Peterson benja...@python.org 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
On Thu, Jan 26, 2012 at 9:18 PM, Nick Coghlan ncogh...@gmail.com 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
20 matches
Mail list logo
