[issue1286] fileinput, StringIO, and cStringIO do not support the with protocol
Changes by Yitz Gale: -- components: Extension Modules nosy: ygale severity: normal status: open title: fileinput, StringIO, and cStringIO do not support the with protocol type: behavior versions: Python 2.5, Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1286> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 and StringIO - since these really are files, in some sense. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1286> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: If these objects do not support the with protocol, the only way to use them is to refactor this code. That may not even be possible, e.g., if it is in a library, or it may not be desirable to refactor. Even if you can refactor it, I don't think you can call these objects file-like objects if you can't use them like a file. Note that in legacy code, you used to write: fh = function_to_get_fh try: finally: fh.close() If function_to_get_fh happens to return some other file-like object and not an actual file, this still works fine without any refactoring. You wrote: > In Py3k, I don't think adding support > for the 'with' statement to StringIO makes > any sense, since the close() > method does nothing. So do you propse removing the close() method altogether? Of course the answer is "no", because then you could not use the object like a file. The same is true for the with protocol. (I now retract the words "that needs to be closed" from my original comment. All file-like objects should support the with protocol, regardles of whether their close() method actually does anything.) __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1286> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 the place to handle StringIO as a special case. What a mess! Why is this getting over-excited? It's a very lightweight change. You can't beat the cost/benefit ratio. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1286> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. 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: -- components: Library (Lib) messages: 57737 nosy: ygale severity: normal status: open title: xml.sax.saxutils.prepare_input_source ignores character stream in InputSource versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1483> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2175] Expat sax parser silently ignores the InputSource protocol
Yitz Gale 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 support it. But that seems a little extreme. -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue2175> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. Otherwise, if the InputSource has a byte stream, use that. 3. Otherwise, open a URI connection to the system ID. The parse() method of IncrementalParser skips step 1. In addition, we need to add a method getSourceEncoding() to the XMLReader interface; if non-null, it will indicate to the parser that the input is a byte stream in the given encoding. The documentation should indicate what the parser should do if the XML itself announces that its encoding is something else. I propose that the parser should be required to raise an error in that case. See also #1483. -- components: Documentation, Library (Lib), XML messages: 62900 nosy: ygale severity: normal status: open title: xml.sax.xmlreader does not support the InputSource protocol type: behavior versions: Python 2.5, Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2174> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 to UTF-8. Rather than silently doing the wrong thing, it should raise an error when fed a character stream, or when given an encoding, via the InputSource interface. And most importantly, these limitations should be mentioned in the documentation. -- components: Documentation, Extension Modules, Library (Lib), Unicode, XML messages: 62901 nosy: ygale severity: normal status: open title: Expat sax parser silently ignores the InputSource protocol type: behavior versions: Python 2.5, Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2175> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1483] xml.sax.saxutils.prepare_input_source ignores character stream in InputSource
Yitz Gale added the comment: 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. Added file: http://bugs.python.org/file9536/test_prepare_input_source.py __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1483> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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, it will have to look in the XML for an encoding declaration, or use UTF-8 by default). Note that expat only can handle the latter case. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2174> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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(), returning a bool. There is a more drastic option: 3. Since expat doesn't support this stuff anyway, and perhaps not too many people have written parsers that do support it, dumb down the InputSource interface. Specifically, deprecate setCharacterStream(), getCharacterStream(), setEncoding() and getEncoding(), none of which are used by expat. Parsers should read the XML from the byte stream and use that to determine the encoding. That may upset some implementors of XML libraries though. They would each have to go to some trouble to provide their own proprietary and possibly incompatible mechanisms for this, if they need it. Perhaps a compromise fourth path would be to have subclasses of InputSource for the two cases of character stream and byte stream. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2174> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7612] Fix "pass and object" typo in Library Reference / Built-in Types / Sequence Types
New submission from Yitz Gale : 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: georg.brandl, ygale severity: normal status: open title: Fix "pass and object" typo in Library Reference / Built-in Types / Sequence Types versions: Python 3.1 Added file: http://bugs.python.org/file15710/typo_pass_and_object.patch ___ Python tracker <http://bugs.python.org/issue7612> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl
Changes by Yitz Gale : -- nosy: +ygale ___ Python tracker <http://bugs.python.org/issue6154> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9498] stdtypes.rst should refer to sys.float_info
New submission from Yitz Gale : 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. There should be a reference to that here instead of that statement. In addition, that paragraph mentions that both float and complex are "implemented using double in C". There is no longer any special reason to mention how those are implemented in C, any more than anything else in Python. Everything you need to know about the implementation is in sys.float_info. (Well, almost everything, see #9192.) The attached patch is for the Python 3.2 branch. -- assignee: d...@python components: Documentation files: stdtypes_float_info.patch keywords: patch messages: 112670 nosy: d...@python, ygale priority: normal severity: normal status: open title: stdtypes.rst should refer to sys.float_info type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file18353/stdtypes_float_info.patch ___ Python tracker <http://bugs.python.org/issue9498> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9498] stdtypes.rst should refer to sys.float_info
Yitz Gale 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 we're not committing ourselves to anything. -- ___ Python tracker <http://bugs.python.org/issue9498> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9498] stdtypes.rst should refer to sys.float_info
Changes by Yitz Gale : Added file: http://bugs.python.org/file18355/stdtypes_float_info_2.patch ___ Python tracker <http://bugs.python.org/issue9498> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
