[Python-Dev] Re: Python multiplexing is too hard (was: Network statistics program)

Guido van Rossum guido@python.org
Fri, 19 May 2000 08:13:01 -0700


[Quoting the entire mail because I've added python-dev to the cc:
list]

> Subject: Re: Python multiplexing is too hard (was: Network statistics program)
> From: Alexandre Ferrieux <alexandre.ferrieux@cnet.francetelecom.fr>
> To: Guido van Rossum <guido@python.org>
> Cc: claird@starbase.neosoft.com
> 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.
> 
> Overkill.
> 
> >  Or you could probably
> > use unix domain sockets (popen only really works on
> > Unix, so that's not much of a restriction).
> 
> Overkill.
> 
> > 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...
> 
> Consider:
> 
> 	- 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 
> 		  anyway.
> 
> 	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
> Python.
> 		
> -Alex

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/)