Phillip J. Eby wrote:
> At 12:37 AM 1/12/2007 +1000, Nick Coghlan wrote:
>> ...a utility which is also known as contextlib.nested().
>>
>> For some strange reason, I suspect you're familiar with that
>> particular context manager ;)
>
> Not that I recall, no, otherwise I'd have used the name. I
On 1/11/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 03:42 PM 1/11/2007 -0600, Collin Winter wrote:
> >On 1/11/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >>At 03:33 PM 1/11/2007 -0500, Terry Reedy wrote:
> >> >Yes, I already see it that way. It would be nice if the rule for 'as'
> >> >t
At 03:42 PM 1/11/2007 -0600, Collin Winter wrote:
>On 1/11/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>At 03:33 PM 1/11/2007 -0500, Terry Reedy wrote:
>> >Yes, I already see it that way. It would be nice if the rule for 'as'
>> >targets were as consistent as possible (ie, at least the same for
On 1/11/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 03:33 PM 1/11/2007 -0500, Terry Reedy wrote:
> >Yes, I already see it that way. It would be nice if the rule for 'as'
> >targets were as consistent as possible (ie, at least the same for except
> >and with)
>
> No can do - with needs tuple
At 03:33 PM 1/11/2007 -0500, Terry Reedy wrote:
>Yes, I already see it that way. It would be nice if the rule for 'as'
>targets were as consistent as possible (ie, at least the same for except
>and with)
No can do - with needs tuples, except isn't getting them.
If we did allow tuples in both cas
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| The case for changing 'for' is weakest, for sure.
As I understand the proposal, the rationale for restricting the exception
target is the autodeletion, which is obviously bug-prone if applied to
pre-existing struc
The case for changing 'for' is weakest, for sure. But 'with' is easy
to coerce into the same category as 'import' and 'except' since it
already uses 'as'...
On 1/11/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 08:36 AM 1/11/2007 -0800, Guido van Rossum wrote:
> >Let me clarify. I have no des
At 08:36 AM 1/11/2007 -0800, Guido van Rossum wrote:
>Let me clarify. I have no desire to prevent tuple assignment in with
>statements. But I do think that the tuples could be limited to plain
>names and other tuples (with similar constraints), and those names
>should all be zapped at the end of th
Let me clarify. I have no desire to prevent tuple assignment in with
statements. But I do think that the tuples could be limited to plain
names and other tuples (with similar constraints), and those names
should all be zapped at the end of the clause, like for except. And we
don't even have to add
At 12:37 AM 1/12/2007 +1000, Nick Coghlan wrote:
>Phillip J. Eby wrote:
>>At 07:47 AM 1/10/2007 -0800, Guido van Rossum wrote:
>>>BTW perhaps we should add the same semantics and syntax to 'with expr
>>>as var'? I can't think of a reasonable use case
>>[snip]
>>>... for using anything
>>>more compl
Phillip J. Eby wrote:
> At 07:47 AM 1/10/2007 -0800, Guido van Rossum wrote:
>> BTW perhaps we should add the same semantics and syntax to 'with expr
>> as var'? I can't think of a reasonable use case
> [snip]
>> ... for using anything
>> more complex than a local variable, BTW.)
>
> with multi(ct
"Greg Falcon" <[EMAIL PROTECTED]> wrote:
[snip]
> Per these rules:
> On 1/7/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > > On 1/4/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > > > except ExcType, e:
> > > > try:
> > > > # body
> > > > finally:
> > >
Some very good points made here.
On 1/10/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Yeah, I like reusing the variable names bound in a for loop. And unless
> we are going to attempt to simplify the in...
>
> for in ...:
> ...
>
> to only be a bare name, and not things like 'i,
On 1/10/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 1/10/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > re = get_resource()
> ...
> > except RareException as re:
> ...
> > re.use_resource()
>
> > So 're = None; del re;' is *only* executed if the except body is executed.
>
> So re.u
At 12:05 PM 1/10/2007 -0500, Greg Falcon wrote:
>I'm coming from a philosophy, though, that believes any time a
>syntactic construct creates a local binding and a new suite to use it
>in, the binding shouldn't escape that suite. Yes, I'm really talking
>about 'for', and I know this is probably a c
On 1/10/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> Phillip came up the translation, I just implemented it. ...
> re = get_resource()
...
> except RareException as re:
...
> re.use_resource()
> So 're = None; del re;' is *only* executed if the except body is executed.
So re.use_re
On 1/10/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> According to the translation rules Colin has previously provided...
>
> re = get_resource()
> ...
> try:
> something()
> except RareException as re:
> ...
> ...
> re.use_resource()
>
> is translated into
At 07:47 AM 1/10/2007 -0800, Guido van Rossum wrote:
>BTW perhaps we should add the same semantics and syntax to 'with expr
>as var'? I can't think of a reasonable use case
[snip]
>... for using anything
>more complex than a local variable, BTW.)
with multi(ctx1, ctx2, ...) as var1, var2, ...:
(
On 1/10/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> According to the translation rules Colin has previously provided...
Phillip came up the translation, I just implemented it.
> re = get_resource()
> ...
> try:
> something()
> except RareException as re:
> ...
"Greg Falcon" <[EMAIL PROTECTED]> wrote:
[snip]
> I'm coming from a philosophy, though, that believes any time a
> syntactic construct creates a local binding and a new suite to use it
> in, the binding shouldn't escape that suite. Yes, I'm really talking
> about 'for', and I know this is probabl
Well, now I have to delurk.
I've been watching with growing excitement. Between the changes to
the scope rules for list comprehensions, and this change for except
blocks, I wondered if Python might have been moving in the direction
of block scoped variables where appropriate as a philosophy.
I a
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
> At 10:00 PM 1/9/2007 -0800, Josiah Carlson wrote:
[snip]
> Please provide what you'd put in the reference manual as an explanation of
> this behavior. (Remember: if the implementation is hard to explain...)
If the name to the right of the 'as' keywo
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
> On 1/9/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > I know that one of the points of all of this is so that the name that
> > the exc_info() stuff gets in the local scope doesn't propagate past the
> > except clause, but I can't help feeling
On 1/9/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> I know that one of the points of all of this is so that the name that
> the exc_info() stuff gets in the local scope doesn't propagate past the
> except clause, but I can't help feeling as if removing the name isn't a
> little overenthusiastic.
At 10:00 PM 1/9/2007 -0800, Josiah Carlson wrote:
>I know that one of the points of all of this is so that the name that
>the exc_info() stuff gets in the local scope doesn't propagate past the
>except clause,
That is the *entire* point of this, actualy. :) (Well, the "as" change
was supposed t
"Collin Winter" <[EMAIL PROTECTED]> wrote:
> On 1/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 1/8/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > > FWIW, I wasn't aware that things like "except T, (a, b, c):" were
> > > possible until I started work on this patch; I thought was all
On 1/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 1/8/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > FWIW, I wasn't aware that things like "except T, (a, b, c):" were
> > possible until I started work on this patch; I thought was all
> > you _could_ use.
>
> And, given the secial seman
On 1/9/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> That seems fine for 2.x, but 3.x should have Only One Way To Do It. 2.x
> needs both syntaxes to support writing forward-compatible code.
Really? I personally expect that that's a lost cause. A much more
modest goal would be to write code tha
At 08:10 AM 1/10/2007 +1100, Tim Delaney wrote:
>Guido van Rossum wrote:
>
> > On 1/8/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> >> FWIW, I wasn't aware that things like "except T, (a, b, c):" were
> >> possible until I started work on this patch; I thought was all
> >> you _could_ use.
> >
>
Guido van Rossum wrote:
> On 1/8/07, Collin Winter <[EMAIL PROTECTED]> wrote:
>> FWIW, I wasn't aware that things like "except T, (a, b, c):" were
>> possible until I started work on this patch; I thought was all
>> you _could_ use.
>
> And, given the secial semantics for this position, I would s
On 1/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> And, given the secial semantics for this position, I would support
> changing the syntax to *only* allow a single simple name there -- not
> even x.y.z. Thsh should handle 99.9% of existing code anyway.
>
> (And yes, if someone wants to add t
On 1/8/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> FWIW, I wasn't aware that things like "except T, (a, b, c):" were
> possible until I started work on this patch; I thought was all
> you _could_ use.
And, given the secial semantics for this position, I would support
changing the syntax to *on
I seem to recall
> that Guido wanted to move to an 'as' clause for Py3K anyway, to avoid the
> "except FooExc, BarExc:" anti-pattern. So now seems as good a time "as"
> any. :)
http://mail.python.org/pipermail/python-dev/2006-March/062449.html
http://mail.python.org/pipermail/python-dev/2006-
At 11:34 AM 1/8/2007 -0600, Collin Winter wrote:
>On 1/8/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>At 10:25 AM 1/8/2007 -0600, Collin Winter wrote:
>> >On 1/8/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>> >>At 09:14 PM 1/7/2007 -0600, Collin Winter wrote:
>> >> >The transformation is as Ph
On 1/8/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 10:25 AM 1/8/2007 -0600, Collin Winter wrote:
> >On 1/8/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >>At 09:14 PM 1/7/2007 -0600, Collin Winter wrote:
> >> >The transformation is as Phillip outlined above, with extra logic to
> >> >handl
At 10:25 AM 1/8/2007 -0600, Collin Winter wrote:
>On 1/8/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>At 09:14 PM 1/7/2007 -0600, Collin Winter wrote:
>> >The transformation is as Phillip outlined above, with extra logic to
>> >handle the case where e is a tuple or list.
>>
>>In the tuple or lis
On 1/8/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:14 PM 1/7/2007 -0600, Collin Winter wrote:
> >The transformation is as Phillip outlined above, with extra logic to
> >handle the case where e is a tuple or list.
>
> In the tuple or list case, there's no need to reset the variables, becau
At 09:14 PM 1/7/2007 -0600, Collin Winter wrote:
>On 1/4/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 1/4/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > > How about:
> > >
> > > except ExcType, e:
> > > try:
> > > # body
> > > finally:
> > >
On 1/7/07, Collin Winter <[EMAIL PROTECTED]> wrote:
On 1/4/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 1/4/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > How about:
> >
> > except ExcType, e:
> > try:
> > # body
> > finally:
> > e
On 1/4/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 1/4/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > How about:
> >
> > except ExcType, e:
> > try:
> > # body
> > finally:
> > e = None
> > del e
> >
> > Then we get the
tomer filiba <[EMAIL PROTECTED]> wrote:
> it ought to have at least a nicer API, for instance,
> tbtext = traceback.format_current()
Do you know about traceback.format_exc()? I think I added it for
2.4.
Neil
___
Python-3000 mailing list
Python-3000@
At 12:18 AM 1/5/2007 +0100, Malte Helmert wrote:
>Phillip J. Eby wrote:
> > Heck, you could even say the translation is:
> >
> > except ExcType:
> > e = sys.exception # or whatever it's called in 3K
> > try:
> > # body
> > finally:
> >
On 1/4/07, tomer filiba <[EMAIL PROTECTED]> wrote:
> [Guido]
> > The use case I am guessing from your example (passing a
> > traceback as a single string across an RPC boundary) isn't all that
> > common and you ought to have only one place in your RPC package where
> > you need to call it.
>
> *th
On 1/4/07, Neil Toronto <[EMAIL PROTECTED]> wrote:
Guido van Rossum wrote:
> On 1/4/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>
>> At 01:41 AM 1/4/2007 -0600, Ka-Ping Yee wrote:
>>
>>> How about this?
>>>
>>> except ExcType, e:
>>> try:
>>> # body
>>> fina
[Guido]
> The use case I am guessing from your example (passing a
> traceback as a single string across an RPC boundary) isn't all that
> common and you ought to have only one place in your RPC package where
> you need to call it.
*this* use-case isn't that useful, true. but many times, frameworks
Guido van Rossum wrote:
> On 1/4/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>
>> At 01:41 AM 1/4/2007 -0600, Ka-Ping Yee wrote:
>>
>>> How about this?
>>>
>>> except ExcType, e:
>>> try:
>>> # body
>>> finally:
>>> e = None
>>>
>> I
On 1/4/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 01:41 AM 1/4/2007 -0600, Ka-Ping Yee wrote:
> >How about this?
> >
> > except ExcType, e:
> > try:
> > # body
> > finally:
> > e = None
>
> It's a little bit more difficult to explain in the r
[Tomer]
> > > as well as
> > > traceback.format_exception (which i greatly dislike).
[Guido]
> > Why? Because it once insulted you?
[Tomer]
> because it's tedious, repetitive and unreadable.
>
> try:
> foo
> except:
> import traceback
> import sys
> tbtext = "".join(traceback.form
[Guido]
> > as well as
> > traceback.format_exception (which i greatly dislike).
>
> Why? Because it once insulted you?
because it's tedious, repetitive and unreadable.
try:
foo
except:
import traceback
import sys
tbtext = "".join(traceback.format_exception(*sys.exc_info()))
r
At 01:41 AM 1/4/2007 -0600, Ka-Ping Yee wrote:
>How about this?
>
> except ExcType, e:
> try:
> # body
> finally:
> e = None
It's a little bit more difficult to explain in the reference manual. I was
figuring we'd say that the exception variable i
On 1/3/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>Or perhaps translate blocks of the form:
>
> except ExcType, e:
> # body
>
>to:
>
> except ExcType, e:
> try:
> # body
> finally:
> del e
That's much nicer! (I feel silly now for n
At 09:11 PM 1/3/2007 -0800, Guido van Rossum wrote:
>On 1/3/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>Or perhaps translate blocks of the form:
>>
>> except ExcType, e:
>> # body
>>
>>to:
>>
>> except ExcType, e:
>> try:
>> # body
>> finally:
>
On 1/3/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Or perhaps translate blocks of the form:
>
> except ExcType, e:
> # body
>
> to:
>
> except ExcType, e:
> try:
> # body
> finally:
> del e
>
> This won't stop you from creating a cy
At 07:38 PM 1/3/2007 -0800, Guido van Rossum wrote:
>On 1/3/07, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> > On Wed, 3 Jan 2007, Adam Olsen wrote:
> > > That can be solved by moving the weakref to the stack frame -> exc
> > > part, and only turning it from a strong reference into a weak
> > > referen
On 1/3/07, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> On Wed, 3 Jan 2007, Adam Olsen wrote:
> > That can be solved by moving the weakref to the stack frame -> exc
> > part, and only turning it from a strong reference into a weak
> > reference when the function exits. When debugging via the raised
>
On Wed, 3 Jan 2007, Adam Olsen wrote:
> That can be solved by moving the weakref to the stack frame -> exc
> part, and only turning it from a strong reference into a weak
> reference when the function exits. When debugging via the raised
> exception, the chain of __context__ references would keep
On 1/2/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 1/1/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > will introduce a cycle from err -> traceback -> stack frame -> err,
> The problem with a weakref is that it won't keep the tb alive when you
> save the exception for later (as is
On 1/2/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 1/2/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > On 1/1/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > I believe the main argument *against*
> > This should probably be made explicit in PEP 344.
> Feel free to send a patch to me
On 1/2/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 1/1/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > I believe the main argument *against* having the tb included in the
> > exception is that it would greatly increase the cyclic nature of
> > tracebacks and stack frames, which in turn wou
On 1/1/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I believe the main argument *against* having the tb included in the
> exception is that it would greatly increase the cyclic nature of
> tracebacks and stack frames, which in turn would cause lots of code to
> break due to late GC'ing of unc
On 1/1/07, tomer filiba <[EMAIL PROTECTED]> wrote:
> a while back some people suggested having the traceback
> as an attribute of the exception object, which allows for
> nested exceptions.
PEP 344, to be precise.
> i would also like to note that having the traceback part of
> the exception objec
tomer filiba wrote:
> this makes sys.excepthook unnecessary
Maybe I'm stating the obvious here, but I override sys.excepthook in
real-world code. If you want it go away for some reason, I guess you should
propose a replacement with similar semantic.
--
Giovanni Bajo
__
a while back some people suggested having the traceback
as an attribute of the exception object, which allows for
nested exceptions.
i would also like to note that having the traceback part of
the exception object allows the exception to print itself,
i.e., its repr would format the traceback text
63 matches
Mail list logo
