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/
> by simpler one:
Sim
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__
>>>
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:
# s
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
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 b
"Chas Emerick" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>One thing that would help Python in this "debate"
In general, discussion of promoting/marketing python is more a topic for
comp.lang.python than for this list. Also see below.
>My suggestion would be to either:
>(a) i
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, outerscope
Since Alex isn't on python-dev, forwarding this for his convenience (he said he wanted to reply.) Tim also replied to his checkin, but I didn't forward that message.-- Forwarded message --
From: Thomas Wouters <[EMAIL PROTECTED]>Date: Aug 24, 2006 12:16 AMSubject: Re: [Python-checki
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 glo
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
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 questi
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 li
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
w
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 we
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 hap
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
>ch
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
22 matches
Mail list logo
