Wiadomość napisana przez Georg Brandl w dniu 23 sty 2012, o godz. 21:18:
> Am 23.01.2012 15:49, schrieb Łukasz Langa:
>
> [graphics]
>> Pomyśl o środowisku naturalnym zanim wydrukujesz tę wiadomość!
>> Please consider the environment before printing out this e-mail.
>
> Oh please?!
Excuse me.
Am 23.01.2012 15:49, schrieb Łukasz Langa:
[graphics]
> Pomyśl o środowisku naturalnym zanim wydrukujesz tę wiadomość!
> Please consider the environment before printing out this e-mail.
Oh please?!
Georg
___
Python-Dev mailing list
Python-Dev@python.o
Wiadomość napisana przez Ethan Furman w dniu 20 sty 2012, o godz. 21:05:The problem I have with 'raise x from None' is it puts 'from None' clear at the end of linefrom None raise SomeOtherError('etc.')Better yet:with nocontext(): raise SomeOtherError('etc.')But that's python-ideas territory ;)-- Be
On 1/20/2012 7:40 PM, Steven D'Aprano wrote:
Benjamin Peterson wrote:
2012/1/20 Terry Reedy :
Since 'raise' means 're-raise the current error', 'raise as OtherError'
means (clearly to me, anyway) 're-raise the current error as
OtherError'.
That doesn't make any sense. You're changing the exce
Ethan Furman wrote:
The question I have at the moment is: should `raise as` be an error if
no exception is currently being handled?
I think so.
"raise as Spam" essentially means "raise Spam with the context set to None".
That's actually only useful if the context otherwise wouldn't be None,
Benjamin Peterson wrote:
2012/1/20 Terry Reedy :
Since 'raise' means 're-raise the current error', 'raise as OtherError'
means (clearly to me, anyway) 're-raise the current error as OtherError'.
That doesn't make any sense. You're changing the exception completely
not reraising it.
I expect
2012/1/20 Terry Reedy :
> Since 'raise' means 're-raise the current error', 'raise as OtherError'
> means (clearly to me, anyway) 're-raise the current error as OtherError'.
That doesn't make any sense. You're changing the exception completely
not reraising it.
--
Regards,
Benjamin
_
Georg Brandl wrote:
Well, the "as" in "raise as" would be very easily overlooked too.
In any case, I don't think the context suppression is the most important
thing about the exception raising, so it doesn't need to stand out...
Good point.
___
Pyth
Since 'raise' means 're-raise the current error', 'raise as OtherError'
means (clearly to me, anyway) 're-raise the current error as
OtherError'. This is just what you want to be able to say. Since 'raise'
without a current error results in a TypeError, so should 'raise as
OtherError'. I would
Am 20.01.2012 21:05, schrieb Ethan Furman:
> Benjamin Peterson wrote:
>> 2012/1/20 Ethan Furman :
>>> Summary:
>>>
>>> Exception Chaining is cool, unless you are writing libraries that want to
>>> transform from Exception X to Exception Y as the the previous exception
>>> context is unnecessary, po
2012/1/20 Ethan Furman :
> Benjamin Peterson wrote:
>>
>> 2012/1/20 Ethan Furman :
>>>
>>> Summary:
>>>
>>> Exception Chaining is cool, unless you are writing libraries that want to
>>> transform from Exception X to Exception Y as the the previous exception
>>> context is unnecessary, potentially c
Benjamin Peterson wrote:
2012/1/20 Ethan Furman :
Summary:
Exception Chaining is cool, unless you are writing libraries that want to
transform from Exception X to Exception Y as the the previous exception
context is unnecessary, potentially confusing, and cluttery (yup, just made
that word up!)
2012/1/20 Ethan Furman :
> Summary:
>
> Exception Chaining is cool, unless you are writing libraries that want to
> transform from Exception X to Exception Y as the the previous exception
> context is unnecessary, potentially confusing, and cluttery (yup, just made
> that word up!).
>
> For all the
Summary:
Exception Chaining is cool, unless you are writing libraries that want
to transform from Exception X to Exception Y as the the previous
exception context is unnecessary, potentially confusing, and cluttery
(yup, just made that word up!).
For all the gory details, see http://bugs.pyt
Nick Coghlan wrote:
A toy example,
that isn't obviously broken at first glance, but in fact fails when
close() is called:
Okay, you've convinced me. I'll consider it to be correct
behaviour and update my expected yield-from test results
accordingly.
--
Greg
___
Antoine Pitrou wrote:
It only happens if you call close() explicitly:
Well, that's only because the exception is being ignored and
you're not getting a traceback at all.
If you arrange to get a traceback, the same thing happens.
import traceback as tb
def g():
try:
try:
On Sun, Aug 1, 2010 at 1:25 PM, Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> I don't see it as an implementation detail - it's part of the spec of
>> generator finalisation in PEP 342
>
> It doesn't seem like something you need to know in this
> situation, though. All it tells you is that the fina
On Sun, 01 Aug 2010 13:01:32 +1200
Greg Ewing wrote:
> While updating my yield-from impementation for Python
> 3.1.2, I came across a quirk in the way that the new
> exception chaining feature interacts with generators.
>
> If you close() a generator, and it raises an exception
> inside a finally
Nick Coghlan wrote:
I don't see it as an implementation detail - it's part of the spec of
generator finalisation in PEP 342
It doesn't seem like something you need to know in this
situation, though. All it tells you is that the finalisation
is happening because the generator is being closed ra
On Sun, Aug 1, 2010 at 11:01 AM, Greg Ewing wrote:
> While updating my yield-from impementation for Python
> 3.1.2, I came across a quirk in the way that the new
> exception chaining feature interacts with generators.
>
> If you close() a generator, and it raises an exception
> inside a finally cl
While updating my yield-from impementation for Python
3.1.2, I came across a quirk in the way that the new
exception chaining feature interacts with generators.
If you close() a generator, and it raises an exception
inside a finally clause, you get a double-barrelled
traceback that first reports
21 matches
Mail list logo
