Martin v. Lwis [EMAIL PROTECTED] writes:
Michael Hudson wrote:
if (ProfilerError == NULL)
ProfilerError = PyErr_NewException(hotshot.ProfilerError,
NULL, NULL);
if (ProfilerError != NULL) {
Fredrik Lundh wrote:
[snip]
in my experience, any external library that supports more than one
Python version on more than one platform is likely to be more robust
than code in the core. add the multilevel volunteer approach de-
described by Steven (with the right infrastructure, things like
On 6/15/05, Benji York [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
I would prefer that the alternate iter() form was broken off into
another separate function, say, iterfunc(), that would let me write
Jp's solution something like:
for chunk in iterfunc('', f1.read, CHUNK_SIZE):
Steven Bethard [EMAIL PROTECTED] writes:
On 6/15/05, Benji York [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
I would prefer that the alternate iter() form was broken off into
another separate function, say, iterfunc(), that would let me write
Jp's solution something like:
for chunk
On Jun 16, 2005, at 10:50 AM, Steven Bethard wrote:
On 6/15/05, Benji York [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
I would prefer that the alternate iter() form was broken off into
another separate function, say, iterfunc(), that would let me write
Jp's solution something like:
Jeremy Maxfield [EMAIL PROTECTED] writes:
The current threadmodule.c does not seem to correctly support multiple
(sub) interpreters.
This would seem to be an accurate statement.
A short history:
The GILState functions were implemented.
The way they work is that when you call
Steven Bethard wrote:
I would prefer that the alternate iter() form was broken off into
another separate function, say, iterfunc(), that would let me write
Jp's solution something like:
for chunk in iterfunc('', f1.read, CHUNK_SIZE):
f2.write(chunk)
Benji York wrote:
for chunk in
PEP 288 is now withdrawn. The generator exceptions portion is subsumed
by PEP 343, and the generator attributes portion never garnered any
support.
The fate of generator attributes is interesting vs-a-vs PEP 342. The
motivation was always related to supporting advanced generator uses such
as
May I suggest rejecting PEP 265.
As of Py2.4, its use case is easily solved with:
sorted(d.iteritems(), key=itemgetter(1), reverse=True)
[('b', 23), ('d', 17), ('c', 5), ('a', 2), ('e', 1)]
Further, Py2.5 offers a parallel solution to the more likely use case of
wanting the access only the
The need for the indices() proposal was mostly met by PEP 279's
enumerate() builtin.
Commenting on 279 before it was accepted for Py2.3, PEP 281's author,
Magnus Lie Hetland, wrote, I'm quite happy to have it make PEP 281
obsolete.
Raymond
___
I updated the patch that supports PEP 304, Controlling Generation of
Bytecode Files to apply cleanly against current CVS. I've tested it on Mac
OS X (straight Unix build only). I'd appreciate it if some Linux, Windows
and Mac framework folks could apply the patch, rebuild, then run the tests
Raymond Hettinger wrote:
May I suggest rejecting PEP 265.
As of Py2.4, its use case is easily solved with:
sorted(d.iteritems(), key=itemgetter(1), reverse=True)
[('b', 23), ('d', 17), ('c', 5), ('a', 2), ('e', 1)]
+1.
I find that usually when I want something like this, I use:
At 08:24 PM 6/16/2005 -0400, Raymond Hettinger wrote:
Looking back at the history of 288, generator attributes surfaced only
in later drafts. In the earlier drafts, the idea for passing arguments
to and from running generators used an argument to next() and a return
value for yield. If this
[Phillip]
I could definitely go for dropping __next__ and the next() builtin
from
PEP
342, as they don't do anything extra. I also personally don't care
about
the new continue feature, so I could do without for-loop alteration
too. I'd be perfectly happy passing arguments to next()
At 10:26 PM 6/16/2005 -0400, Raymond Hettinger wrote:
288 was brought out of retirement a few months ago. Guido hated every
variation of argument passing and frequently quipped that data passing
was trivially accomplished though mutable arguments to a generator,
through class based iterators, or
On 6/16/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Phillip]
I could definitely go for dropping __next__ and the next() builtin from PEP
342, as they don't do anything extra. I also personally don't care about
the new continue feature, so I could do without for-loop alteration
too.
Agreed. I don't want to add sorting abilities (with all its infinite
variants) to every data structure -- or even one or two common data
structures. You want something sorted that's not already a list? Use
the sorted() method.
On 6/16/05, Steven Bethard [EMAIL PROTECTED] wrote:
Raymond Hettinger
On 6/16/05, Guido van Rossum [EMAIL PROTECTED] wrote:
Agreed. I don't want to add sorting abilities (with all its infinite
variants) to every data structure -- or even one or two common data
structures. You want something sorted that's not already a list? Use
the sorted() method.
I meant the
At 08:03 PM 6/16/2005 -0700, Guido van Rossum wrote:
Someone should really come up with some realistic coroutine examples
written using PEP 342 (with or without continue EXPR).
How's this?
def echo(sock):
while True:
try:
data = yield
On 6/16/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
The need for the indices() proposal was mostly met by PEP 279's
enumerate() builtin.
Commenting on 279 before it was accepted for Py2.3, PEP 281's author,
Magnus Lie Hetland, wrote, I'm quite happy to have it make PEP 281
obsolete.
Yes
At 12:07 AM 6/17/2005 -0400, Phillip J. Eby wrote:
def schedule_coroutine(geniter, *arg):
def resume():
value = geniter.next(*arg)
if value is not None:
schedule_coroutine(value)
reactor.callLater(0, resume)
Oops. I just
[Phillip]
I also personally don't care about the new continue feature,
so I could do without for-loop alteration too.
[Guido]
I do like continue EXPR but I have to admit I haven't even tried to
come up with examples -- it may be unnecessary. As Phillip says, yield
expressions and
The principal use case was largely met by enumerate(). From PEP 276's
rationale section:
A common programming idiom is to take a collection of objects and apply
some operation to each item in the collection in some established
sequential order. Python provides the for in looping control
23 matches
Mail list logo
