Re: [Python-Dev] Let's just *keep* lambda
On Fri, 10 Feb 2006 16:49:13 +1300, Greg Ewing [EMAIL PROTECTED] wrote: Valentino Volonghi aka Dialtone wrote: when some_operation_that_results_in_a_deferred() - result: if result == 'Initial Value': when work_on_result_and_return_a_deferred(result) - inner_res: print inner_res else: print No work on result reactor.stop() Hmmm. This looks remarkably similar to something I got half way through dreaming up a while back, that I was going to call Simple Continuations (by analogy with Simple Generators). Maybe I should finish working out the details and write it up. On the other hand, it may turn out that it's subsumed by the new enhanced generators plus a trampoline. This in only partially true. In fact, let's consider again twisted for the example, you can do something like this: @defgen def foo(): for url in urls: page = yield client.getPage(url) print page This has 2 disadvantages IMHO. First of all I have to use a function or a method decorated with @defgen to write that. But most important that code, although correct is serializing things that could be parallel. The solution is again simple but not really intuitive: @defgen def foo(): for d in map(client.getPage, urls): page = yield d print page Written in this way it will actually work in a parallel way but it is not really an intuitive solution. Using when instead: for url in urls: when client.getPage(url) - page: print page This wouldn't have any problem and is quite readable. A similar construct is used in the E language and here http://www.skyhunter.com/marcs/ewalnut.html#SEC20 is explained how when works for them and their promise object. You can also have multiple things to wait for: when (client.getPage(url), cursor.execute(query)) - (page, results): print page, results or l = [list, of, deferreds] when l - *results: print results and we could catch errors in the following way: when client.getPage(url) - page: print page except socket.error, e: print something bad happened HTH -- Valentino Volonghi aka Dialtone Now Running MacOSX 10.4 Blog: http://vvolonghi.blogspot.com New Pet: http://www.stiq.it ___ 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] Let's just *keep* lambda
On Thu, 09 Feb 2006 17:39:31 +0100, \Martin v. Löwis\ [EMAIL PROTECTED] wrote: It's not a specific example though: what precise library provides the visit method? I'll provide my own usecase right now which is event driven programming of any kind (from GUI toolkits, to network frameworks/libraries). From my experience these are the kind of usecases that suffer most from having to define functions everytime and, worse, to define functions before their actual usage (which is responsible for part of the bad reputation that, for example, deferreds have). Let's consider this piece of code (actual code that works today and uses twisted for convenience): def do_stuff(result): if result == 'Initial Value': d2 = work_on_result_and_return_a_deferred(result) d2.addCallback(println) return d2 return 'No work on result' def println(something): print something d1 = some_operation_that_results_in_a_deferred() d1.addCallback(do_stuff) d1.addCallback(lambda _: reactor.stop()) reactor.run() As evident the execution order is almost upside-down and this is because I have to define a function before using it (instead of defining and using a function inline). However python cannot have a statement inside an expression as has already been said, thus I think some new syntax to support this could be helpful, for example: when some_operation_that_results_in_a_deferred() - result: if result == 'Initial Value': when work_on_result_and_return_a_deferred(result) - inner_res: print inner_res else: print No work on result reactor.stop() reactor.run() In this case the execution order is correct and indentation helps in identifying which pieces of the execution will be run at a later time (depending on the when block). This way of coding could be useful for many kind of event driven frameworks like GUI toolkits that could do the following: when button.clicked() - event, other_args: when some_dialog() - result: if result is not None: window.set_title(result) IMHO similar considerations are valid for other libraries/frameworks like asyncore. What would this require? Python should basically support a protocol for a deferred like object that could be used by a framework to support that syntax. Something like: callback(initial_value) add_callback(callback, *a, **kw) add_errback(callback, *a, **kw) (extra methods if needed) HTH -- Valentino Volonghi aka Dialtone Now Running MacOSX 10.4 Blog: http://vvolonghi.blogspot.com New Pet: http://www.stiq.it ___ 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] threadsafe patch for asynchat
On Wed, Feb 08, 2006 at 01:23:26PM +, Donovan Baarda wrote: I believe that Twisted does pretty much this with it's deferred stuff. It shoves slow stuff off for processing in a separate thread that re-syncs with the event loop when it's finished. Deferreds are only an elaborate way to deal with a bunch of callbacks. It's Twisted itself that provides a way to run something in a separate thread and then fire a deferred (from the main thread) when the child thread finishes (reactor.callInThread() to call stuff in a different thread, reactor.callFromThread() to call reactor APIs from a different thread) Deferreds are just a bit more than: class Deferred(object): def __init__(self): self.callbacks = [] def addCallback(self, callback): self.callbacks.append(callback) def callback(self, value): for callback in self.callbacks: value = callback(value) This is mostly what a deferred is (without error handling, extra argument passing, 'nested' deferreds handling and blabla, the core concept however is there). As you see there is no extra magic in deferreds (or weird dependency on Twisted, they are pure python and could be used everywhere, you can implement them in any language that supports first class functions). In the case of Zope/ZEO I'm not entirely sure but I think what happened was medusa (asyncore/asynchat based stuff Zope2 was based on) didn't have this deferred handler support. When they found some of the stuff Here I think you meant that medusa didn't handle computation in separate threads instead. -- Valentino Volonghi aka Dialtone Now Running MacOSX 10.4 Blog: http://vvolonghi.blogspot.com New Pet: http://www.stiq.it pgpMxTGEMNS2c.pgp Description: PGP signature ___ 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] Small any/all enhancement
I see that Python 2.5 will include a simple implementation of any/all.
What I would like to ask, before it's too late, is if it's possible to add an
optional test argument.
any(iterable, test=bool) and all(iterable, test=bool)
These would be the new proposed APIs. The usecase is to be able to extract
attributes from objects or simply to have arbitrary checks like:
import operator
any(some_objects, test=operator.attrgetter('some_attribute'))
or
def zerop(x):
return x==0
all(some_objects, zerop)
instead of preprocessing the generator with a generator expression before
passing it to any/all.
Thanks.
--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
pgpm3YZZLyclq.pgp
Description: PGP signature
___
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] Small any/all enhancement
On Tue, Dec 27, 2005 at 01:50:37PM -0800, Alex Martelli wrote: I'll answer here for all the people who kindly answered. Why would that be better than any(o.some_attribute for o in some_objects) ? I think it's because lately I've been using common lisp a lot and the approach with the test function is pretty common there. Of course I already knew all the alternatives using map and the generator expression, but I felt like mine was clearer for a reader, this is probably true but not enough to justify the change. One reason was to hide the iteration from the user and let python handle it, but I can see that this is both not enough and probably not even so necessary since the iteration protocol is already 'hidden' when using for..in. What am I missing? Nothing, it's just me and the bad influence that lisp has on my mind :). Sorry to bother the list then. Thanks for the kind replies. -- Valentino Volonghi aka Dialtone Now Running MacOSX 10.4 Blog: http://vvolonghi.blogspot.com http://weever.berlios.de pgpeKPBtN4P2s.pgp Description: PGP signature ___ 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
