[issue2175] Expat sax parser silently ignores the InputSource protocol

Yitz Gale g...@sefer.org added the comment: Perhaps more people would be interested if you raise the priority. This bug can cause serious data corruption, or even crashes. It should also be tagged as easy. An alternative would be to remove the expat sax parser from the libraries, since we don't

[issue9498] stdtypes.rst should refer to sys.float_info

New submission from Yitz Gale g...@sefer.org: Library docs section 5.4 Numeric Types states about floating point numbers that all bets on their precision are off unless you happen to know the machine you are working with. That has not been true since Python 2.6, when sys.float_info was added

[issue9498] stdtypes.rst should refer to sys.float_info

Yitz Gale g...@sefer.org added the comment: It's not necessarily true for other than CPython, and it could theoretically not be true someday on some weird platform even for CPython. How about just adding this: Floating point numbers are usually implemented using double in C. Then at least

[issue9498] stdtypes.rst should refer to sys.float_info

Changes by Yitz Gale g...@sefer.org: Added file: http://bugs.python.org/file18355/stdtypes_float_info_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9498

[issue7612] Fix pass and object typo in Library Reference / Built-in Types / Sequence Types

New submission from Yitz Gale g...@sefer.org: Change if you pass and object of the wrong type to if you pass an object of the wrong type in stdtypes.rst. -- assignee: georg.brandl components: Documentation files: typo_pass_and_object.patch keywords: patch messages: 97086 nosy

[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl

Changes by Yitz Gale g...@sefer.org: -- nosy: +ygale ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6154 ___ ___ Python-bugs-list mailing list

[issue2174] xml.sax.xmlreader does not support the InputSource protocol

New submission from Yitz Gale: 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

[issue2175] Expat sax parser silently ignores the InputSource protocol

New submission from Yitz Gale: The expat sax parser in xml.sax.expatreader does not fully support the InputSource protocol in xml.sax.xmlreader. It only accepts byte streams. It ignores the encoding indicated in the InputStream object and only uses the encoding read from the XML or defaults

[issue2175] Expat sax parser silently ignores the InputSource protocol

Yitz Gale added the comment: See also: #1483 and #2174. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2175 __ ___ Python-bugs-list mailing list Unsubscribe: http

[issue2174] xml.sax.xmlreader does not support the InputSource protocol

Yitz Gale added the comment: See also: #1483 and #2175. -- components: +Unicode __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2174 __ ___ Python-bugs-list mailing list

[issue2174] xml.sax.xmlreader does not support the InputSource protocol

Yitz Gale added the comment: Hmm. When getSourceEncoding() is None, there needs to be some way for the parser to distinguish between the cases where it is getting pre-decoded Unicode through a character stream, or where it is getting a byte stream with an unspecified encoding. In the latter case

[issue2174] xml.sax.xmlreader does not support the InputSource protocol

Yitz Gale added the comment: So I think there are two possibilities: 1. Use a special value for getSourceEnconding(), like unicode, to indicate that this is a unicode character stream and not a byte stream. 2. Provide yet another method in the XMLReader interface: sourceIsCharacterStream

[issue2174] xml.sax.xmlreader does not support the InputSource protocol

Yitz Gale added the comment: Subclass of XMLReader would be needed, not InputStream. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2174 __ ___ Python-bugs-list mailing list

[issue1483] xml.sax.saxutils.prepare_input_source ignores character stream in InputSource

Yitz Gale added the comment: Oops, obvious typo, sorry: -if source.getByteStream() is None: +if source.getCharacterStream() is None and source.getByteStream() is None: __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1483

[issue1483] xml.sax.saxutils.prepare_input_source ignores character stream in InputSource

New submission from Yitz Gale: 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

[issue1286] fileinput, StringIO, and cStringIO do not support the with protocol

Yitz Gale added the comment: I was actually bitten badly by this issue with StringIO. I added fileinput only as an afterthought. In an xml.sax app, I needed seek() support for a codec-wrapped file handle, so I over-wrapped it with StringIO. The result was that I had to refactor code all over

[issue1286] fileinput, StringIO, and cStringIO do not support the with protocol

Yitz Gale added the comment: These objects are supposed to be drop-in replacements for file handles. Except in legacy code, the way you use a file handle is: with function_to_create_fh as fh: do stuff If these objects do not support the with protocol, the only way to use them is to refactor

[issue1286] fileinput, StringIO, and cStringIO do not support the with protocol

New submission from Yitz Gale: The standard idiom for opening a file is now with open... So I think it should be a goal that this should work with any built-in file-like object that needs to be closed, without having to explicitly wrap it in closing(). It certainly should work for fileinput