Igor Bukanov wrote:
This example also suggests how to fix generators. One just need to
change the close method so it would cause return executed right after
the yield instead of throw.
I.e. replace the current text from
http://www.python.org/dev/peps/pep-0342/
snip close() =
John J Lee wrote:
On Mon, 21 Aug 2006, Nick Coghlan wrote:
John J Lee wrote:
And once the result has been promoted to unicode, __unicode__ is used
directly:
print repr(%s%s % (a(), a()))
__str__
accessing __main__.a object at 0x00AF66F0.__unicode__
__str__
accessing __main__.a object
This discussion probably happens as a result of attempts to copy
Python's design in JavaScript. I propose that JavaScript do whatever
it wants and its developers leave Python alone -- maybe some time in
the future we'll be able to compare the two approaches. I think it's
impossible to do so at the
I rather like it, actually. I don't recall there being any real reasons to
catch a GeneratorExit exception, but even if there were, you could do the
equivalent like this:
try:
closed = True
yield 1
closed = False
finally:
if closed:
#
This may seem like it's coming out of left field for a minute, but
bear with me.
There is no doubt that Ruby's success is a concern for anyone who
sees it as diminishing Python's status. One of the reasons for
Ruby's success is certainly the notion (originally advocated by Bruce
Tate, if
I'm CC python-dev as this may be a bug in the gc module. Although this may be
more of a c.l.p. post, I think that this usage shouldn't cause segfaults
regardless.
On Tuesday 22 August 2006 3:06 pm, Robert Fleming wrote:
[step 1 unnecessary]
2. test program (test.c):
/ snip /
Martin v. Löwis schrieb:
Thomas Heller schrieb:
I suggest that it [the ctypes package] should be removed from the 2.5 win64
msi installers, so that
at least, when it is ready, can be installed as separate package.
Unfortunately, I won't be able to work on this until the release is
made.
Hi all,
I noticed in Python/ceval.c that LOAD_GLOBAL uses a dictionary lookup,
and was wondering if that can be optimized to a simple array lookup.
If i'm right there are 3 kinds of name lookups: locals, outer
scopes(closures), and globals. (not counting attribute lookup). Locals
are identified
On 8/23/06, K.S.Sreeram [EMAIL PROTECTED] wrote:
Hi all,I noticed in Python/ceval.c that LOAD_GLOBAL uses a dictionary lookup,and was wondering if that can be optimized to a simple array lookup.No, not as the language stands now.
If i'm right there are 3 kinds of name lookups: locals,
On Aug 23, 2006, at 2:22 PM, K.S.Sreeram wrote:
Hi all,
I noticed in Python/ceval.c that LOAD_GLOBAL uses a dictionary lookup,
and was wondering if that can be optimized to a simple array lookup.
If i'm right there are 3 kinds of name lookups: locals, outer
scopes(closures), and globals.
2006/8/24, Brett Cannon [EMAIL PROTECTED]:
On 8/23/06, K.S.Sreeram [EMAIL PROTECTED] wrote:
Hi all,
I noticed in Python/ceval.c that LOAD_GLOBAL uses a dictionary lookup,
and was wondering if that can be optimized to a simple array lookup.
No, not as the language stands now.
If
I have been spending my Google sprint time on writing and implementing PEP 362 (http://www.python.org/dev/peps/pep-0362/), which finally defines Signature objects for functions. With the implementation at a place I am happy with, I wanted to ask about the open issues with the PEP.
The first
IIUC this is how return currently works -- in some sense it's an
exception, but it can't be caught, and it won't escape from the
current frame. Ditto for break/continue.
The generator extensions are still very young, and I'm not against
changing them somewhat in 2.6 or py3k. Perhaps GeneratorExit
Zitat von Tim Peters [EMAIL PROTECTED]:
Huh. It's been a (mildly controversial, but intentional all the same)
feature that Python tries to raise raise OverflowError on overflowing
libm operations. Doesn't work all that well, since there's no
consistency across platforms about when libm
Brett Cannon wrote:
I have been spending my Google sprint time on writing and implementing
PEP 362 (http://www.python.org/dev/peps/pep-0362/), which finally
defines Signature objects for functions. With the implementation at a
place I am happy with, I wanted to ask about the open issues
On Aug 23, 2006, at 3:29 PM, Thomas Wouters wrote:
Since Alex isn't on python-dev, forwarding this for his convenience
(he said he wanted to reply.)
Thanks! I _am_ on Python-Dev (otherwise couldn't read what you're
forwarding here), but not on Python-Checkins (where the discussion
was
On Aug 23, 2006, at 3:13 PM, [EMAIL PROTECTED] wrote:
Zitat von Tim Peters [EMAIL PROTECTED]:
Huh. It's been a (mildly controversial, but intentional all the
same)
feature that Python tries to raise raise OverflowError on overflowing
libm operations. Doesn't work all that well, since
On 8/23/06, Georg Brandl [EMAIL PROTECTED] wrote:
Brett Cannon wrote: I have been spending my Google sprint time on writing and implementing PEP 362 (http://www.python.org/dev/peps/pep-0362/), which finally
defines Signature objects for functions.With the implementation at a place I am happy
At 04:10 PM 8/23/2006 -0700, Guido van Rossum wrote:
IIUC this is how return currently works -- in some sense it's an
exception, but it can't be caught, and it won't escape from the
current frame. Ditto for break/continue.
The generator extensions are still very young, and I'm not against
At 01:44 AM 8/24/2006 +0200, Igor Bukanov wrote:
Regarding yield in the finally problem:
The current implementation throws RuntimeException after the yield
transfer the control back to the close method. If that is changed to
reporting a bad behavior and rethrowing GeneratorExit or its hidden
20 matches
Mail list logo
