Delaney, Timothy C (Timothy) wrote:
> Nick Coghlan wrote:
> I think if we are going to emphasise the difference, a decorator does
> not go far enough. To use a decorator, this *must* be valid syntax::
>
> def gen():
> try:
> yield
> finally:
> print 'Don
Nick Coghlan wrote:
> Ah, someone else did post this idea first :)
I knew I was standing on the shoulders of others :)
> To deal with the generator issue, one option would be to follow up on
> Phillip's idea of a decorator to convert a generator (or perhaps any
> standard iterator) into a block
Delaney, Timothy C (Timothy) wrote:
> Guido van Rossum wrote:
>
>
>>I'd like the block statement to be defined exclusively in terms of
>>__exit__() though.
>
>
> This does actually suggest something to me (note - just a thought - no
> real idea if it's got any merit).
>
> Are there any use cas
> At 05:17 PM 5/3/05 -0700, Guido van Rossum wrote:
>>But I kind of doubt that it's an issue; you'd have to have a
>>try/except catching StopIteration around a yield statement that
>>resumes the generator before this becomes an issue, and that sounds
>>extremely improbable.
The specific offending
Phillip J. Eby wrote:
> This and other examples from the PEP still have a certain awkwardness of
> phrasing in their names. A lot of them seem to cry out for a "with"
> prefix, although maybe that's part of the heritage of PEP 310. But Lisp
> has functions like 'with-open-file', so I don't thi
Tim Peters wrote:
> I don't think anyone has mentioned this yet, so I will: library
> writers using Decimal (or more generally HW 754 gimmicks) have a need
> to fiddle lots of thread-local state ("numeric context"), and must
> restore it no matter how the routine exits. Like "boost precision to
>
James Y Knight wrote:
> On May 3, 2005, at 12:53 PM, Guido van Rossum wrote:
>
>>def saving_stdout(f):
>>save_stdout = sys.stdout
>>try:
>>sys.stdout = f
>>yield
>>finally:
>>sys.stdout = save_stdout
>
>
> I hope you aren't going to be using that in any thread
Delaney, Timothy C (Timothy) wrote:
> Guido van Rossum wrote:
>
>> I'd like the block statement to be defined exclusively in terms of
>> __exit__() though.
>
> 1. If an iterator declares __exit__, it cannot be used in a for-loop.
>For-loops do not guarantee resource cleanup.
>
> 2. If an it
> >(So do you want this feature now or not? Earlier you said it was no
big
> deal.)
>
> It *isn't* a big deal; but it'd still be nice, and I'd happily
volunteer
> to
> do the actual implementation of the 'close()' method myself, because
it's
> about the same amount of work as updating PEP 333 and
At 08:47 PM 5/3/05 -0400, Phillip J. Eby wrote:
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/141934
Oops; that one's not really a valid example; the except StopIteration just
has a harmless "pass", and it's not in a loop.
___
Python-D
At 05:17 PM 5/3/05 -0700, Guido van Rossum wrote:
>(So do you want this feature now or not? Earlier you said it was no big deal.)
It *isn't* a big deal; but it'd still be nice, and I'd happily volunteer to
do the actual implementation of the 'close()' method myself, because it's
about the same a
> > I think that realization is important. It would be great to have a
> > section of the PEP that focuses on separability and matching
features to
> > benefits. Start with above observation that the proposed examples
can
> > be achieved with generators driving the block statement.
>
> Good idea
Guido van Rossum wrote:
> I'd like the block statement to be defined exclusively in terms of
> __exit__() though.
This does actually suggest something to me (note - just a thought - no
real idea if it's got any merit).
Are there any use cases proposed for the block-statement (excluding the
for-l
On 5/3/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 04:41 PM 5/3/05 -0700, Guido van Rossum wrote:
> >Given all that, it's not infeasible to add a close() method to
> >generators as a shortcut for this:
> >
> > def close(self):
> > try:
> > self.__exit__(StopIteration)
[Guido]
> > And come to think of it, using a generator to "drive" a block
> > statement is also separable; with just the definition of the block
> > statement from the PEP you could implement all the examples using a
> > class (similar to example 6, which is easily turned into a template).
[Raymon
At 04:41 PM 5/3/05 -0700, Guido van Rossum wrote:
>Given all that, it's not infeasible to add a close() method to
>generators as a shortcut for this:
>
> def close(self):
> try:
> self.__exit__(StopIteration)
> except StopIteration:
> break
> else
> it's not infeasible to add a close() method to
> generators as a shortcut for this:
>
> def close(self):
> try:
> self.__exit__(StopIteration)
> except StopIteration:
> break
> else:
> # __exit__() didn't
> raise Runtime
> But there are several separable proposals in the PEP. Using "continue
> EXPR" which calls its.__next__(EXPR) which becomes the return value of
> a yield-expression is entirely orthogonal (and come to think of it the
> PEP needs a motivating example for this).
>
> And come to think of it, using a
> >Maybe if you drop support for the "separate protocol" alternative... :-)
>
> I don't understand you. Are you suggesting a horse trade, or...?
Only tongue-in-cheek. :-)
> >I had never heard of that PEP. How much code is there in the field?
>
> Maybe a dozen or so web applications and framewo
At 07:27 PM 5/3/05 -0400, Phillip J. Eby wrote:
>Modifying the spec is potentially more controversial, however; it'll have
>to go past the Web-SIG, and I assume the first thing that'll be asked is,
>"Why aren't generators getting a close() method then?", so I figured I
>should ask that question fir
At 03:33 PM 5/3/05 -0700, Guido van Rossum wrote:
>[Phillip]
> > That reminds me of something; in PEP 333 I proposed use of a 'close()'
> > attribute in anticipation of PEP 325, so that web applications implemented
> > as generators could take advantage of resource cleanup. Is there any
> > chance
Sorry Jim, but I just don't think you & I were intended to be on the
same language design committee. Nothing you say seems to be making any
sense to me these days. Maybe someone else can channel you
effectively, but I'm not going to try to do a line-by-line response to
your email quoted below.
On
Summary:
Resource Managers are a good idea.
First Class Suites may be a good idea.
Block Iterators try to split the difference. They're not as powerful
as First Class Suites, and not as straightforward as Resource
Managers. This particular middle ground didn't work out so well.
On 5/3/05, G
[Phillip]
> That reminds me of something; in PEP 333 I proposed use of a 'close()'
> attribute in anticipation of PEP 325, so that web applications implemented
> as generators could take advantage of resource cleanup. Is there any
> chance that as part of PEP 340, 'close()' could translate to the
[Guido]
> > Where do you see a learning curve for blocks?
[Raymond]
> Altering the meaning of a for-loop; introducing a new keyword; extending
> the semantics of "break" and "continue"; allowing try/finally inside a
> generator; introducing new control flow; adding new magic methods
> __next__ and
At 05:30 PM 5/3/05 -0400, Raymond Hettinger wrote:
>By comparision, g.throw() or g.close() are trivially simple approaches
>to generator/iterator finalization.
That reminds me of something; in PEP 333 I proposed use of a 'close()'
attribute in anticipation of PEP 325, so that web applications imp
> > In contrast, the new use of yield differs in that the suspended
frame
> > transfers control from the encloser to the enclosed.
>
> Why does your notion of who encloses whom suddenly reverse when you go
> from a for-loop to a block-statement? This all feels very strange to
> me.
After another
[Tim]
>> Because Queue does use condvars now instead of plain locks, I wouldn't
>> approve of any gimmick purporting to hide the acquire/release's in
>> put() or get(): that those are visible is necessary to seeing that
>> the _condvar_ protocol is being followed ("must acquire() before
>> wait();
...
[Jim Jewett]
>> qsize, empty, and full could be done with a lockself decorator.
>> Effectively, they *are* lockself decorators for the _xxx functions
>> that subclasses are told to override.
[Guido]
> Actually you're pointing out a bug in the Queue module: these *should*
> be using a try/fin
[Tim]
> Because Queue does use condvars now instead of plain locks, I wouldn't
> approve of any gimmick purporting to hide the acquire/release's in
> put() or get(): that those are visible is necessary to seeing that
> the _condvar_ protocol is being followed ("must acquire() before
> wait(); must
> [Raymond Hettinger]
> >> Likewise, is it correct that "yield" is anti-parallel to the current
> >> meaning? Inside a generator, it returns control upwards to the caller.
> >> But inside a block-iterator, it pushes control downwards (?inwards) to
> >> the block it controls.
>
[Guido]
> > I have
[Raymond]
It would be great if we could point to some code in the standard library
or in a major Python application that would be better (cleaner, faster,
or clearer) if re-written using blocks and block-iterators
[Guido]
>>> look more closely at Queue, and you'll find that the two
> [Raymond]
> > > Likewise, is it correct that "yield" is anti-parallel to the current
> > > meaning? Inside a generator, it returns control upwards to the caller.
> > > But inside a block-iterator, it pushes control downwards (?inwards) to
> > > the block it controls.
>
> [Guido van Rossum]
> >
[Raymond]
> > Likewise, is it correct that "yield" is anti-parallel to the current
> > meaning? Inside a generator, it returns control upwards to the
caller.
> > But inside a block-iterator, it pushes control downwards (?inwards)
to
> > the block it controls.
[Guido van Rossum]
> I have a hard ti
On May 3, 2005, at 12:53 PM, Guido van Rossum wrote:
> def saving_stdout(f):
> save_stdout = sys.stdout
> try:
> sys.stdout = f
> yield
> finally:
> sys.stdout = save_stdout
I hope you aren't going to be using that in any threaded program.
That's one really nic
On Tue, May 03, 2005, Phillip J. Eby wrote:
> At 09:53 AM 5/3/05 -0700, Guido van Rossum wrote:
>>
>>I just came across another use case that is fairly common in the
>>standard library: redirecting sys.stdout. This is just a beauty (in
>>fact I'll add it to the PEP):
>>
>>def saving_stdout(f):
>
>
At 09:53 AM 5/3/05 -0700, Guido van Rossum wrote:
>I just came across another use case that is fairly common in the
>standard library: redirecting sys.stdout. This is just a beauty (in
>fact I'll add it to the PEP):
>
>def saving_stdout(f):
Very nice; may I suggest 'redirecting_stdout' as the name
[Raymond Hettinger]
> I just made a first reading of the PEP and want to clarify my
> understanding of how it fits with existing concepts.
Thanks! Now is about the right time -- all the loose ends are being
solidified (in my mind any way).
> Is it correct to say that "continue" parallel's its cur
Hi,
Sounds like a useful requirement to have for new features in 2.x,
IMO. that is... "demonstrated need".
If the feature implies that the app needs to be designed from the
ground up to *really* take advantage of the feature, then, maybe
leave it for Guido's sabbatical (e.g. Python 300
I just made a first reading of the PEP and want to clarify my
understanding of how it fits with existing concepts.
Is it correct to say that "continue" parallel's its current meaning and
returns control upwards (?outwards) to the block iterator that called
it?
Likewise, is it correct that "yield"
40 matches
Mail list logo
