On Mon, Mar 24, 2008 at 10:21 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 24, 2008 at 3:04 PM, Thomas Wouters <[EMAIL PROTECTED]> wrote: > > > > On Fri, Feb 15, 2008 at 9:11 PM, Josiah Carlson < > [EMAIL PROTECTED]> > > wrote: > > > Twisted core has been proposed, but I believe the consensus was that > > > it wasn't desirable, generally. > > > > > > > I remember only a couple of dissenting voices, and only a small number > of > > participants. Of the dissenting voices, I do not recall any actual > arguments > > about undesireability, just misunderstandings of how Twisted actually > works. > > Getting Twisted core (meaning Deferreds, a simple reactor and the > Protocol > > class) into the core is still on my TODO list. > > > > > > > I'm also pretty sure that people learn twisted because everyone learns > > > twisted. It's one of those buzz-words ;). > > > > > > > I think that's quite an unfair assessment, even in jest :) Twisted is > well > > worth learning to actually use it, as it's a very versatile event loop > and > > does it best to integrate nicely with other event systems. And including > it > > in the standard library improves integration with other event loops by > > creating a single interface. It's not a matter of dropping it in, > though; it > > requires some careful structuring to avoid embarrassing situations like > we > > have with the xml package, but still people to provide their own > reactor. > > > > In case you're wondering how the twisted reactor in the stdlib is useful > to > > people not using Twisted, take a look at what you currently need to do > to > > combine stdlib modules like urllib and ftplib with event systems like > > Tkinter and PyGTK. Not to mention that the Twisted implementations of > > various protocols are really quite, quite good -- in many cases quite a > lot > > better than the stdlib ones. But including those takes yet more time. > > In that sense it'd be competing with safethread for inclusion in > Python. Whereas safethread requires little if any API changes, > twisted requires an entirely new API that can be event-driven. Worse, > we'd likely to be stuck maintaining both APIs for a long time, if not > forever. > I am not going to worry about this for the time being. Even if safethread goes in and becomes ubiquitous, Twisted is still a very valid approach to the problem. And I'm not just saying that because I don't subscribe to your enthusiasm of safethreads as a concept or as an implementation :) > > Twisted may be one of the best (if not *the* best) ways of writing > concurrent programs today, but it doesn't need to be in the stdlib for > that. If safethread is going to solve many of the same problems, with > less changes required by the users of the language, then this is the > wrong time to add twisted. > You must have missed the part where we already have a large set of event loops, and not having a single interface to them is in fact hurting people. Twisted goes out of its way to interact nicely with event loops, but it can only do that with ones it knows about (and are versatile enough to hook into.) Having a single event system in the standard library is definitely advantageous, even if safethreads were available everywhere and the performance in the common case was satisfactory. It used to be the case that people thought asyncore was this standard event system, but it's long since ceased to be. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
_______________________________________________ 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
