Phillip J. Eby wrote:
This interest is unrelated to anonymous blocks in any case; it's about
being able to simulate lightweight pseudo-threads ala Stackless, for use
with Twisted. I can do this now of course, but "yield expressions" as
described in PEP 340 would eliminate the need for the awkwa
Guido van Rossum wrote:
> I've written a PEP about this topic. It's PEP 340: Anonymous Block
> Statements (http://python.org/peps/pep-0340.html).
>
> Some highlights:
>
> - temporarily sidestepping the syntax by proposing 'block' instead of 'with'
> - __next__() argument simplified to StopIteratio
Terry Reedy wrote:
Not supporting iterables makes it harder to write a class which is
inherently usable in a with block, though. The natural way to make
iterable classes is to use 'yield' in the definition of __iter__ - if
iter() is not called, then that trick can't be used.
If you're defining i
"Brett C." <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> And before anyone decries the fact that this might confuse a newbie
> (which
> seems to happen with every advanced feature ever dreamed up), remember
> this
> will not be meant for a newbie but for someone who has experien
"Skip Montanaro" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>Guido> with VAR = EXPR:
>Guido> BODY
>
> What about a multi-variable case? Will you have to introduce a new level
> of
> indentation for each 'with' var?
I would expect to see the same structure u
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Guido van Rossum wrote:
> > statement expansion", I think we can expect EXPR to produce a value
> > that is already an iterator (rather than merely an interable).
>
> Not supporting iterables makes it harder to write a c
Fredrik Lundh wrote:
Regardless, I believe that solving generator finalization (calling all
enclosing finally blocks in the generator) is a worthwhile problem to
solve. Whether that be by PEP 325, 288, 325+288, etc., that should be
discussed. Whether people use it as a pseudo-block, or decide tha
[Brian Sabbey]
> >> If suites were commonly used as above to define properties, event handlers
> >> and other callbacks, then I think most people would be able to comprehend
> >> what the first example above is doing much more quickly than the second.
[Fredrik]
> > wonderful logic, there. good lu
Bob Ippolito wrote:
>>> def strawman(self):
>>> def sayGoodbye(mingleResult):
>>> def goAway(goodbyeResult):
>>> self.loseConnection()
>>> self.send("goodbye").addCallback(goAway)
>>> def mingle(helloResult):
>>> self.send("nice weather we're having").ad
Josiah Carlson wrote:
> > for my purposes, I've found that the #1 callback killer in contemporary
> > Python
> > is for-in:s support for the iterator protocol:
> ...
> > and get shorter code that runs faster. (see cElementTree's iterparse for
> > an excellent example. for typical use cases, it'
Shane Hathaway wrote:
Brian's suggestion makes the code read more like an outline. In Brian's
example, the high-level intent stands out from the details
that assumes that when you call a library function, the high-level intent of
*your* code is obvious from the function name in the library, and to
Fredrik Lundh wrote:
Brian Sabbey wrote:
If suites were commonly used as above to define properties, event handlers
and other callbacks, then I think most people would be able to comprehend
what the first example above is doing much more quickly than the second.
wonderful logic, there. good luck
Brian Sabbey wrote:
If suites were commonly used as above to define properties, event handlers
and other callbacks, then I think most people would be able to comprehend
what the first example above is doing much more quickly than the second.
wonderful logic, there. good luck with your future adv
13 matches
Mail list logo
