[Python-Dev] Re: Python multiplexing is too hard (was: Network statistics program)
Guido van Rossum
Fri, 19 May 2000 08:13:01 -0700
[Quoting the entire mail because I've added python-dev to the cc:
> Subject: Re: Python multiplexing is too hard (was: Network statistics program)
> From: Alexandre Ferrieux <firstname.lastname@example.org>
> To: Guido van Rossum <email@example.com>
> Cc: firstname.lastname@example.org
> Date: Fri, 19 May 2000 11:25:43 +0200
> Delivery-Date: Fri May 19 05:26:59 2000
> Guido van Rossum wrote:
> > Cameron Laird wrote:
> > > .
> > > Right. asyncore is nice--but restricted to socket
> > > connections. For many applications, that's not a
> > > restriction at all. However, it'd be nice to have
> > > such a handy interface for communication with
> > > same-host processes; that's why I mentioned popen*().
> > > Does no one else perceive a gap there, in convenient
> > > asynchronous piped IPC? Do folks just fall back on
> > > select() for this case?
> > Hm, really? For same-host processes, threads would
> > do the job nicely I'd say.
> > Or you could probably
> > use unix domain sockets (popen only really works on
> > Unix, so that's not much of a restriction).
> > Also note that often this is needed in the context
> > of a GUI app; there something integrated in the GUI
> > main loop is recommended. (E.g. the file events that
> > Moshe mentioned.)
> Okay so your answer is, The Python Way of doing it is to use Tcl.
> That's pretty disappointing, I'm sorry to say...
> - In Tcl, as you said, this is nicely integrated with the GUI's
> event queue:
> - on unix, by a an additional bit on X's fd (socket) in
> the select()
> - on 'doze, everything is brought back to messages
> And, in both cases, it works with pipes, sockets, serial or other
> devices. Uniform, clean.
> - In python "popen only really works on Unix": are you satisfied with
> that state of affairs ? I understand (and value) Python's focus on
> algorithms and data structures, and worming around OS misgivings is a
> boring, ancillary task. But what about the potential gain ?
> I'm an oldtime Tcler, firmly decided to switch to Python, 'cause it is
> just so beautiful inside. But while Tcl is weaker in the algorithms, it
> is stronger in the os-wrapping library, and taught me to love high-level
> abstractions. [fileevent] shines in this respect, and I'll miss it in
Alex, it's disappointing to me too! There just isn't anything
currently in the library to do this, and I haven't written apps that
needs this often enough to have a good feel for what kind of
abstraction is needed.
However perhaps we can come up with a design for something better? Do
you have a suggestion here?
I agree with your comment that higher-level abstractions around OS
stuff are needed -- I learned system programming long ago, in C, and
I'm "happy enough" with the current state of affairs, but I agree that
for many people this is a problem, and there's no reason why Python
couldn't do better...
--Guido van Rossum (home page: http://www.python.org/~guido/)