[Python-Dev] Re: Re: anonymous blocks
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 awkward syntax and frame hackery I currently use. since when does def mythread(self): ... yield request print self.response ... qualify as frame hackery? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Re: anonymous blocks
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 StopIteration or ContinueIteration > instance > - use "continue EXPR" to pass a value to the generator > - generator exception handling explained +1 (most excellent) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: Re: anonymous blocks
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 it by means of a generator, you don't need a class at all -- just make the whole thing a generator function. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Re: anonymous blocks
"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 experience in > Python and > iterators at the minimum, and hopefully with generators. Not exactly > meant for > someone for which raw_input() still holds a "wow" factor for. =) I have accepted the fact that Python has become a two-level language: basic Python for expressing algorithms + advanced features (metaclasses, decorators, CPython-specific introspection and hacks, and now possibly 'with' or whatever) for solving software engineering issues. Perhaps there should correspondingly be two tutorials. Terry J. Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Re: anonymous blocks
"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 unpacking as with assignment, for loops, and function calls: with a,b,c = x,y,z and so on. Terry J. Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Re: anonymous blocks
"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 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. Would not calling iter() (or .__iter__) explicitly, instead of depending on the implicit call of for loops, suffice to produce the needed iterator? tjr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: Re: anonymous blocks
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 that blocks are further worthwhile, I suppose we could wait and see. Agreed. I agree, in fact I think that solving that issue is very important before/if ever introducing a generalized block statement because otherwise things that would naturally be expressible with for and generators will use the block construct which allow more variety and so possibly less immediate clarity just because generators are not good at resource handling. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: Re: anonymous blocks
[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 luck with your future adventures in language > > design. [Brian again] > I'm just trying to help python improve. Maybe I'm not doing a very good > job, I don't know. Either way, there's no need to be rude. > > If I've broken some sort of unspoken code of behavior for this list, then > maybe it would be easier if you just 'spoke' it (perhaps in a private > email or in the description of this list on python.org). In his own inimitable way, Fredrik is pointing out that your argument is a tautology (or very close to one): rephrased, it sounds like "if X were commonly used, you'd recognize it easily", which isn't a sufficient argument for anything. While I've used similar arguments occasionally to shut up folks whose only remaining argument against a new feature was "but nobody will understand it the first time they encounter it" (which is true of *everything* you see for the first time), such reasoning isn't strong enough to support favoring one thing over another. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Re: anonymous blocks
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").addCallback(sayGoodbye)
>>> self.send("hello").addCallback(mingle)
>>
>> def iterman(self):
>> yield "hello"
>> yield "nice weather we're having"
>> yield "goodbye"
>
> Which, more or less works, for a literal translation of the straw-man above.
> However, you're
> missing the point. These deferred operations actually return results.
> Generators offer no sane
> way to pass results back in.
that's why you need a context object (=self, in this case).
def iterman(self):
yield "hello"
print self.data
yield "nice weather we're having"
print self.data
yield "goodbye"
also see:
http://effbot.org/zone/asyncore-generators.htm
> If they did, then this use case could be mostly served by generators.
exactly.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Re: anonymous blocks
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's nearly three times faster > > than pyexpat, which is the fastest callback-based XML parser we have) > > It seems as though you are saying that because callbacks are so slow, > that blocks are a non-starter for you because of how slow it would be to > call them. Not really -- I see the for-in loop body as the block. The increased speed is just a bonus. > I'm thinking that if people get correct code easier, that speed will not be > as much > of a concern (that's why I use Python already). (Slightly OT, but speed is always a concern. I no longer buy the "it's python, it has to be slow" line of reasoning; when done correctly, Python code is often faster than anything else. cElementTree is one such example; people have reported that cElementTree plus Python code can be a lot faster than dedicated XPath/XSLT engines; the Python bytecode engine is extremely fast, also compared to domain-specific interpreters... And in this case, you get improved usability *and* improved speed at the same time. That's the way it should be.) > With that said, both blocks and iterators makes /writing/ such things > easier to understand, but neither really makes /reading/ much easier. > Sure, it is far more terse, but that doesn't mean it is easier to read > and understand what is going on. Well, I was talking about reading here: with the for-in pattern, you loop over the "callback source", and the "callback" itself is inlined. You don't have to think in "here is the callback, here I configure the callback source" terms; just make a function call and loop over the result. > 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 that > blocks are further worthwhile, I suppose we could wait and see. Agreed. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Re: anonymous blocks
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 some extent, by the argument names chosen by the library implementor. I'm not so sure that's always a valid assumption. while in your example, there is no visual cue that distinguishes the details from the intent. carefully chosen function names (that you chose yourself) plus blank lines can help with that. Of course, lambdas are even better, when it's possible to use them: doFoo((lambda a, b: a + b), (lambda c, d: c + d)) that only tells you that you're calling "doFoo", with no clues whatsoever to what the code in the lambdas are doing. keyword arguments are a step up from that, as long as your intent matches the library writers intent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: Re: anonymous blocks
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 with your future adventures in language design. I'm just trying to help python improve. Maybe I'm not doing a very good job, I don't know. Either way, there's no need to be rude. If I've broken some sort of unspoken code of behavior for this list, then maybe it would be easier if you just 'spoke' it (perhaps in a private email or in the description of this list on python.org). I'm not sure what your point is exactly. Are you saying that any language feature that needs to be commonly used to be comprehendible will never be comprehendible because it will never be commonly used? If so, then I do not think you have a valid point. I never claimed that keyword suites *need* to be commonly used to be comprehendible. I only said that if they were commonly used they would be more comprehendible than the alternative. I happen to also believe that seeing them once or twice is enough to make them about equally as comprehendible as the alternative. -Brian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Re: anonymous blocks
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 adventures in language design. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
