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&#x
Changes by Yitz Gale :
Added file: http://bugs.python.org/file18355/stdtypes_float_info_2.patch
___
Python tracker
<http://bugs.python.org/issue9498>
___
___
Python-bug
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
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_i
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:
Changes by Yitz Gale :
--
nosy: +ygale
___
Python tracker
<http://bugs.python.org/issue6154>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Yitz Gale added the comment:
Subclass of XMLReader would be needed, not InputStream.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2174>
__
___
Python-bugs-list
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: sourceIsChara
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
Yitz Gale added the comment:
See also: #1483 and #2175.
--
components: +Unicode
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2174>
__
___
Python-bugs-
Yitz Gale added the comment:
See also: #1483 and #2174.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2175>
__
___
Python-bugs-list mailing list
Unsubs
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(Strin
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
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
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/
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
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
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
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
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 <[EM
20 matches
Mail list logo
