For a stream with a "poor" encoding, such as sys.stderr on Windows where 
encoding is cp437, the encoding of an unicode message will fail 
(expected) and then a fallback encoding to UTF-8 will be done:

(in 
http://code.python.org/hg/trunk/file/bd98b2c097fe/Lib/logging/__init__.p
y#l837):
837                 except UnicodeError:
838                     stream.write(fs % msg.encode("UTF-8"))

However, that fallback won't work, as at this point, fs was already 
converted to unicode and is now u'%s\n', so the (msg.encode("UTF-8")) 
str will be decoded to unicode again using the default encoding, which 
will likely fail with a UnicodeDecodeError if msg contains non-ascii 
characters.

The solution would be to keep using fs as "%s\n" in this line.

This is similar to issue6991, but not exactly the same and it only 
happens for Python 2.7. Using logging_error.py, I've tested Python 2.3 
to Python 2.6 (works) and Python 2.7a1 (fails), current trunk must have 
the same issue as 2.7a1. Patch follows.

One way to solve the issue. 

PS: copy/pasting URLs to the Mercurial repo apparently doesn't work, for 
some reason (probably the line anchor); the URL I gave above was:

 http://code.python.org/hg/trunk/file/bd98b2c097fe/Lib/logging/__init__.py

 + #l837

PPS: Ok, links to the Mercurial repo /really/ don't work, and it was not 
the #l837 part ;-)

Sorry Christian, your patch appears just to rename 'fs' to 'ufs' so I'm
not sure if your patch is exactly what you intended.

Never mind my earlier comment, I looked at the change more carefully
after a cup of coffee, and it now makes sense to me ;-)

Fixed checked into trunk (r76754), thanks.

Hello Vinay, 

I recently installed Python 2.6.5, and I see this buglet is also present there. When I reported the issue, I said 2.6 worked and IIRC it must have been 2.6 or 2.6.1. 

I don't know if it's worth to backport the fix for 2.6.6, but just in case, I wanted to let you know.

Only security fixes and documentation fixes are allowed to go into stable branches.