I ran 'python setup.py --author' for the pypi package "ll-orasql-0.6"
(whose author name has non-ascii characters) under subprocess.Popen and
this is what I get:

Traceback (most recent call last):
  File "/home/sridharr/as/pypm/bin/python", line 39, in <module>
    execfile(sys.argv[0])
  File "setup.py", line 50, in <module>
    package_dir={"ll": ""}
  File "/opt/ActivePython-2.6/lib/python2.6/distutils/core.py", line
138, in setup
    ok = dist.parse_command_line()
  File "/opt/ActivePython-2.6/lib/python2.6/distutils/dist.py", line
456, in parse_command_line
    if self.handle_display_options(option_order):
  File "/opt/ActivePython-2.6/lib/python2.6/distutils/dist.py", line
704, in handle_display_options
    print value
UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in
position 8: ordinal not in range(128)

When ran under the console, this exception is not seen. Otherwise, the
return code is 1 and nothing (apart from the above exception) is printed.

How to reproduce?
=================

Download `ll-orasql-0.6` from PyPI and run the following in the Python
shell:

>>> subprocess.Popen('python setup.py --author', stdout=subprocess.PIPE,
shell=True).stdout.read()

This is not a bug in distutils, but how print works when executed
through subprocess. 

here's a demo:

Create a file called "test.py" with:

  # -*- coding: utf8 -*-
  print u'éééé'

Now another one called "test2.py" with:

  import subprocess

  subprocess.Popen('python test.py', stdout=subprocess.PIPE,
shell=True).stdout.read()

Now launch test2:

  $ python test2.py 
  Traceback (most recent call last):
  File "test.py", line 2, in <module>
    print u'éééé'
  UnicodeEncodeError: 'ascii' codec can't encode characters in position 
0-3: ordinal not in range(128)

I don't know about the internals of print, and I am not sure this is a
bug, so I'll put Marc-André in the loop.

Sridhar, can you test with the envvar PYTHONIOENCODING set to UTF-8?

"PYTHONIOENCODING=UTF-8 python test2.py" does work.

I agree with Tarek this is not a bug, and there is a workaround, so I’m closing this.