Sorry, Nick. GMail, for some reason, doesn't follow the reply-to
properly for python-dev. Forwarding to list now...
On 10/9/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Jim Fulton wrote:
> > Based on the discussion, I think I'd go with defaultproperty.
> >
> > Questions:
> >
> > - Should this be
On 10/6/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 10:09 PM 10/5/2005 -0700, Neal Norwitz wrote:
> >The general idea is to allocate the stack in one big hunk and just
> >walk up/down it as functions are called/returned. This only means
> >incrementing or decrementing pointers. This should
Jim Fulton wrote:
> Based on the discussion, I think I'd go with defaultproperty.
>
> Questions:
>
> - Should this be in builtins, alongside property, or in
>a library module? (Oleg suggested propertytools.)
>
> - Do we need a short PEP?
The much-discussed never-created decorators module, p
On Sunday 09 October 2005 22:44, Greg Ewing wrote:
> I'm aware of the differences, but I still see a strong
> similarity where this particular feature is concerned.
> The pattern of thinking is the same: "I want to deal
> with the first n of these things individually, and the
> rest collective
Guido van Rossum wrote:
> I personally think this is adequately handled by writing:
>
> (first, second), rest = something[:2], something[2:]
That's less than satisfying because it violates DRY
three times (once for mentioning 'something' twice,
once for mentioning the index twice, and once for
Guido van Rossum wrote:
> Plus, Piet also remarked that the value is silently ignored
> when the generator is used in a for-loop. ... I'd worry that accepting
> "return X" would increase the occurrence of bugs caused by someone
> habitually writing "return X" where they meant "yield X".
Then ha
Nick Coghlan wrote:
> Sometimes I miss the obvious. There's a *much*, *much* better place to store
> the return value of a generator than on the StopIteration exception that it
> raises when it finishes. Just save the return value in the *generator*.
I'm not convinced that this is better, becau
At 01:33 PM 10/10/2005 +1300, Greg Ewing wrote:
>Phillip J. Eby wrote:
>
> > Clearly, the cost of function calls in Python lies somewhere else, and I'd
> > probably look next at parameter tuple allocation,
>
>For simple calls where there aren't any *args or other
>such complications, it seems like
On 10/9/05, Jim Fulton <[EMAIL PROTECTED]> wrote:
> Based on the discussion, I think I'd go with defaultproperty.
Great.
> Questions:
>
> - Should this be in builtins, alongside property, or in
>a library module? (Oleg suggested propertytools.)
>
> - Do we need a short PEP?
I think so. From
Phillip J. Eby wrote:
> Clearly, the cost of function calls in Python lies somewhere else, and I'd
> probably look next at parameter tuple allocation,
For simple calls where there aren't any *args or other
such complications, it seems like it should be possible
to just copy the args from the cal
Le dimanche 09 octobre 2005 à 07:46 -0700, Guido van Rossum a écrit :
> I
> also think that using a thread for async I/O is the wrong approach --
> if you wanted to use threads shou should be using threads and you
> wouldn't be dealing with generators. There's a solution that uses
> select() which
Based on the discussion, I think I'd go with defaultproperty.
Questions:
- Should this be in builtins, alongside property, or in
a library module? (Oleg suggested propertytools.)
- Do we need a short PEP?
Jim
Jim Fulton wrote:
> Guido van Rossum wrote:
>
>>On 9/28/05, Jim Fulton <[EMAIL PR
On 10/9/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Sometimes I miss the obvious. There's a *much*, *much* better place to store
> the return value of a generator than on the StopIteration exception that it
> raises when it finishes. Just save the return value in the *generator*.
>
> And then pro
On 10/9/05, Anders J. Munch <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
> >Anders J. Munch wrote:
> >
> >>Note that __with__ and __enter__ could be combined into one with no
> >>loss of functionality:
> >>
> >>abc,VAR = (EXPR).__with__()
> >>
> >
> >They can't be combined, bec
Nick Coghlan wrote:
>Anders J. Munch wrote:
>
>>Note that __with__ and __enter__ could be combined into one with no
>>loss of functionality:
>>
>>abc,VAR = (EXPR).__with__()
>>
>
>They can't be combined, because they're invoked on different objects.
>
Sure they can. The comb
Nick Coghlan wrote:
> Although, if StopIteration.result was a read-only property with the above
> definition, wouldn't that give us the benefit of "one obvious way" to return
> a
> value from a coroutine without imposing any runtime cost on normal use of
> StopIteration to finish an iterator?
> What happened to the CurrentVersion registry entry documented at
>
> http://www.python.org/windows/python/registry.html
>
> AFAICT, even the python15.wse file did not fill a value in this
> entry (perhaps I'm misinterpreting the wse file, though).
>
> So was this ever used? Why is it documented,
17 matches
Mail list logo
