On Windows, os.popen with an invalid mode throw a
ValueError and on POSIX systems it throws an OSError.

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os
>>> os.popen('dir', '')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: popen() arg 2 must be 'r' or 'w'

Python 2.3 (#167, Sep  1 2003, 06:38:18)
[GCC 3.0.4] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os
>>> os.popen('ls', '')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OSError: [Errno 22] Invalid argument

Additionally, the ValueError message is incorrect; arg
2 can be 'r', 'rb', 'rt', 'w', 'wb', or 'wt'.

Logged In: YES 
user_id=1188172

Should the exceptions be synchronized?

This snippet still raises 'OSError: [Errno 22] ...' in Linux:

import os
os.popen('ls', '')

Can anyone do a quick check on Windows?

On Windows:

>>> os.popen("cmd", "")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: popen() arg 2 must be 'r' or 'w'

Windows has a specific implementation of os.popen, which does validate 
the mode. Whereas on POSIX platforms, the parameters are passed as is to 
the popen() function.
I'd call this an "implementation detail", and the exact exception is not 
important IMO.

I can confirm this but, but os.popen() is deprecated in 2.6 hence there
is no point in fixing generated exception even though in a language that
claims to be cross-platform exceptions should be unified.

I would add os.popen to keywords list for future reference and close
this bug as "won't fix". There are many other bugs about os.popen on
windows platform and people would be interested to know exactly why
subprocess should be used.

Closed as os.popen deprecated in favour of subprocess.popen.