Bugfix for #1470540 (XMLGenerator cannot output UTF-16)

[loewis]

http://bugs.python.org/review/1470548/diff/5039/Lib/xml/sax/saxutils.py
File Lib/xml/sax/saxutils.py (right):

http://bugs.python.org/review/1470548/diff/5039/Lib/xml/sax/saxutils.py#newco...
Lib/xml/sax/saxutils.py:18: _error_handling = "strict"
I think this variable _error_handling can go, and its only use be replaced by
"xmlcharrefreplace".

http://bugs.python.org/review/1470548/diff/5039/Lib/xml/sax/saxutils.py#newco...
Lib/xml/sax/saxutils.py:82: def __init__(self, out=None, encoding=None,
short_empty_elements=False):
Why do you drop the default value for encoding? XMLGenerator certainly needs to
continue to create bytes by default. It's documented to default to iso-8859-1,
so I see no reason to change it.

[storchaka]

http://bugs.python.org/review/1470548/diff/5039/Lib/xml/sax/saxutils.py
File Lib/xml/sax/saxutils.py (right):

http://bugs.python.org/review/1470548/diff/5039/Lib/xml/sax/saxutils.py#newco...
Lib/xml/sax/saxutils.py:18: _error_handling = "strict"
On 2012/05/30 19:06:39, loewis wrote:
> I think this variable _error_handling can go, and its only use be replaced by
> "xmlcharrefreplace".

I suspected this, but wanted to know your opinion, as the author of this code.

http://bugs.python.org/review/1470548/diff/5039/Lib/xml/sax/saxutils.py#newco...
Lib/xml/sax/saxutils.py:82: def __init__(self, out=None, encoding=None,
short_empty_elements=False):
On 2012/05/30 19:06:39, loewis wrote:
> Why do you drop the default value for encoding? XMLGenerator certainly needs
to
> continue to create bytes by default. It's documented to default to
iso-8859-1,
> so I see no reason to change it.

In Python 3 XMLGenerator creates unicode string by default.  Output to StringIO
is used in the tests and may often used in third-party code. I have kept this
behavior.

encoding="iso-8859-1" is bad choice by default for output to sys.stdout (the
default value for an out). Will be better to use "us-ascii" or encoding of a
sys.stdout.

In any case, something has to change.

[AntoinePitrou]

http://bugs.python.org/review/1470548/diff/5409/Lib/test/test_sax.py
File Lib/test/test_sax.py (right):

http://bugs.python.org/review/1470548/diff/5409/Lib/test/test_sax.py#newcode165
Lib/test/test_sax.py:165: result = BytesIO()
Is output to a StringIO still tested somewhere?

http://bugs.python.org/review/1470548/diff/5409/Lib/xml/sax/saxutils.py
File Lib/xml/sax/saxutils.py (right):

http://bugs.python.org/review/1470548/diff/5409/Lib/xml/sax/saxutils.py#newco...
Lib/xml/sax/saxutils.py:80: import sys
You should import sys at the top level.

http://bugs.python.org/review/1470548/diff/5409/Lib/xml/sax/saxutils.py#newco...
Lib/xml/sax/saxutils.py:101: try:
If it only has a write() method then this "try" block is useless.

http://bugs.python.org/review/1470548/diff/5409/Lib/xml/sax/saxutils.py#newco...
Lib/xml/sax/saxutils.py:122: self._close
self._close(), no?

[storchaka]

http://bugs.python.org/review/1470548/diff/5409/Lib/test/test_sax.py
File Lib/test/test_sax.py (right):

http://bugs.python.org/review/1470548/diff/5409/Lib/test/test_sax.py#newcode165
Lib/test/test_sax.py:165: result = BytesIO()
On 2012/12/28 13:37:33, AntoinePitrou wrote:
> Is output to a StringIO still tested somewhere?

No.

http://bugs.python.org/review/1470548/diff/5409/Lib/xml/sax/saxutils.py
File Lib/xml/sax/saxutils.py (right):

http://bugs.python.org/review/1470548/diff/5409/Lib/xml/sax/saxutils.py#newco...
Lib/xml/sax/saxutils.py:80: import sys
On 2012/12/28 13:37:33, AntoinePitrou wrote:
> You should import sys at the top level.

This was in old code.

http://bugs.python.org/review/1470548/diff/5409/Lib/xml/sax/saxutils.py#newco...
Lib/xml/sax/saxutils.py:101: try:
On 2012/12/28 13:37:33, AntoinePitrou wrote:
> If it only has a write() method then this "try" block is useless.

However it can have not only a write() method.

http://bugs.python.org/review/1470548/diff/5409/Lib/xml/sax/saxutils.py#newco...
Lib/xml/sax/saxutils.py:122: self._close
On 2012/12/28 13:37:33, AntoinePitrou wrote:
> self._close(), no?

Yes, of course.