After nine months, no support has grown beyond the original poster. The
PEP did however generate some negative responses when brought-up on
comp.lang.python (it made some people's stomach churn).
The PEP fails the tests of obviousness and necessity. The PEP's switch
example is easily handled by
[Raymond]
> Let me go on record as a strong -1 for "continue EXPR". The for-loop is
> our most basic construct and is easily understood in its present form.
> The same can be said for "continue" and "break" which have the added
> advantage of a near zero learning curve for people migrating from ot
While the majority of Python users deem this to be a nice-to-have
feature, the community has been unable to reach a consensus on the
proper syntax after more than two years of intensive debate (the PEP was
introduced in early April 2003).
Most agree that there should be only-one-way-to-do-it; howe
I've never liked that idea. Down with it!
On 6/16/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> 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 ea
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
st
[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 an
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 jus
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
> obsole
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 nonblocking_read(s
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
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 Hetting
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
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,
[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() exp
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 s
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:
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
(
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
___
Pytho
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 l
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 vís-a-vís PEP 342. The
motivation was always related to supporting advanced generator uses such
as e
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
FYI. Check it out, the Python program is really good!
-- Forwarded message --
From: Gina Blaber <[EMAIL PROTECTED]>
Date: Jun 16, 2005 11:31 AM
Subject: [Oscon] please spread the word about OSCON early reg deadline
To: OSCON Committee Mailing List <[EMAIL PROTECTED]>
Cc: Gina Blabe
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 PyGILState_E
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 som
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:
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_
On Sun, 2005-06-12 at 00:52, Nick Coghlan wrote:
> The idea behind 'with' is that the block is executed while holding
> (i.e. 'with') the resource.
>
> I think the '-ing' form of the example templates is a holdover from
> the days when the PEP used the 'do' keyword - I find that past tense
> o
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 li
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>
>> if (ProfilerError == NULL)
>> ProfilerError = PyErr_NewException("hotshot.ProfilerError",
>>NULL, NULL);
>> if (ProfilerError != NULL) {
>>
29 matches
Mail list logo
