Re: asynchat and threading
Anthony Baxter wrote: > > AFAICT, the main complaint is that it is tied to the TCP transport, > > the sockets API, and the select/poll API. IOW, it cannot easily: > > - integrate TLS on top of TCP (because TLS might involve no-data > >communications, e.g. when TLS negotation happens in the middle > >of a TLS session), > > - integrate other transports, such as serial ports on Windows, > > - integrate other multi-endpoint wait APIs, such as IO completion > >ports on Windows NT+, or kqueue on BSD. > > - work with other event loops, such as GUI toolkits sure can. but sure, if you don't want it to work, nothing stops you from writing crappy code. we've been using asyncore/medusa on high-performance servers for nearly 10 years; I think we'd noticed by now if the library was seriously broken. -- http://mail.python.org/mailman/listinfo/python-list
Re: asynchat and threading
Jp Calderone wrote: Why not use apt-get? well, I am recommending using apt-get but within entirely different and separate namespace for modules. But on second thought,, it might not be necessary to separate the namespace. If you just need to add the repository for Python modules to the apt-get configuration files, it might just work. hmmm. the trick would be making modules that were multiplatform/distribution aware. ---eric -- http://mail.python.org/mailman/listinfo/python-list
Re: asynchat and threading
On Mon, 29 Nov 2004 23:24:54 -0500, Caleb Hattingh <[EMAIL PROTECTED]> wrote: > I heartily support something like this, but alas I have not the time to > help out with it. I like the Enthought python distribution because it > installs several packages in one shot. A pity there isn't a similar thing > for python addons in Linux (or is there?). Plenty of people would like to see this. Alas, no-one has stepped forward to do the work (or, if you have money but no time, to offer to fund the work). Python runs on volunteers - no-one's done this yet, so it's not happened. -- http://mail.python.org/mailman/listinfo/python-list
Re: asynchat and threading
"Eric S. Johansson" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > this points to an important issue that should be addressed at some point > which is the ability to quickly and easily, on the level of rpm or > apt-get, import external frameworks. Depending on your distribution, this may be already available. For instance in Mandrake 10.1 I just tried # urpmi python-twisted and it downloaded twisted 1.3. Seems to work too. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: asynchat and threading
On Mon, 29 Nov 2004 16:05:14 -0500, "Eric S. Johansson" <[EMAIL PROTECTED]> wrote: > If I could simply do: py-get twisted > and have all of the dependencies resolved, it would be wonderful. as a > prototype, I would suggest wrapping apt-get with a python envelope which > automatically invokes apt-get with a python specific configuration > file for .pydeb files as well as a private repository and database etc.. > Since apt-get exists for almost every version of Linux and should be > portable to other platforms, this distribution method should be > relatively distribution portable. > > One can also handle upgrades of the core image of Python and ancillary > packages as well by leaving a breadcrumb file indicating which packaging > system is native and the package currently installed. <<- idea needs work > > yea? nay? > Why not use apt-get? Jp -- http://mail.python.org/mailman/listinfo/python-list
Re: asynchat and threading
I heartily support something like this, but alas I have not the time to help out with it. I like the Enthought python distribution because it installs several packages in one shot. A pity there isn't a similar thing for python addons in Linux (or is there?). Something apt-get-like would be cool. Was there talk of having the python package index support something like this at some stage? If I could simply do: py-get twisted and have all of the dependencies resolved, it would be wonderful. as a prototype, I would suggest wrapping apt-get with a python envelope which automatically invokes apt-get with a python specific configuration file for .pydeb files as well as a private repository and database etc.. Since apt-get exists for almost every version of Linux and should be portable to other platforms, this distribution method should be relatively distribution portable. One can also handle upgrades of the core image of Python and ancillary packages as well by leaving a breadcrumb file indicating which packaging system is native and the package currently installed. <<- idea needs work yea? nay? ---eric -- http://mail.python.org/mailman/listinfo/python-list
Re: asynchat and threading
Anthony Baxter wrote: twisted is too large to go into the python core as is - in addition, there's a mismatch between Python's release cycle speed and twisted's release cycle speed (although the current delayed-until-who-knows-when Twisted 2.0 might be a harbinger of twisted slowing down to Python's speed ) It's possible that in the future a small core of twisted could end up in the stdlib - this topic's come up a couple of times on the twisted list (most recently, a couple of months ago). I wonder if the asyncore docs couldn't grow a 'See also' that points at twisted, though... this points to an important issue that should be addressed at some point which is the ability to quickly and easily, on the level of rpm or apt-get, import external frameworks. I have a body of code which counts on smtpd.py and pop3d.py. I have modified both and just created new versions to sit within my application. Easy integration. If I was to count on twisted, I would have another fetch fest collecting all the pieces as well as increasing the complexity of building my application. If I could simply do: py-get twisted and have all of the dependencies resolved, it would be wonderful. as a prototype, I would suggest wrapping apt-get with a python envelope which automatically invokes apt-get with a python specific configuration file for .pydeb files as well as a private repository and database etc.. Since apt-get exists for almost every version of Linux and should be portable to other platforms, this distribution method should be relatively distribution portable. One can also handle upgrades of the core image of Python and ancillary packages as well by leaving a breadcrumb file indicating which packaging system is native and the package currently installed. <<- idea needs work yea? nay? ---eric -- http://mail.python.org/mailman/listinfo/python-list
