[issue1046] HTMLCalendar.formatyearpage not behaving as documented
Walter Dörwald added the comment: Fixed in r57620 -- nosy: +doerwalter resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1046> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1125] bytes.split shold have same interface as str.split, or different name
Walter Dörwald added the comment: Because it's not clear whether b'\xa0' *is* whitespace or not. Bytes have no meaning, characters do. -- nosy: +doerwalter __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1125> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1399] XML codec
Walter Dörwald added the comment: "xml-auto-detect" sounds OK to me, it even makes sense for the encoder, because it normally detects the encoding to use for writing from the XML declaration. We could put "xml-auto-detect" into the alias mapping and keep xml as the module name. But I noticed I have to rewrap a lot of lines, before I check it in. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1399> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1399] XML codec
Walter Dörwald added the comment:
OK, I've changed the name of the codec to xml_auto_detect and added
support for EBCDIC.
Added file: http://bugs.python.org/file8717/diff2.txt
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1399>
__Index: Include/pyerrors.h
===
--- Include/pyerrors.h (Revision 55955)
+++ Include/pyerrors.h (Arbeitskopie)
@@ -30,8 +30,8 @@
PyObject *args;
PyObject *encoding;
PyObject *object;
-PyObject *start;
-PyObject *end;
+Py_ssize_t start;
+Py_ssize_t end;
PyObject *reason;
} PyUnicodeErrorObject;
Index: Objects/exceptions.c
===
--- Objects/exceptions.c(Revision 55955)
+++ Objects/exceptions.c(Arbeitskopie)
@@ -955,36 +955,6 @@
SimpleExtendsException(PyExc_ValueError, UnicodeError,
"Unicode related error.");
-static int
-get_int(PyObject *attr, Py_ssize_t *value, const char *name)
-{
-if (!attr) {
-PyErr_Format(PyExc_TypeError, "%.200s attribute not set", name);
-return -1;
-}
-
-if (PyLong_Check(attr)) {
-*value = PyLong_AsSsize_t(attr);
-if (*value == -1 && PyErr_Occurred())
-return -1;
-} else {
-PyErr_Format(PyExc_TypeError, "%.200s attribute must be int", name);
-return -1;
-}
-return 0;
-}
-
-static int
-set_ssize_t(PyObject **attr, Py_ssize_t value)
-{
-PyObject *obj = PyInt_FromSsize_t(value);
-if (!obj)
-return -1;
-Py_CLEAR(*attr);
-*attr = obj;
-return 0;
-}
-
static PyObject *
get_bytes(PyObject *attr, const char *name)
{
@@ -1062,40 +1032,35 @@
int
PyUnicodeEncodeError_GetStart(PyObject *exc, Py_ssize_t *start)
{
-if (!get_int(((PyUnicodeErrorObject *)exc)->start, start, "start")) {
-Py_ssize_t size;
-PyObject *obj = get_unicode(((PyUnicodeErrorObject *)exc)->object,
-"object");
-if (!obj) return -1;
-size = PyUnicode_GET_SIZE(obj);
-if (*start<0)
-*start = 0; /*XXX check for values <0*/
-if (*start>=size)
-*start = size-1;
-Py_DECREF(obj);
-return 0;
-}
-return -1;
+PyObject *obj = get_unicode(((PyUnicodeErrorObject *)exc)->object,
+"object");
+Py_ssize_t size;
+if (!obj)
+return -1;
+*start = ((PyUnicodeErrorObject *)exc)->start;
+size = PyUnicode_GET_SIZE(obj);
+if (*start<0)
+*start = 0; /*XXX check for values <0*/
+if (*start>=size)
+*start = size-1;
+return 0;
}
int
PyUnicodeDecodeError_GetStart(PyObject *exc, Py_ssize_t *start)
{
-if (!get_int(((PyUnicodeErrorObject *)exc)->start, start, "start")) {
-Py_ssize_t size;
-PyObject *obj = get_bytes(((PyUnicodeErrorObject *)exc)->object,
- "object");
-if (!obj) return -1;
-size = PyBytes_GET_SIZE(obj);
-if (*start<0)
-*start = 0;
-if (*start>=size)
-*start = size-1;
-Py_DECREF(obj);
-return 0;
-}
-return -1;
+PyObject *obj = get_bytes(((PyUnicodeErrorObject *)exc)->object, "object");
+Py_ssize_t size;
+if (!obj)
+return -1;
+*start = ((PyUnicodeErrorObject *)exc)->start;
+size = PyBytes_GET_SIZE(obj);
+if (*start<0)
+*start = 0;
+if (*start>=size)
+*start = size-1;
+return 0;
}
@@ -1109,61 +1074,59 @@
int
PyUnicodeEncodeError_SetStart(PyObject *exc, Py_ssize_t start)
{
-return set_ssize_t(&((PyUnicodeErrorObject *)exc)->start, start);
+((PyUnicodeErrorObject *)exc)->start = start;
+return 0;
}
int
PyUnicodeDecodeError_SetStart(PyObject *exc, Py_ssize_t start)
{
-return set_ssize_t(&((PyUnicodeErrorObject *)exc)->start, start);
+((PyUnicodeErrorObject *)exc)->start = start;
+return 0;
}
int
PyUnicodeTranslateError_SetStart(PyObject *exc, Py_ssize_t start)
{
-return set_ssize_t(&((PyUnicodeErrorObject *)exc)->start, start);
+((PyUnicodeErrorObject *)exc)->start = start;
+return 0;
}
int
PyUnicodeEncodeError_GetEnd(PyObject *exc, Py_ssize_t *end)
{
-if (!get_int(((PyUnicodeErrorObject *)exc)->end, end, "end")) {
-Py_ssize_t size;
-PyObject *obj = get_unicode(((PyUnicodeErrorObject *)exc)->object,
-"object");
-if (!obj) return -1;
-size = PyUnicode_GET_SIZE(obj);
-if (*end<1)
-*end = 1;
-if (*end>size)
-
[issue1427] Error in standard module calendar
Walter Dörwald added the comment: Fixed in r58942 (trunk) and r58943 (2.5). Closing the issue. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1427> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1328] feature request: force BOM option
Walter Dörwald added the comment: jgsack wrote: > > If codec utf_8 or utf_8_sig were to accept input with or without the > 3-byte BOM, and write it as currently specified without/with the BOM > respectively, then _I_ can reread again with either utf_8 or utf_8_sig. That's exactly what the utf_8_sig codec does. The decoder accepts input with or without the BOM (the (first) BOM doesn't get returned). The encoder always prepends a BOM. Or do you want a codec that behaves like utf_8 on reading and like utf_8_sig on writing? Such a codec indead indead wouldn't roundtrip. -- nosy: +doerwalter __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1328> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1328] feature request: force BOM option
Walter Dörwald added the comment: > For utf16, (arguably) a missing BOM should merely assume machian endianess. > For utf_16_le, utf_16_be input, both should accept & discard a BOM. > On output, I'm not sure; maybe all should write a BOM unless passed a flag > signifying no bom? > Or to preserve backward compat, could have a parm write_bom defaulting to > True for utf16 and False for utf_16_le and utf_16_be. This is a > modification of the originial request (for a force_bom flag). The Unicode FAQ (http://unicode.org/faq/utf_bom.html#28) clearly states: """ Q: How I should deal with BOMs? [...] Where the precise type of the data stream is known (e.g. Unicode big-endian or Unicode little-endian), the BOM should not be used. In particular, whenever a data stream is declared to be UTF-16BE, UTF-16LE, UTF-32BE or UTF-32LE a BOM *must* not be used. [...] __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1328> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1444] utf_8_sig streamreader bug, patch, and test
Walter Dörwald added the comment: Checked in your change and the test as r59049 (trunk) and r59050 (2.5). Thanks for the patch. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1444> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1521] string.decode() fails on long strings
Walter Dörwald added the comment: Can you attach a (small) example that demonstrates the bug? -- nosy: +doerwalter __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1521> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12171] Reset method of the incremental encoders of CJK codecs calls the decoder reset function
Walter Dörwald added the comment: +1 on the documentation changes. -- nosy: +doerwalter ___ Python tracker <http://bugs.python.org/issue12171> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10087] HTML calendar is broken
Walter Dörwald added the comment: Does the following patch fix your problems? -- keywords: +patch nosy: +doerwalter Added file: http://bugs.python.org/file19217/calendar.diff ___ Python tracker <http://bugs.python.org/issue10087> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10038] json.loads() on str should return unicode, not str
Walter Dörwald added the comment: The following patch (against the release27-maint branch) seems to fix the problem. -- keywords: +patch nosy: +doerwalter Added file: http://bugs.python.org/file19468/json.diff ___ Python tracker <http://bugs.python.org/issue10038> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10329] trace.py and unicode in Python 3
New submission from Walter Dörwald : It seems that on Python 3 (i.e. the py3k branch) trace.py can not handle source that includes Unicode characters. Running the test suite with code coverage info via ./python Lib/test/regrtest.py -T -N -uurlfetch,largefile,network,decimal sometimes fails with the following exception: Traceback (most recent call last): File "Lib/test/regrtest.py", line 1500, in main() File "Lib/test/regrtest.py", line 696, in main r.write_results(show_missing=True, summary=True, coverdir=coverdir) File "/home/coverage/python/Lib/trace.py", line 319, in write_results lnotab, count) File "/home/coverage/python/Lib/trace.py", line 369, in write_results_file outfile.write(line.expandtabs(8)) UnicodeEncodeError: 'ascii' codec can't encode character '\xe4' in position 30: ordinal not in range(128) The script that produces code coverage info on http://coverage.livinglogic.de/ uses this feature to generate code coverage info. Applying the attached patch (i.e. specifying an explicit encoding when opening the output file) fixes the problem. -- files: trace.diff keywords: patch messages: 120506 nosy: doerwalter, haypo priority: normal severity: normal status: open title: trace.py and unicode in Python 3 Added file: http://bugs.python.org/file19505/trace.diff ___ Python tracker <http://bugs.python.org/issue10329> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10329] trace.py and unicode in Python 3
Walter Dörwald added the comment: Using the original encoding of the Python source file might be the politically correct thing to do, but it complicates handling of the output of trace.py. For each file you have to do the encoding detection dance again. It would be great if I could specify which encoding trace.py use (with the files encoding being the default). -- ___ Python tracker <http://bugs.python.org/issue10329> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10329] trace.py and unicode in Python 3
Walter Dörwald added the comment: > STINNER Victor added the comment: > >> ... it complicates handling of the output of trace.py. >> For each file you have to do the encoding detection dance again ... > > What? You just have to call one function! tokenize.open() :-) Well, ok, > it's not commited yet, but it looks like most people agree: #10335. The problem is that the script that downloads and builds the Python source and generates the HTML for http://coverage.livinglogic.de/ isn't ported to Python 3 yet (and can't be ported easily). However *running* the test suite of course uses the current Python checkout, so an option that lets me specify which encoding trace.py/regrtest.py should output would be helpful. -- ___ Python tracker <http://bugs.python.org/issue10329> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10541] regrtest.py -T broken
New submission from Walter Dörwald : Running regrtest.py with coverage option seems to be broken for the py3k branch at the moment. Run the following commands on the shell: wget http://svn.python.org/snapshots/python3k.tar.bz2 tar xjf python3k.tar.bz2 cd python ./configure --enable-unicode=ucs4 --with-pydebug make coverage ./python.exe Lib/test/regrtest.py -T -N test_urllib This gives the following output: [1/1] test_urllib Not printing coverage data for 'Lib/test/regrtest.py': [Errno 2] No such file or directory: 'Lib/test/regrtest.py' Traceback (most recent call last): File "Lib/test/regrtest.py", line 1502, in main() File "Lib/test/regrtest.py", line 698, in main r.write_results(show_missing=True, summary=True, coverdir=coverdir) File "/Users/walter/x/pybug/python/Lib/trace.py", line 331, in write_results with open(filename, 'rb') as fp: IOError: [Errno 2] No such file or directory: 'Lib/test/regrtest.py' [123146 refs] I'm testing on Mac OS X 10.6.5. Attached is the complete log of the shell session. This bug might be related to issue 10329, as the failing line was introduced in r86303. -- assignee: haypo components: Tests files: build.log messages: 122463 nosy: doerwalter, haypo priority: normal severity: normal status: open title: regrtest.py -T broken Added file: http://bugs.python.org/file19824/build.log ___ Python tracker <http://bugs.python.org/issue10541> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10541] regrtest.py -T broken
Walter Dörwald added the comment: OK, I reran the test with:: ./python -mtest.regrtest -T -N test_urllib and this does indeed produce coverage files (for _abcoll, _weakrefset, abc, base64, codecs, collections, contextlib, functools, genericpath, hashlib, locale, mimetypes, os, posixpath, quopri, random, re, sre_compile, sre_parse, ssl, stat, tempfile, textwrap, trace, uu, warnings). However running the complete test suite via:: ./python -mtest.regrtest -T -N -uurlfetch,largefile,network,decimal fails with:: Not printing coverage data for '/tmp/tmp0fdr9o/t4/sub/subsub/__init__.py': [Errno 2] No such file or directory: '/tmp/tmp0fdr9o/t4/sub/subsub/__init__.py' Traceback (most recent call last): File "/home/coverage/python/Lib/runpy.py", line 160, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/home/coverage/python/Lib/runpy.py", line 73, in _run_code exec(code, run_globals) File "/home/coverage/python/Lib/test/regrtest.py", line 1502, in main() File "/home/coverage/python/Lib/test/regrtest.py", line 698, in main r.write_results(show_missing=True, summary=True, coverdir=coverdir) File "/home/coverage/python/Lib/trace.py", line 331, in write_results with open(filename, 'rb') as fp: IOError: [Errno 2] No such file or directory: '/tmp/tmp0fdr9o/t4/sub/subsub/__init__.py' sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' encoding='ANSI_X3.4-1968'> (attached is the complete output of running the test suite (build2.log).) -- Added file: http://bugs.python.org/file19871/build2.log ___ Python tracker <http://bugs.python.org/issue10541> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706460] access to unicodedata (via codepoints or 2-char surrogates)
Walter Dörwald <[EMAIL PROTECTED]> added the comment: Fixed for 2.6 in r63899. -- nosy: +doerwalter resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1706460> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706460] access to unicodedata (via codepoints or 2-char surrogates)
Walter Dörwald <[EMAIL PROTECTED]> added the comment: Fixed for 3.0 in r63918 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1706460> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue701743] Reloading pseudo modules
Walter Dörwald <[EMAIL PROTECTED]> added the comment: AFAIK reload() is gone in 3.0 anyway, so I don't think this patch is relevant any longer. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue701743> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3739] unicode-internal encoder reports wrong length
New submission from Walter Dörwald <[EMAIL PROTECTED]>:
The encoder for the "unicode-internal" codec reports the wrong length:
Python 3.0b3+ (py3k, Aug 30 2008, 11:55:21)
[GCC 4.0.1 (Apple Inc. build 5484)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import codecs
>>> codecs.getencoder("unicode-internal")("a")
(b'a\x00', 2)
I would have expected it to output:
(b'a\x00', 1)
instead.
--
components: Unicode
messages: 72193
nosy: doerwalter
severity: normal
status: open
title: unicode-internal encoder reports wrong length
versions: Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3739>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7309] crasher in str(Exception())
Walter Dörwald added the comment: On 24.02.10 15:28, Eric Smith wrote: > Eric Smith added the comment: > > Fixed: > > trunk: r78418 > release26-maint: r78419 > > Still working on porting to py3k and release31-maint. A much better solution would IMHO be to forbid setting the encoding, object and reason attributes to objects of the wrong type in the first place. Unfortunately this would require an extension to PyMemberDef for the T_OBJECT and T_OBJECT_EX types. -- ___ Python tracker <http://bugs.python.org/issue7309> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8014] Setting a T_INT attribute raises internal error
New submission from Walter Dörwald :
In the current py3k branch setting an attribute of an object with PyMemberDefs
raises an internal error:
$ ./python.exe
Python 3.2a0 (py3k:78419M, Feb 24 2010, 17:56:06)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> x = UnicodeEncodeError('ascii', 'gurk', 0, 4, 'broken')
[37539 refs]
>>> x.start = None
Traceback (most recent call last):
File "", line 1, in
SystemError: Objects/longobject.c:439: bad argument to internal function
In Python 2.6.4 (and in the current trunk version) this raises a proper
TypeError:
$ python
Python 2.6.4 (r264:75706, Oct 27 2009, 15:18:04)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> x = UnicodeEncodeError('ascii', u'gurk', 0, 4, 'broken')
>>> x.start = None
Traceback (most recent call last):
File "", line 1, in
TypeError: an integer is required
--
messages: 100051
nosy: doerwalter
severity: normal
status: open
title: Setting a T_INT attribute raises internal error
type: behavior
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue8014>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8092] utf8, backslashreplace and surrogates
Walter Dörwald added the comment: After the patch the comment: /* Implementation limitations: only support error handler that return bytes, and only support up to four replacement bytes. */ no longer applies. Also I would like to see a version of this patch where the length limitation for the replacement returned from the error handler is removed (ideally for both the str and bytes case). -- nosy: +doerwalter ___ Python tracker <http://bugs.python.org/issue8092> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8377] Errata on page:http://docs.python.org/library/stdtypes.html
Walter Dörwald added the comment: This is a common thinko. ;) If i is negative then len(s) - i would be greater that len(s). However len(s) + i is correct. Example: foo[-1] is foo[len(foo) + (-1)] is foo[len(foo)-1] -- nosy: +doerwalter resolution: -> invalid status: open -> closed ___ Python tracker <http://bugs.python.org/issue8377> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7651] Python3: guess text file charset using the BOM
Walter Dörwald added the comment: Yes, that's the posting I was referring to. I wonder why the link is gone. -- ___ Python tracker <http://bugs.python.org/issue7651> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2017] Calendar.yeardatescalendar etc. do not take 'month' argument
Walter Dörwald added the comment: Fixed in r60618 (trunk) and r60619 (release25-maint) -- nosy: +doerwalter resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2017> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2018] TextCalendar.formatmonth is not influenced by setfirstweekday
Walter Dörwald added the comment: setfirstweekday() isn't supposed to have any influence on calendar objects created explicitely. The function setfirstweekday() is only for the module level interface. The documentation is wrong here. However you *can* change the first weekday with the setfirstweekday() *method*. -- assignee: -> doerwalter nosy: +doerwalter resolution: -> accepted __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2018> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2018] TextCalendar.formatmonth is not influenced by setfirstweekday
Walter Dörwald added the comment: You're supposed to use firstweekday as a property instead of using the getter method getfirstweekday(). Anyway this is fixed now in r60651 (trunk) and r60652 (release25-maint) -- resolution: accepted -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2018> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2018] TextCalendar.formatmonth is not influenced by setfirstweekday
Walter Dörwald added the comment: The doccumentation is here:http://docs.python.org/dev/library/calendar.html#calendar.TextCalendar.formatmonth (or in Doc/library/calendar.rst in the source). Anyway the first of those documentation bugs is fixed now in r60649 (trunk) and r60650 (release25-maint). __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2018> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1399] XML codec
Walter Dörwald <[EMAIL PROTECTED]> added the comment: There was resistance in python-dev against this patch (see the thread at http://mail.python.org/pipermail/python-dev/2007-November/075138.html), so this issue should probably closed as rejected. However there was consensus, that a detect_xml_encoding() function might be usefull. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1399> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1328] Force BOM option in UTF output.
Walter Dörwald <[EMAIL PROTECTED]> added the comment: I don't see exactly what James is proposing. > For my needs, I would like the decoding parts of the utf_8 module > to treat an initial BOM as an optional signature and skip it if > there is one (just like the utf_8_sig decoder). In fact I have > a working patch that replaces the utf_8_sig decode, > IncrementalDecoder and StreamReader components by direct > transplants from utf_8_sig (as recently repaired -- there was a > SteamReader error). I've you want a decoder that behave like the utf-8-sig decoder, use the utf-8-sig decoder. I don't see how changing the utf-8 decoder helps here. > I can imagine there might be utf_8 client code out there which > expects to see a leading U+feff as (perhaps) a clue that the > output should be returned with a BOM-signature (say) to > accomodate the guessed input requirements of the remote > correspondant. In this case use UTF-8: The leading BOM will be passed to the application. > I can just live with code like > if input[0] == u"\ufeff": >input=input[1:} > spread around, and of course slightly different for incremental > and stream inputs. Can you post an example that requires this code? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1328> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1477] UnicodeDecodeError that cannot be caught in narrow unicode builds
Walter Dörwald <[EMAIL PROTECTED]> added the comment:
For a wide build, the code
if (x <= 0x)
*p++ = (Py_UNICODE) x;
else {
*p++ = (Py_UNIC0DE) x;
looks strange.
Furthermore with the patch applied Python no longer complains about
illegal code points:
>>> ur'\U'
u'\u1c04\udd11'
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1477>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1477] UnicodeDecodeError that cannot be caught in narrow unicode builds
Walter Dörwald <[EMAIL PROTECTED]> added the comment: The patch looks goog to me now. Go ahead and check it in. -- assignee: doerwalter -> amaury.forgeotdarc __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1477> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1328] Force BOM option in UTF output.
Walter Dörwald <[EMAIL PROTECTED]> added the comment:
If you want to use UTF-8-sig for decoding and UTF-8 for encoding and
have this available as one codec you can define your owen codec for this:
import codecs
def search_function(name):
if name == "myutf8":
utf8 = codecs.lookup("utf-8")
utf8_sig = codecs.lookup("utf-8-sig")
return codecs.CodecInfo(
name='myutf8',
encode=utf8.encode,
decode=utf8_sig.decode,
incrementalencoder=utf8.IncrementalEncoder,
incrementaldecoder=utf8_sig.IncrementalDecoder,
streamreader=utf8_sig.StreamReader,
streamwriter=utf8.StreamWriter,
)
codecs.register(search_function)
Closing the issue as "wont fix"
--
resolution: -> wont fix
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1328>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1328] Force BOM option in UTF output.
Walter Dörwald <[EMAIL PROTECTED]> added the comment:
Oops, that code was supposed to read:
import codecs
def search_function(name):
if name == "myutf8":
utf8 = codecs.lookup("utf-8")
utf8_sig = codecs.lookup("utf-8-sig")
return codecs.CodecInfo(
name='myutf8',
encode=utf8.encode,
decode=utf8_sig.decode,
incrementalencoder=utf8.incrementalencoder,
incrementaldecoder=utf8_sig.incrementaldecoder,
streamreader=utf8_sig.streamreader,
streamwriter=utf8.streamwriter,
)
codecs.register(search_function)
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1328>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4178] codecs: Documentation Inconsistency
Walter Dörwald <[EMAIL PROTECTED]> added the comment: I agree that the documentation should be fixed to read "encode/decode" instead of "encoder/decoder". ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4178> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4178] codecs: Documentation Inconsistency
Walter Dörwald <[EMAIL PROTECTED]> added the comment: Fixed in r67005 (trunk) and r67006 (pk3k). -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4178> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5135] Expose simplegeneric function in functools module
Walter Dörwald added the comment: The patch looks fine to me. Tests pass. I have no opinion about the name. Both "simplegeneric" and "generic" are OK to me. I wonder if being able to use register() directly instead of as a decorator should be dropped. Also IMHO the Python 2.3 backwards compatibility (__name__ isn't setable) can be dropped. -- nosy: +doerwalter ___ Python tracker <http://bugs.python.org/issue5135> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1076233] distutils.core.setup() with unicode arguments broken
Walter Dörwald added the comment: It does indeed work with Python 2.6 (however not with 2.5). Closing. -- resolution: -> out of date status: open -> closed ___ Python tracker <http://bugs.python.org/issue1076233> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5094] datetime lacks concrete tzinfo impl. for UTC
Walter Dörwald added the comment: The patch doesn't include any changes to the documentation. -- nosy: +doerwalter ___ Python tracker <http://bugs.python.org/issue5094> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38482] BUG in codecs.BufferedIncrementalDecoder
Walter Dörwald added the comment:
The documentation might be unclear here. But the argument iterator of
iterdecode(iterator, encoding, errors='strict', **kwargs)
*is* supposed to be an iterable over bytes objects.
In fact iterencode() transforms an iterator over strings into an iterator over
bytes and iterdecode() transforms an iterator over bytes into an iterator over
strings.
Since iterating over strings iterates over the characters, it's possible to
pass a string to iterencode(). However it's not possible to pass a bytes object
to iterdecode() since iterating over a bytes object yields integers:
>>> import codecs
>>> list(codecs.iterencode(['spam'], 'utf-8'))
[b'spam']
>>> list(codecs.iterencode('spam', 'utf-8'))
[b's', b'p', b'a', b'm']
>>> list(codecs.iterdecode([b'spam'], 'utf-8'))
['spam']
>>> list(codecs.iterdecode(b'spam', 'utf-8'))
Traceback (most recent call last):
File "", line 1, in
File
"/usr/local/Cellar/python/3.7.4_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/codecs.py",
line 1048, in iterdecode
output = decoder.decode(input)
File
"/usr/local/Cellar/python/3.7.4_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/codecs.py",
line 321, in decode
data = self.buffer + input
TypeError: can't concat int to bytes
--
nosy: +doerwalter
___
Python tracker
<https://bugs.python.org/issue38482>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38482] BUG in codecs.BufferedIncrementalDecoder
Walter Dörwald added the comment: codecs.iterencode()/iterdecode() are just shallow 10-line wrappers around incremental codecs (which are used as the basis of io streams). Note that the doc string for iterencode() contains: Encodes the input strings from the iterator using an IncrementalEncoder. i.e. "strings" (plural) should give a hint that iterator is an iterator over strings. But maybe this could be made clearer. And https://docs.python.org/3/library/codecs.html#codecs.iterencode and https://docs.python.org/3/library/codecs.html#codecs.iterdecode could indead be clearer about what iterator should be. An example might also help. -- ___ Python tracker <https://bugs.python.org/issue38482> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36819] Crash during encoding using UTF-16/32 and custom error handler
Walter Dörwald added the comment:
The original specification (PEP 293) required that an error handler called for
encoding *must* return a replacement string (not bytes). This returned string
must then be encoded again. Only if this fails an exception must be raised.
Returning bytes from the encoding error handler is an extension specified by
PEP 383:
> The error handler interface is extended to allow the encode error handler to
> return byte strings immediately, in addition to returning Unicode strings
> which then get encoded again (also see the discussion below).
So for 3. in Serhiy's problem list
> 3. Incorrect exception can be raised if the error handler returns invalid
> string/bytes: a non-ASCII string or a bytes object consisting of not a whole
> number of units.
I get:
🐚 ~/ ❯ python
Python 3.9.7 (default, Sep 3 2021, 12:37:55)
[Clang 12.0.5 (clang-1205.0.22.9)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def bad(exc):
... return ('\udbc0', exc.start)
...
>>> import codecs
>>> codecs.register_error('bad', bad)
>>> '\udbc0'.encode('utf-16', 'bad')
Traceback (most recent call last):
File "", line 1, in
UnicodeEncodeError
I would have expected an exception message that basically looks like the one
I'd get, if I had used the strict error handler.
But otherwise returning a replacement that is unencodable is allowed and should
raise an exception (which happens here, but with a missing exception message).
(Returning something unencodable might make sense when the error handler is
able to create replacement characters for some unencodable input, but not for
other, but of course the error handler can always raise an exception directly).
Returning invalid bytes is not an issue, they simply get written to the output.
That's exactly the use case of PEP 383: The bytes couldn't be decoded in the
specified encoding, so they are "invalid", but the surrogateescape error
handler encodes them back to the same "invalid" bytes. So the error handler is
allowed to output bytes that can't be decoded again with the same encoding.
Returning a restart position outside the valid range of the length of the
original string should raise an IndexError according to PEP 293:
> If the callback does not raise an exception (either the one passed in, or a
> different one), it must return a tuple: `(replacement, newpos)`
> `replacement` is a unicode object that the encoder will encode and emit
> instead of the unencodable `object[start:end]` part, `newpos` specifies
> a new position within object, where (after encoding the replacement) the
> encoder will continue encoding.
> Negative values for `newpos` are treated as being relative to end of object.
> If `newpos` is out of bounds the encoder will raise an `IndexError`.
Of course we could retroactively reinterpret "out of bounds" as outside of
`range(exc.start + 1, len(object))`, instead of outside `range(0,
len(object))`. An error handler that never advances is broken anyway. But we
can't detect "never".
However it would probably be OK to reject pathological error handlers (i.e.
those that don't advance (i.e. return at least `exc.start + 1` as the restart
position)). But I'm not sure how that's different from an error handler that
skips ahead much farther (i.e. returns something like
`(exc.start+len(object))//2` or `max(exc.start+1, len(object)-10)`): The
returned restart position leads to a certain expectation of how many bytes the
encoder might have to output until everything is encoded and must adjust
accordingly.
--
___
Python tracker
<https://bugs.python.org/issue36819>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39939] Add str methods to remove prefixes or suffixes
Walter Dörwald added the comment: IMHO the names don't fit Pythons current naming scheme, so what about naming them "lchop" and "rchop"? -- nosy: +doerwalter ___ Python tracker <https://bugs.python.org/issue39939> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38352] In typing docs, note explicit import needed for IO and Pattern/Match
Walter Dörwald added the comment: Shadowing the real modules `re` and `io` by from typing import * would indeed be bad, but that argument IMHO doesn't hold for the types `IO`, `TextIO` and `BinaryIO`, yet they are not listed in `typing.__all__`. Is there a reason for that? And if not, could `IO`, `TextIO` and `BinaryIO` be added to `typing.__all__`? -- nosy: +doerwalter ___ Python tracker <https://bugs.python.org/issue38352> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42930] xml.parsers.expat results differ buffer_text and / or buffer_size
Walter Dörwald added the comment: Just a guess, but the buffer size might be so small that the text that you expect gets passed via **two** calls to _char_data(). You should refactor your code the simply collect all the text in _char_data() and act on it in the _end_element() handler. So this probably isn't a bug in xml.parsers.expat. -- nosy: +doerwalter ___ Python tracker <https://bugs.python.org/issue42930> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35078] Allow customization of CSS class name of a month in calendar module
Walter Dörwald added the comment: New changeset 85339f5c220a5e79c47c3a33c93f1dca5c59c52e by Srinivas Reddy Thatiparthy (శ్రీనివాస్ రెడ్డి తాటిపర్తి) in branch 'master': bpo-35078: Allow customization of CSS class name of a month in calendar module (gh-10137) https://github.com/python/cpython/commit/85339f5c220a5e79c47c3a33c93f1dca5c59c52e -- ___ Python tracker <https://bugs.python.org/issue35078> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35078] Allow customization of CSS class name of a month in calendar module
Change by Walter Dörwald : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35078> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41115] Codecs should raise precise UnicodeDecodeError or UnicodeEncodeError
Walter Dörwald added the comment:
UnicodeEncodeError and UnicodeDecodeError are used to report un(en|de)codedable
ranges in the source object, so it wouldn't make sense to use them for errors
that have nothing to do with problems in the source object. Their constructor
requires 5 arguments (encoding, object, start, end, reason), not just a simple
message: e.g. UnicodeEncodeError("utf-8", "foo", 17, 23, "bad string").
But for reporting e.g. missing BOMs at the start it would be useful to use (0,
0) as the offending range.
--
nosy: +doerwalter
___
Python tracker
<https://bugs.python.org/issue41115>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41465] io.TextIOWrapper.errors not writable
New submission from Walter Dörwald : PEP 293 states the following: """ For stream readers/writers the errors attribute must be changeable to be able to switch between different error handling methods during the lifetime of the stream reader/writer. This is currently the case for codecs.StreamReader and codecs.StreamWriter and all their subclasses. All core codecs and probably most of the third party codecs (e.g. JapaneseCodecs) derive their stream readers/writers from these classes so this already works, but the attribute errors should be documented as a requirement. """ However for io.TextIOWrapper, the errors attribute can not be changed: Python 3.8.5 (default, Jul 21 2020, 10:48:26) [Clang 11.0.3 (clang-1103.0.32.62)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import io >>> s = io.TextIOWrapper(io.BytesIO()) >>> s.errors = 'replace' Traceback (most recent call last): File "", line 1, in AttributeError: attribute 'errors' of '_io.TextIOWrapper' objects is not writable So the errors attribute of io.TextIOWrapper should be made writable. -- components: IO messages: 374751 nosy: doerwalter priority: normal severity: normal status: open title: io.TextIOWrapper.errors not writable type: behavior ___ Python tracker <https://bugs.python.org/issue41465> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41465] io.TextIOWrapper.errors not writable
Walter Dörwald added the comment: I guess that is good enough. "Being changeable" does not necessarily mean mean "being changeable via attribute assignment". Thanks for your research. Closing the issue as "not a bug". -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue41465> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13830] codecs error handler is called with a UnicodeDecodeError with the same args
Walter Dörwald added the comment: See this ancient posting about this problem: http://mail.python.org/pipermail/python-dev/2002-August/027661.html (see point 4.). So I guess somebody did finally complain! ;) The error attributes are documented in PEP 293. The existence of the attributes is documented in Doc/c-api/exceptions.rst, but not their meaning. -- nosy: +doerwalter ___ Python tracker <http://bugs.python.org/issue13830> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34443] enum repr should use __qualname__
Walter Dörwald added the comment:
Can we at least get the __qualname__ in exception messages?
Currently enum.Enum.__new__() and enum.Enum._missing_() use:
raise ValueError("%r is not a valid %s" % (value, cls.__name__))
IMHO this should be:
raise ValueError("%r is not a valid %s" % (value, cls.__qualname__))
in both spots.
Example code:
class Person:
class Type(enum.Enum):
EMPLOYEE = "employee"
CUSTOMER = "customer"
SUPPLIER = "supplier"
class Contact:
class Type(enum.Enum):
EMAIL = "email"
PHONE = "phone"
MOBILE = "mobile"
with this the following code:
Person.Type('foo')
raises the exception:
ValueError: 'foo' is not a valid Type
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "", line 1, in
File
"/usr/local/Cellar/python/3.7.4/Frameworks/Python.framework/Versions/3.7/lib/python3.7/enum.py",
line 310, in __call__
return cls.__new__(cls, value)
File
"/usr/local/Cellar/python/3.7.4/Frameworks/Python.framework/Versions/3.7/lib/python3.7/enum.py",
line 564, in __new__
raise exc
File
"/usr/local/Cellar/python/3.7.4/Frameworks/Python.framework/Versions/3.7/lib/python3.7/enum.py",
line 548, in __new__
result = cls._missing_(value)
File
"/usr/local/Cellar/python/3.7.4/Frameworks/Python.framework/Versions/3.7/lib/python3.7/enum.py",
line 577, in _missing_
raise ValueError("%r is not a valid %s" % (value, cls.__name__))
ValueError: 'foo' is not a valid Type
IMHO the exception message:
ValueError: 'foo' is not a valid Person.Type
would be much more helpful and unambiguous.
And BTW, maybe we should suppress exception chaining here, i.e. use:
raise ValueError("%r is not a valid %s" % (value, cls.__qualname__)) from
None
--
___
Python tracker
<https://bugs.python.org/issue34443>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34443] enum repr should use __qualname__
Change by Walter Dörwald : -- pull_requests: +14603 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/14809 ___ Python tracker <https://bugs.python.org/issue34443> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30733] Typo in Document What's New: Calendar
Changes by Walter Dörwald : -- pull_requests: +2463 ___ Python tracker <http://bugs.python.org/issue30733> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30733] Typo in Document What's New: Calendar
Walter Dörwald added the comment: New changeset f5c58c781aa0bb296885baf62f4f39100f2cd93d by Walter Dörwald in branch 'master': bpo-30733: Fix typos in "What's New" entry (GH-2414) https://github.com/python/cpython/commit/f5c58c781aa0bb296885baf62f4f39100f2cd93d -- nosy: +doerwalter ___ Python tracker <http://bugs.python.org/issue30733> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30733] Typo in Document What's New: Calendar
Walter Dörwald added the comment: Should be fixed now. Thanks for noticing it. -- resolution: -> fixed ___ Python tracker <http://bugs.python.org/issue30733> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30733] Typo in Document What's New: Calendar
Changes by Walter Dörwald : -- stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.org/issue30733> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2661] Mapping tests cannot be passed by user implementations
Change by Walter Dörwald : -- pull_requests: +10390 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue2661> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2661] Mapping tests cannot be passed by user implementations
Walter Dörwald added the comment: OK, I've created the pull request (11157). -- ___ Python tracker <https://bugs.python.org/issue2661> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18059] Add multibyte encoding support to pyexpat
Walter Dörwald added the comment: This looks to me like a limited reimplementation of the codec machinery. Why not use incremental codecs as a preprocessor? Would this be to slow? -- ___ Python tracker <http://bugs.python.org/issue18059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30095] HTMLCalendar allow custom classes
Walter Dörwald added the comment: IMHO this could all be done by overwriting the relevant methods. But this might be overkill. I think a solution might be to move the CSS classes into class attributes of HTMLCalendar. Customizing the CSS classes would then be done by subclassing HTMLCalendar and overwriting the appropriate class attributes. Is this what you had in mind? -- nosy: +doerwalter ___ Python tracker <http://bugs.python.org/issue30095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30095] HTMLCalendar allow custom classes
Walter Dörwald added the comment: OK, go ahead. I'm looking forward to what you come up with. -- ___ Python tracker <http://bugs.python.org/issue30095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30095] HTMLCalendar allow custom classes
Walter Dörwald added the comment: The second link is a 404. For the v1 patch: The variable names are a bit inconsistent: The first uses "classes" all others use "styles". This should be consistent within itself and with the existing code, i.e. "classes" should be used. Also each class attribute should be preceded with a comment, explaining what the CSS class is used for. As these are now made public to be overwritten by subclasses, I wonder wether it would make sense to document these class attributes in Doc/library/calendar.rst -- ___ Python tracker <http://bugs.python.org/issue30095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30095] HTMLCalendar allow custom classes
Walter Dörwald added the comment: See comments on Github -- ___ Python tracker <http://bugs.python.org/issue30095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30095] HTMLCalendar allow custom classes
Walter Dörwald added the comment: See my comments on the pull request: https://github.com/python/cpython/pull/1439 After you address those, IMHO this is ready to be merged. -- ___ Python tracker <http://bugs.python.org/issue30095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30095] HTMLCalendar allow custom classes
Walter Dörwald added the comment: See comments on the pull request. Also it seems that currently the pull request can't be merged because of merge conflicts. -- ___ Python tracker <http://bugs.python.org/issue30095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30095] HTMLCalendar allow custom classes
Walter Dörwald added the comment: New changeset 8b7a4cc40e9b2f34da94efb75b158da762624015 by Walter Dörwald (Oz N Tiram) in branch 'master': bpo-30095: Make CSS classes used by calendar.HTMLCalendar customizable (GH-1439) https://github.com/python/cpython/commit/8b7a4cc40e9b2f34da94efb75b158da762624015 -- ___ Python tracker <http://bugs.python.org/issue30095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30095] HTMLCalendar allow custom classes
Walter Dörwald added the comment: Closing the issue. The patch has been merged. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <http://bugs.python.org/issue30095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33850] Json.dump() bug when using generator
Walter Dörwald added the comment: The problem here is that StreamArray lies about the length of the iterator. This confuses json.encoder._make_iterencode._iterencode_list(), (which is called by json.dump()), because it first does a check for "if not lst" and then assumes in the loop that it will be entered at least once. (Note that json.dumps() doesn't have that problem, because it calls JSONEncoder.encode() with _one_shot=True which leads to a totally different code path). We could declare that bug as "don't do that then", but the problem is easily solvable, because we can check whether the loop was entered. The attached patch should do the trick. An even better approach would IMHO be, that the encoder supports a special flag that enables JSON serialization of generators directly, so it's no longer required to masquerade generators as list -- keywords: +patch nosy: +doerwalter resolution: not a bug -> status: closed -> open Added file: https://bugs.python.org/file47640/json-dump-generators-bug.diff ___ Python tracker <https://bugs.python.org/issue33850> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33967] functools.singledispatch: Misleading exception when calling without arguments
New submission from Walter Dörwald : When I call a function decorated with functools.singledispatch without an argument, I get the following: $ python Python 3.6.5 (default, Jun 17 2018, 12:13:06) [GCC 4.2.1 Compatible Apple LLVM 9.1.0 (clang-902.0.39.2)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import functools >>> @functools.singledispatch ... def f(x): ... pass ... >>> f() Traceback (most recent call last): File "", line 1, in File "/usr/local/Cellar/python/3.6.5_1/Frameworks/Python.framework/Versions/3.6/lib/python3.6/functools.py", line 803, in wrapper return dispatch(args[0].__class__)(*args, **kw) IndexError: tuple index out of range I would have expected a TypeError along the lines of TypeError: f() missing 1 required positional argument: 'x' -- components: Library (Lib) messages: 320485 nosy: doerwalter priority: normal severity: normal status: open title: functools.singledispatch: Misleading exception when calling without arguments type: behavior versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue33967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34443] enum repr should use __qualname__
New submission from Walter Dörwald : The __repr__ output of an enum class should use __qualname__ instead of __name__. The following example shows the problem: import enum class X: class I: pass class Y: class I(enum.Enum): pass print(X.I) print(Y.I) This prints: I would have expected it to print or even for maximum consistency -- components: Library (Lib) messages: 323799 nosy: doerwalter priority: normal severity: normal status: open title: enum repr should use __qualname__ type: enhancement ___ Python tracker <https://bugs.python.org/issue34443> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34443] enum repr should use __qualname__
Change by Walter Dörwald : -- keywords: +easy ___ Python tracker <https://bugs.python.org/issue34443> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34935] Misleading error message in str.decode()
New submission from Walter Dörwald :
The following code issues a misleading exception message:
>>> b'\xed\xa0\xbd\xed\xb3\x9e'.decode("utf-8")
Traceback (most recent call last):
File "", line 1, in
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xed in position 0: invalid
continuation byte
The cause for the exception is *not* an invalid continuation byte, but UTF-8
encoded surrogates. In fact using the 'surrogatepass' error handler doesn't
raise an exception:
>>> b'\xed\xa0\xbd\xed\xb3\x9e'.decode("utf-8", "surrogatepass")
'\ud83d\udcde'
I would have expected an exception message like:
UnicodeDecodeError: 'utf-8' codec can't decode bytes in position 0-2:
surrogates not allowed
(Note that the input bytes are an improperly UTF-8 encoded version of U+1F4DE
(telephone receiver))
--
components: Unicode
messages: 327357
nosy: doerwalter, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: Misleading error message in str.decode()
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue34935>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34935] Misleading error message in str.decode()
Walter Dörwald added the comment: OK, I see, http://www.unicode.org/versions/Unicode5.2.0/ch03.pdf (Table 3-7 on page 93) states that the only valid 3-bytes UTF-8 sequences starting with the byte 0xED have a value for the second byte in the range 0x80 to 0x9F. 0xA0 is just beyond that range (as that would result in an encoded surrogate). Python handles all invalid sequences according to that table with the same error message. I think this issue can be closed. -- ___ Python tracker <https://bugs.python.org/issue34935> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1470548] Bugfix for #1470540 (XMLGenerator cannot output UTF-16)
Walter Dörwald added the comment: An alternative would be to use an incremental encoder instead of a StreamWriter. (Which is what TextIOWrapper does internally). -- nosy: +doerwalter ___ Python tracker <http://bugs.python.org/issue1470548> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15408] os.fork/os.popen behaviour change between 2.7 and 3.2
New submission from Walter Dörwald : The attached script behaves differently on Python 2.7.2 and Python 3.2.3. With Python 2.7 the script runs for ca. 30 seconds and then I get back my prompt. With Python 3.2 the script runs in the background, I get back my prompt immediately and can type shell commands. Commenting out the call to uname() changes the behaviour of the script on Python 3.2 so that it behaves like on Python 2.7. (This happens on both Max OS X 10.7 and Linux.) -- files: gurk.py messages: 165942 nosy: doerwalter priority: normal severity: normal status: open title: os.fork/os.popen behaviour change between 2.7 and 3.2 versions: Python 3.2 Added file: http://bugs.python.org/file26456/gurk.py ___ Python tracker <http://bugs.python.org/issue15408> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15408] os.fork/os.popen behaviour change between 2.7 and 3.2
Walter Dörwald added the comment: So is this simply a documentation issue, or can we close the bug as "won't fix"? -- ___ Python tracker <http://bugs.python.org/issue15408> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15278] UnicodeDecodeError when readline in codecs.py
Walter Dörwald added the comment:
> >>> codecs.utf_8_decode('\u20ac'.encode('utf8')[:2])
> ('', 0)
>
> Oh... codecs.CODEC_decode are incremental decoders? I misunderstood completly
> this.
No, those function are not decoders, they're just helper functions used to
implement the real incremental decoders. That's why they're undocumented.
Whether codecs.utf_8_decode() returns partial results or raises an exception
depends on the final argument::
>>> s = '\u20ac'.encode('utf8')[:2]
>>> codecs.utf_8_decode(s, 'strict')
('', 0)
>>> codecs.utf_8_decode(s, 'strict', False)
('', 0)
>>> codecs.utf_8_decode(s, 'strict', True)
Traceback (most recent call last):
File "", line 1, in
UnicodeDecodeError: 'utf-8' codec can't decode bytes in position 0-1:
unexpected end of data
If you look at encodings/utf_8.py you see that the stateless decoder call
codecs.utf_8_decode() with final==True::
def decode(input, errors='strict'):
return codecs.utf_8_decode(input, errors, True)
so the stateless decoder *will* raise exceptions for partial results. The
incremental decoder simply passed on the final argument given to its encode()
method.
--
nosy: +doerwalter
___
Python tracker
<http://bugs.python.org/issue15278>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21400] Code coverage documentation is out-of-date.
Walter Dörwald added the comment: The cronjob that produces this information has been deactivated, because it currently produces broken output. The code for that job is available from here: https://pypi.python.org/pypi/pycoco It would be great to have up to date coverage info for Python again, but I don't have time to work on that. Perhaps someone can combine this code and Ned Batchelder coverage script to implement a new coverage site (that includes coverage info for C modules). However for now I think this link should be removed. -- nosy: +doerwalter ___ Python tracker <http://bugs.python.org/issue21400> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16577] Suspect test.test_codeccallbacks.test_mutatingdecodehandler
Walter Dörwald added the comment:
True, the second test uses the wrong error handler.
And yes, you're correct, bytes are now immutable. And even if I try to decode a
bytearray, what the callback gets to see is still an immutable bytes object::
import codecs
def mutating(exc):
if isinstance(exc, UnicodeDecodeError):
exc.object[:] = b""
return ("\u4242", 0)
else:
raise TypeError("don't know how to handle %r" % exc)
codecs.register_error('mutating', mutating)
input = bytearray(b'bbb\xff')
input.decode('ascii', 'mutating')
This still raises:
TypeError: 'bytes' object does not support item assignment
So the change should indeed be reverted.
--
nosy: +doerwalter
___
Python tracker
<http://bugs.python.org/issue16577>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16585] surrogateescape broken w/ multibytecodecs' encode
Walter Dörwald added the comment: And returning bytes is documented in PEP 383, as an extension to the PEP 293 machinery: """To convert non-decodable bytes, a new error handler ([2]) "surrogateescape" is introduced, which produces these surrogates. On encoding, the error handler converts the surrogate back to the corresponding byte. This error handler will be used in any API that receives or produces file names, command line arguments, or environment variables. The error handler interface is extended to allow the encode error handler to return byte strings immediately, in addition to returning Unicode strings which then get encoded again (also see the discussion below).""" -- nosy: +doerwalter ___ Python tracker <http://bugs.python.org/issue16585> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16613] ChainMap.new_child could use improvement
Walter Dörwald added the comment:
I'd like to have this feature too. However the code should use
d if d is not None else {}
instead of
d or {}
For example I might want to use a subclass of dict (lowerdict) that converts
all keys to lowercase. When I use an empty lowerdict in new_child(),
new_child() would silently use a normal dict instead:
class lowerdict(dict):
def __getitem__(self, key):
return dict.__getitem__(
self,
key.lower() if isinstance(key, str) else key
)
import collections
cm = collections.ChainMap(lowerdict(), lowerdict())
cm2 = cm.new_child(lowerdict())
print(type(cm2.maps[0]))
This would print .
--
nosy: +doerwalter
___
Python tracker
<http://bugs.python.org/issue16613>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19585] Frame annotation
New submission from Walter Dörwald: This patch adds frame annotations, i.e. it adds an attribute f_annotation to frame objects, a decorator to set this attribute on exceptions and extensions to the traceback machinery that display the annotation in the traceback. -- components: Interpreter Core files: frame-annotation.diff hgrepos: 214 keywords: patch messages: 202862 nosy: doerwalter priority: normal severity: normal status: open title: Frame annotation type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file32614/frame-annotation.diff ___ Python tracker <http://bugs.python.org/issue19585> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19585] Frame annotation
Walter Dörwald added the comment: See http://bugs.python.org/issue18861 and the discussion started here: https://mail.python.org/pipermail/python-dev/2013-November/130155.html. Basically it allows to add context information to a traceback without changing the type of the exception. In the following example: import itertools ', '.join(itertools.chain((str(i) for i in range(100)), [42])) the join method itself adds context information to the TypeError: Traceback (most recent call last): File "hurz.py", line 2, in ', '.join(itertools.chain((str(i) for i in range(100)), [42])) TypeError: sequence item 100: expected str instance, int found i.e. the "sequence item 100" is context information. However when the exception occurs higher up in the call chain, no such context information is added: import itertools def foo(x): return str(x+1) ', '.join(foo(x) for x in itertools.chain(range(100), [None])) This gives: Traceback (most recent call last): File "hurz.py", line 6, in ', '.join(foo(x) for x in itertools.chain(range(100), [None])) File "hurz.py", line 6, in ', '.join(foo(x) for x in itertools.chain(range(100), [None])) File "hurz.py", line 4, in foo return str(x+1) TypeError: unsupported operand type(s) for +: 'NoneType' and 'int' With frame annotations the traceback might look like this: Traceback (most recent call last): File "hurz.py", line 6, in ', '.join(foo(x) for x in itertools.chain(range(100), [None])) File "hurz.py", line 6, in : sequence item 100 ', '.join(foo(x) for x in itertools.chain(range(100), [None])) File "hurz.py", line 4, in foo return str(x+1) TypeError: unsupported operand type(s) for +: 'NoneType' and 'int' -- ___ Python tracker <http://bugs.python.org/issue19585> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19585] Frame annotation
Walter Dörwald added the comment: Here is a new version of the patch. The annotation is done on the code object instead of on the frame object. This avoids two problems: There is no runtime overhead, as the decorator returns the original function and no additional frames show up in the traceback. Since the variables are only known at runtime, the annotation is now a function that does the formatting of the annotation message and gets passed the frame object. With this there is no runtime overhead when no exception is raised and even if an exception is raise, but the traceback is never formatted. -- Added file: http://bugs.python.org/file32834/code-annotation.diff ___ Python tracker <http://bugs.python.org/issue19585> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19585] Frame annotation
Walter Dörwald added the comment: Do you have an example where code objects are shared? We could attach the annotation formatter to the function object, but unfortunately the function object is now accessible in the traceback. Note the co_annotation is not the annotation string, rather it is a function that does the formatting of the annotation. -- ___ Python tracker <http://bugs.python.org/issue19585> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19834] Unpickling exceptions pickled by Python 2
New submission from Walter Dörwald: Exception objects that have been pickled with Python 2 can not be unpickled with Python 3, even when fix_imports=True is specified: $ python2.7 Python 2.7.2 (default, Aug 30 2011, 11:04:13) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle >>> pickle.dumps(StopIteration()) 'cexceptions\nStopIteration\np0\n(tRp1\n.' >>> $ python3.3 Python 3.3.2 (default, Nov 14 2013, 12:22:14) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import pickle >>> pickle.loads(b'cexceptions\nStopIteration\np0\n(tRp1\n.', fix_imports=True) Traceback (most recent call last): File "", line 1, in ImportError: No module named 'exceptions' >>> Adding an entry "exceptions": "builtins" to _compat_pickle.IMPORT_MAPPING seems to fix the problem. -- messages: 204733 nosy: doerwalter priority: normal severity: normal status: open title: Unpickling exceptions pickled by Python 2 ___ Python tracker <http://bugs.python.org/issue19834> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19834] Unpickling exceptions pickled by Python 2
Walter Dörwald added the comment: OK, here is a patch. Instead of mapping the exceptions module to builtins, it does the mapping for each exception class separately. I've excluded StandardError, because I think there's no appropriate equivalent in Python 3. -- keywords: +patch Added file: http://bugs.python.org/file32911/python-2-exception-pickling.diff ___ Python tracker <http://bugs.python.org/issue19834> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19834] Unpickling exceptions pickled by Python 2
Walter Dörwald added the comment: Here's an updated version of the patch, addressing most of Alexandre's comments. -- Added file: http://bugs.python.org/file32918/python-2-exception-pickling-2.diff ___ Python tracker <http://bugs.python.org/issue19834> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19834] Unpickling exceptions pickled by Python 2
Changes by Walter Dörwald : -- resolution: -> fixed ___ Python tracker <http://bugs.python.org/issue19834> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12808] Coverage of codecs.py
Walter Dörwald added the comment: The requirement that getstate() returns a (buffer, int) tuple has to do with the fact that for text streams seek() and tell() somehow have to take the state of the codec into account. See _pyio.TextIOWrapper.(seek|tell|_pack_cookie|_unpack_cookie). However I can't remember the exact history of the specification. -- nosy: +doerwalter ___ Python tracker <http://bugs.python.org/issue12808> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2661] Mapping tests cannot be passed by user implementations
Walter Dörwald added the comment: Here is a patch that implements suggestion 2 and 3. -- keywords: +patch Added file: http://bugs.python.org/file35800/mapping-tests.diff ___ Python tracker <http://bugs.python.org/issue2661> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19806] smtpd crashes when a multi-byte UTF-8 sequence is split between consecutive data packets
Walter Dörwald added the comment: I don't know anything about SMTP, but would it make sense to use an incremental decoder for decoding UTF-8? -- nosy: +doerwalter ___ Python tracker <http://bugs.python.org/issue19806> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21968] 'abort' object is not callable
Walter Dörwald added the comment: The problem seems to be in that line: except imaplib.IMAP4_SSL.abort, imaplib.IMAP4.abort: This does *not* catch both exception classes, but catches only IMAP4_SSL.abort and stores the exception object in imaplib.IMAP4.abort. What you want is: except (imaplib.IMAP4_SSL.abort, imaplib.IMAP4.abort): -- nosy: +doerwalter ___ Python tracker <http://bugs.python.org/issue21968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19100] Use backslashreplace in pprint
Walter Dörwald added the comment:
This is not the fault of pprint. IMHO it doesn't make sense to fix anything
here, at least not for pprint specifically. print() has the same "problem":
$ LANG= ./python -c "print('\u20ac')"
Traceback (most recent call last):
File "", line 1, in
UnicodeEncodeError: 'ascii' codec can't encode character '\u20ac' in
position 0: ordinal not in range(128)
--
nosy: +doerwalter
___
Python tracker
<http://bugs.python.org/issue19100>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19100] Use backslashreplace in pprint
Walter Dörwald added the comment: sys.displayhook doesn't fail, because it uses the backslashreplace error handler, and for sys.displayhook that's OK, because it's only used for screen output and there some output is better than no output. However print and pprint.pprint might be used for output that is consumed by other programs (via pipes etc.) and IMHO in this case "Errors should never pass silently." -- ___ Python tracker <http://bugs.python.org/issue19100> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20132] Many incremental codecs don’t handle fragmented data
Walter Dörwald added the comment: The best solution IMHO would be to implement real incremental codecs for all of those. Maybe iterencode() with an empty iterator should never call encode()? (But IMHO it would be better to document that iterencode()/iterdecode() should only be used with "real" codecs.) Note that the comment before PyUnicode_DecodeUTF7Stateful() in unicodeobject.c reads: /* The decoder. The only state we preserve is our read position, * i.e. how many characters we have consumed. So if we end in the * middle of a shift sequence we have to back off the read position * and the output to the beginning of the sequence, otherwise we lose * all the shift state (seen bits, number of bits seen, high * surrogate). */ Changing that would have to introduce a state object that the codec updates and from which it can be restarted. Also the encoder does not buffer anything. To implement the suggested behaviour, the encoder might have to buffer unlimited data. -- ___ Python tracker <http://bugs.python.org/issue20132> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13881] Stream encoder for zlib_codec doesn't use the incremental encoder
Walter Dörwald added the comment: The stream part of the codecs isn't used that much in Python 3 any more, so I'm not sure if this is worth fixing. -- ___ Python tracker <http://bugs.python.org/issue13881> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
