Exaggeration in defense of elegance is no vice.wink
Maybe not, but it still sounds like BS to me.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
block argument, or perhaps yieldn.
:-)
--
--Guido van Rossum (home page: http://www.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
the solution with a generator and block-statement.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
:
in EXPR for VAR:
BLOCK
If you don't need the variable, you can leave the for VAR part out:
in EXPR:
BLOCK
Too cute? :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
to be shared with the containing
function,
Agreed. We'd need to add a STORE_CELL bytecode or
something for this.
This actually exists -- it is used for when an outer function stores
into a local that it shares with an inner function.
--
--Guido van Rossum (home page: http://www.python.org/~guido
you get out of it depends on what you put into it. :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
is a new namespace,
and that's exactly what a block (by whichever name) is *not*.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
, and I expect that by the time
you've figured out a mechanism, thunks aren't all that simple any
more.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
, if
there were no convincing argument for either, I still like block
much better -- perhaps because suite is the technical term used all
over the grammar.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
with
explaining when the else-clause is executed, because it's too dynamic.
It does solve one problem with option 2 though: if there's no
else-clause, and ElseIteration is raised, that could become an error
rather than being ignored silently.
--
--Guido van Rossum (home page: http://www.python.org
-statement.
There are still a few loose ends left, including the alternative API
that you've proposed (which I'm not super keen on, to be sure, but
which is still open for consideration).
--
--Guido van Rossum (home page: http://www.python.org/~guido
using err...
So I'm more than ever in favor of keeping the block-statement simple,
i.e. without any additional clauses.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
benefit.
Unless there's more discussion on any of these, I'll probably finish
up the PEP and post it to c.l.py in a few days.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
mean?
--
--Guido van Rossum (home page: http://www.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
of logic error; it can never happen when the generator is
called by a block statement.
I'll update the PEP to reflect this.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
Python under supervision of gdb
and trap it that way.
But tell me, what do you want the process to do instead of
terminating? Py_FatalError is used in situations where raising an
exception is impossible or would do more harm than good.
--
--Guido van Rossum (home page: http://www.python.org/~guido
finally:
sys.stdout = save_stdout
--
--Guido van Rossum (home page: http://www.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
in the
standard library.
--
--Guido van Rossum (home page: http://www.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
thought. It doesn't exactly mean still undecided but more depends
on your POV. I'll use something different, and also clarify that as
far as break/continue are concerned, it *is* a loop.
--
--Guido van Rossum (home page: http://www.python.org/~guido
return fn (*args, **kwargs)
finally:
sys.stdout = save_stdout
return redirect
return captured_stream
o=StringIO()
@saving_stdout(o)
...
This has absolutely nothing to recommend it.
--
--Guido van Rossum (home page: http
sense of) code readability here not about implementation.
Hm... Maybe you also want to have separate function and procedure
keywords? Or static typing? 'def' can be used to define all sorts of
things, that is Python's beauty!
--
--Guido van Rossum (home page: http://www.python.org/~guido
code is there in the field?
Written by whom?
I suppose you can always write a decorator that takes care of the
mapping. I suppose it should catch and ignore the StopIteration that
__exit__(StopIteration) is likely to throw.
--
--Guido van Rossum (home page: http://www.python.org/~guido
://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
middle ground didn't work out so well.
On 5/3/05, Guido van Rossum [EMAIL PROTECTED] wrote:
[Jim Jewett]
...
With the block, every yield returns to a single designated callback.
This callback had to be established at the same time the block was
created, and must be textually inside
:
# __exit__() didn't
raise RuntimeError(or some other exception)
I'd like the block statement to be defined exclusively in terms of
__exit__() though.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python
On 5/3/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 04:41 PM 5/3/05 -0700, Guido van Rossum wrote:
Given all that, it's not infeasible to add a close() method to
generators as a shortcut for this:
def close(self):
try:
self.__exit__(StopIteration
think I knew Java -- certainly I
didn't know it well enough to realize that it gives this construct the
meaning proposed by Reinhold's PEP.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
. But please only if there is broad agreement on
something.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
that should Google for do-loop. :-)
I wonder how many folks call their action methods do() though.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
identifier.
--
--Guido van Rossum (home page: http://www.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
with that
code? Perhaps it ought to be rewritten as
f = action1()
try:
...
finally:
action2(f)
I can't see how this would ever do something different than your version.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python
[me]
I can't see how this would ever do something different than your version.
[Reinhold]
Well, in the original the call to action1 was wrapped in an additional
try-except
block.
Ah. Francois was misquoting it.
--
--Guido van Rossum (home page: http://www.python.org/~guido
, but that may
make it harder to spot the change)
Yeah, but that will stop working in Python 3.0. I like the solution
that puts a bare raise at the top of the except clause.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev
by stating that it's not
countering those items nor repeating them.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
not even sure that if we reach agreement on python-dev there's any
point in repeating the agony on c.l.py.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
.
--
--Guido van Rossum (home page: http://www.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
this
(plus continue EXPR which will be moved to a separate PEP once I
have some extra time) than most of the other proposals.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
that IOError here is untouched by Wrapper
yield f
f.close() # Ditto for errors here (however unlikely)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
case. Anyway, a wrapped
generator wrapper can't do with all those distinctions unless we
augment the generator somehow (continue EXPR would suffice).
(Your decorator is equivalent to mine, but I don't like creating a new
class each time.)
--
--Guido van Rossum (home page: http://www.python.org
[Timothy Fitz]
A more flexible approach would be to allow finally at the beginning or
ending of the try statement. A more flexible approach would be to
allow both, or even finally clauses mixed in.
-1000.
--
--Guido van Rossum (home page: http://www.python.org/~guido
distinguish between non-local gotos
(break/continue/return), exceptions, and normal completion of BLOCK.
(I'm not sure that this is really different from (3).)
What do you think?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev
stops an exception from propagating outward
is worth an explicit try/except clause, so the reader knows what is
happening.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
lines (the use) in isolation doesn't
give me an idea of what happens when the 3rd attempt fails. Here,
EIBTI.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
in the modified PEP 310 proposal.
Plus I think the use cases are much weaker (even PEP 340 doesn't have
many use cases for exception handling -- the only one is the
auto-retry example).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python
want to see how nastly documenting try/except/finally can get. And
they don't even have an else clause! ;-)
Fine with me.
Can I go ahead and approve this now before someone proposes to add a
new keyword?
--
--Guido van Rossum (home page: http://www.python.org/~guido
VAR = itr.__enter__()
try: BLOCK
finally: itr.__exit__(*sys.exc_info()) # Except sys.exc_info() isn't
defined by finally
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
Can I go ahead and approve this now
While I see the cost of this PEP being pretty small, I see the benefit
the same way too.
Sure. Let me approve it and we'll see if someone cares enough to implement it.
--
--Guido van Rossum (home page: http://www.python.org/~guido
traction (at least not with me
:-).
--Guido van Rossum (home page: http://www.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
van Rossum (home page: http://www.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
in value.traceback.
I proposed the same thing a while back (during the early hours of
writing PEP 340).
It won't fly as long as we have string exceptions (since there's
nowhere to put the traceback) but once those are dead I like it a lot.
--
--Guido van Rossum (home page: http://www.python.org/~guido
exception handling code and somehow a bug in the
handler (or an uncooperative environment, e.g. a full disk) causes the
exception handling code to trip over an exception.
I'm fairly certain (but not 100%) that Ping meant to include both use cases.
--
--Guido van Rossum (home page: http
all
in one PEP.
--
--Guido van Rossum (home page: http://www.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
greppable?
And is *args also frowned upon?
--
--Guido van Rossum (home page: http://www.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
these,
but I think it ought to for the purposes of this proposal.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
attaching the outer exception to each
exception raised.
Yes, though i did not expect to provide any mechanism for distinguishing
the two cases. Do you think such a mechanism would be necessary?
No, I was just trying to figure out what you meant when you said
raise. It's clear now.
--
--Guido van
anything wrong with your implementation of
combining either), but even if that existed I think I'd prefer to just
write
with opening(src_fn) as src:
with opening(dst_fn) as dst:
copy(src, dst)
See Ma, no magic! :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido
traceback
which was shy enough to make repeating it a pain.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
more challenging to switch to the model
where all exceptions derive from a single (new-style) base class.
(And no, there are no plans to kill classic classes before 3.0 either.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python
: block signals for
the duration of a block. This could be a function in the signal
module, e.g. signal.blocking([ist of signals to block]). The list
would default to all signals. Similar signal.ignoring().
--
--Guido van Rossum (home page: http://www.python.org/~guido
bound by the construct.
Nevertheless, I think I actually like this argument!
(Repeated for the benefit of others.)
Straight up-or-down votes in the full senate are appreciated at this point.
+1 for the PEP 340 variant.
--
--Guido van Rossum (home page: http://www.python.org/~guido
() returns.
--
--Guido van Rossum (home page: http://www.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
Eby. I do want to pass the
exception into __exit__ so that it can be logged, for example.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
[Nick Coghlan]
The ban on yielding inside try/finally will need to be extended to yielding
inside user defined statements until such time as an iterator finalisation
protocol is chosen, though.
Ah! Good point. This breaks PEP 340 example 5. No big deal, but worth noting.
--
--Guido van
[Guido van Rossum]
Cons:
- slightly less simple (__enter__ must return something for VAR;
__exit__ takes optional args)
[Fredrik Lundh]
what happened to the original yield the target object solution? or did
I just dream that?
Don't worry, that works when you use a generator. It just
[Guido van Rossum]
So then the all-important question I want to pose is: do we like the
idea of using a (degenerate, decorated) generator as a template for
the do-statement enough to accept the slightly increased complexity?
[Greg Ewing]
I can't see how this has anything to do with whether
a standard module defining a do_template
decorator that turns a degenerate generator into a do-statement
controller.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
.
--
--Guido van Rossum (home page: http://www.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
statements, allowing the above to be written naturally with try/finally.
Let's not try to tie this to other features. I tried that with PEP 340
and you know the mess it became. :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python
counterproposals (e.g. Nick Coghlan's PEP 3XX or the proposals that
make every keyword associated with 'try' a method).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
, it's also possible that Nick did *not* mean for the missing
raise to be there. But in that case other claims from his PEP become
false, so I'm assuming with Steven here. Nick?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python
including the return.
I don't want to manipulate signals directly in the VM; it's
platform-specific, expensive, rarely needed, and you never know
whether you aren't invoking some Python code that might do I/O, making
the entire thread uninterruptible for a long time.
--
--Guido van Rossum (home
it should say print line.)
--
--Guido van Rossum (home page: http://www.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
__exit__
can take a single exception argument from the start. (But what should
it receive if a string exception is being caught? A triple perhaps?)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
(or a tuple value) is invalid in the curernt
proposal. So I'd rather punt on this.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
them system attributes is
more backwards compatible.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
to me.
--
--Guido van Rossum (home page: http://www.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
[Guido van Rossum]
My rule has more to do with who owns the namespace on the one hand,
and with magic behavior caused (or indicated) by the presence of the
attribute on the other. Class or instance is irrelevant; that most
magic attributes live on classes or modules is just because those
when the exception is raised, would be too expensive for
exceptions raised *and* caught somewhere deep.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
[Guido van Rossum]
I'm in favor of the general idea, but would like to separate the error
injection and finalization API for generators into a separate PEP,
which would then compete with PEP 288 and PEP 325.
[Nick Coghlan]
Without that it pretty much devolves into the current version
@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
will end up being.
Greg
___
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/guido%40python.org
--
--Guido van Rossum (home page
of the current context would be sufficient.
--
--Guido van Rossum (home page: http://www.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
()
newctx = oldctx.copy()
decimal.setcontext(newctx)
yield newctx
decimal.setcontext(oldctx)
To be used like this:
do with_decimal_context() as ctx:
ctx.prec += 2
# change other settings
# algorithm goes here
--
--Guido van Rossum (home page: http://www.python.org
of introspection). So I think the PEP should
continue to use __traceback__ etc.
On 5/17/05, Greg Ewing [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
Unfortunately I can't quite decide whether either rule applies in the
case of exceptions.
I think you'd at least be justified in using
also propose
to go with the alternative in PEP 342 of using next() rather than
__next__() -- generators will have methods next(), throw(), and
close().
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
, works for me.
--
--Guido van Rossum (home page: http://www.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
.
--
--Guido van Rossum (home page: http://www.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
__del__() takes care of handling this exception (by printing and then
ignoring it). Raymond take notice if you're still working on the PEP.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
traceback.
Ironically, throwing an exception with a traceback into a generator is
likely to cause a cycle because the traceback likely references the
throwing frame, which certainly has a reference to the generator...
--
--Guido van Rossum (home page: http://www.python.org/~guido
be reachable from a trash
generator in a cycle.
--
--Guido van Rossum (home page: http://www.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
f_exc_traceback points to the
traceback object, and the traceback object's tb_frame points back to
the frame. So that's a cycle right there.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http
to the length of the string before you start; that's
a decent upper bound. :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
[Guido van Rossum]
Do we really need both __context__ and __cause__?
[Ka-Ping Yee]
Well, it depends whose needs we're trying to meet.
If we want to satisfy those who have been asking for chaining
of unexpected secondary exceptions, then we have to provide that
on some attribute.
If we
than just the value of XYZ. Or the
VM's except handling code could pull the value out of the exception and
store it in err for full compatibility.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
this is contrary to what some here have claimed (that you
could pass an explicit context to cause it to round according to the
context's precision).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev
one of those calls
would need to be changed to specify a context.
But passing a context doesn't help for obtaining the desired precision.
PS I also asked Cowlishaw and he said he would ponder it over the
weekend. Maybe Raymond can mail him too. ;-)
--
--Guido van Rossum (home page: http
to kick-start the work.
--
--Guido van Rossum (home page: http://www.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
available -- I cannot even think about this
myself without making drawings of object references...
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
that they can't root any
cycles?
I sort of doubt that these are the main source of live cycles. After
all, they are reset whenever a frame is popped (grep the sources for
reset_exc_info).
--
--Guido van Rossum (home page: http://www.python.org/~guido
I hope that I've got the rewrite of PEP 343 to include generator
extensions right now. I've chosen the 'with' keyword. Please review
here; I think this is ready for review by the unwashed masses. :-)
http://www.python.org/peps/pep-0343.html
--
--Guido van Rossum (home page: http
101 - 200 of 5880 matches
Mail list logo
