values of sys.platform? for a serial port lib

Peter Hansen peter at
Sat Dec 29 21:57:41 EST 2001

Chris Liechti wrote:
> Peter Hansen <peter at> wrote:
> > I'd strongly recommend you *not* try to use an
> > index origin of 0 but instead pass the open() routine (or
> > whatever you have) a *string* naming the serial port.
> i want it to run mainly on win32 and linux. the user of the lib should not
> need to care about device names.

Very good point.  Let me change my recommendation and say don't 
*prevent* someone from specifying a special-case name for the device.  
The fact that this matches what you actually did in no way indicates my
original comment was wrong or simplistic or any other bad thing. <grin>

> i also have an optional argument to specify the port string, but when this
> is used it isn't portable anymore.

Just a thought, but could you make this the same argument as 
the port number, allowing either an integer or a string?  
I could also see a benefit, in a cross-platform serial-port app, 
in having a method to return the actual device name in use, for 
display/troubleshooting purposes, even if specified as a number.

> > By the way, does your win32 implementation work well with
> > threads, if one thread is trying to read from the port while
> > the other is trying to write to it?
> i haven't tested it that way. i use it in a multi-threaded environment, but
> the class that accesses the serial port (and generates binary communication
> frames) uses means from the module threading.

You may know this already, but in Windows you need to use 
"overlapped" I/O operations if you want to be able to have
a read thread and a write thread waiting independently on 
operations on the same serial port.  Without this, any time 
one thread is blocked waiting for results for its operation, 
the other thread will also block when it tries to access the 
device even if its operation would not otherwise block.  
(Or something like that... I don't know the full details 
behind it, only what I learned trying to implement a win32file-
based serial port class which didn't have this limitation.)

Peter Hansen, P.Eng.
peter at

More information about the Python-list mailing list