homepage

In the documentation for xml.sax.xmlreader.InputSource objects
(section 8.12.4 of the Library Reference) we find that
users of InputSource objects should use the following
sequence to get their input data:
1. If the InputSource has a character stream, use that.
2. Otherwise, if the InputSource has a byte stream, use that.
3. Otherwise, open a URI connection to the system ID.
prepare_input_source() skips step 1.
This is a one-line fix in Lib/xml/sax/saxutils.py:
- if source.getByteStream() is None:
+ if source.getCharacterStream is None and source.getByteStream() is 
None:

Oops, obvious typo, sorry:
- if source.getByteStream() is None:
+ if source.getCharacterStream() is None and source.getByteStream() is 
None:

Could you please provide a simple little test case for the bug? I'd
like to add a test when I commit the change, but you can probably boil
the problem down into a test faster than I can.

Sure. Here is a simple test case:
 def testUseCharacterStream(self):
 '''If the source is an InputSource with a character stream, use 
it.'''
 src = xml.sax.xmlreader.InputSource(temp_file_name)
 src.setCharacterStream(StringIO.StringIO(u"foo"))
 prep = xml.sax.saxutils.prepare_input_source(src)
 self.failIf(prep.getCharacterStream() is None, "ignored character 
stream")
If "temp_file_name" is omitted, you'll get an
AttributeError, and if you put it in but the
file doesn't exist, you'll get an IOError.
I'm attaching an almost full set of tests.
It omits the case of a URL. You can easily
put that in if you have a handy function that
converts a file path to a file URL, with all
the fidgety stuff you need for Windows. (Does that
already exist somewhere?)
Unfortunately, I now see that the problem
is a bit deeper than this. There are two more
related bugs that need to be fixed before
this really works.
See #2174 and #2175.

Are this and the other issues still problems in 2.7 (rc out now) and 3.1?

There's a one line patch in msg57749 and some unit tests are attached so would a committer take a look please. Also note that #2174 and #2175 are related.

Fixed in issue2175.