[issue32268] quopri.decode(): string argument expected, got 'bytes'
Alexey Luchko <soulne...@gmail.com> added the comment: 1. On quopri. It is counter-intuitive despite the clear statement in the doc-string. Quoted-printable is used mostly for text encoding. (It would be quite awkward and inefficient to use it for binary data.) My case: I have a text and I mean to get a text. Why on earth StringIO is not suitable for this goal... It is just crazy! 2. On duck typing and StringIO. It should make life easy, not crazy. But with great power... You know. Taking a wider look than just quopri, the case shows a problem – writing text to StringIO produces a type error stating *string argument expected*. That is crazy and as counter-duck-typing as type checking. And even more ... crazy in case of 7bit ascii! There could be a solution on StringIO side, like an encoding it should expect on input if it gets binary data. At least 7bit ascii would be totally ok for default it this case. Then it either would have worked or would have produced a clear text encoding related error that would be *meaningful* and *instructive*. 3. On protocol. A protocol: write_bytes() and write_string() methods that would have been raising type error in case of text_file.write_bytes() or binary_file.write_string(). Then one having bytes-*like* object (like quopri.decode) would call write_bytes() and StringIO would raise smth like 'StringIO used for binary output, consider BytesIO' or 'Text file requires strings, not bytes' that would be meaningful as well. Other one having string-*like* object would call knowingly write_string() with a corresponding error from BytesIO or binary file. *There is nothing of checking in the protocol, but clear intention statement.* Disclaimer: It is just an example and an opinion. There is no reason for holy war. I don't pretend it would be any better... -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32268> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32268] quopri.decode(): string argument expected, got 'bytes'
Alexey Luchko <soulne...@gmail.com> added the comment: I didn't mean type checking. The point is that since string and bytes are different types, then binary and text files are actually much more different than before python 3. Therefore they better be of different protocols. Then inside quopri with StringIO in place of BytesIO the error would be much more clear and this issue would not have appeared. This would be helpful in lack of one's intuition, like with newcomers. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32268> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32268] quopri.decode(): string argument expected, got 'bytes'
Alexey Luchko <soulne...@gmail.com> added the comment: Yes. With io.BytesIO() output, it works. However, this kind of error messages is quite very confusing. It better be possible to distinguish binary and text streams, so one (including quopri module) could tell it won't work in advance %) Thanks for referring to binascii module as well! -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32268> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32268] quopri.decode(): string argument expected, got 'bytes'
New submission from Alexey Luchko <soulne...@gmail.com>:
$ python3 -c 'import io, quopri; quopri.decode(io.StringIO("some initial text
data"), io.StringIO())'
Traceback (most recent call last):
File "", line 1, in
File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/quopri.py",
line 125, in decode
output.write(odata)
TypeError: string argument expected, got 'bytes'
--
components: Library (Lib)
messages: 307957
nosy: luch
priority: normal
severity: normal
status: open
title: quopri.decode(): string argument expected, got 'bytes'
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32268>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14437] _io build fails on cygwin
Alexey Luchko l...@ank-sia.com added the comment: Final 2.7.3 didn't get the fix. Checked http://python.org/ftp/python/2.7.3/Python-2.7.3.tar.xz -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14437 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14438] _cursesmodule build fails on cygwin
Alexey Luchko l...@ank-sia.com added the comment: It's cygwin's issue. Cygwin's python 2.6 has a patch for it. Just in case: --- origsrc/Python-2.6.5/Include/py_curses.h2009-09-06 16:23:05.0 -0500 +++ src/Python-2.6.5/Include/py_curses.h2010-04-14 15:21:23.008971400 -0500 @@ -17,6 +17,13 @@ #define NCURSES_OPAQUE 0 #endif /* __APPLE__ */ +#ifdef __CYGWIN__ +/* the following define is necessary for Cygwin; without it, the + Cygwin-supplied ncurses.h sets NCURSES_OPAQUE to 1, and then Python + can't get at the WINDOW flags field. */ +#define NCURSES_INTERNALS +#endif /* __CYGWIN__ */ + #ifdef __FreeBSD__ /* ** On FreeBSD, [n]curses.h and stdlib.h/wchar.h use different guards -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14438 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14437] _io build fails on cygwin
New submission from Alexey Luchko l...@ank-sia.com: $ make ... gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.7.11-i686-2.7/Python-2.7.3rc2/Modules/_io/bufferedio.o build/temp.cygwin-1.7.11-i686-2.7/Python-2.7.3rc2/Modules/_io/bytesio.o build/temp.cygwin-1.7.11-i686-2.7/Python-2.7.3rc2/Modules/_io/fileio.o build/temp.cygwin-1.7.11-i686-2.7/Python-2.7.3rc2/Modules/_io/iobase.o build/temp.cygwin-1.7.11-i686-2.7/Python-2.7.3rc2/Modules/_io/_iomodule.o build/temp.cygwin-1.7.11-i686-2.7/Python-2.7.3rc2/Modules/_io/stringio.o build/temp.cygwin-1.7.11-i686-2.7/Python-2.7.3rc2/Modules/_io/textio.o -L/usr/local/lib -L. -lpython2.7 -o build/lib.cygwin-1.7.11-i686-2.7/_io.dll build/temp.cygwin-1.7.11-i686-2.7/Python-2.7.3rc2/Modules/_io/bufferedio.o: In function `_set_BlockingIOError': /Python-2.7.3rc2/Modules/_io/bufferedio.c:579: undefined reference to `__imp__PyExc_BlockingIOError' /Python-2.7.3rc2/Modules/_io/bufferedio.c:579: undefined reference to `__imp__PyExc_BlockingIOError' build/temp.cygwin-1.7.11-i686-2.7/Python-2.7.3rc2/Modules/_io/bufferedio.o: In function `_buffered_check_blocking_error': /Python-2.7.3rc2/Modules/_io/bufferedio.c:595: undefined reference to `__imp__PyExc_BlockingIOError' collect2: ld returned 1 exit status CYGWIN_NT-6.1-WOW64 ... 1.7.11(0.260/5/3) 2012-02-24 14:05 i686 Cygwin gcc version 4.5.3 (GCC) -- components: Extension Modules messages: 157024 nosy: luch priority: normal severity: normal status: open title: _io build fails on cygwin type: compile error versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14437 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14437] _io build fails on cygwin
Alexey Luchko l...@ank-sia.com added the comment: The error got building Python 2.7.2 2.7.3rc2 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14437 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14438] _cursesmodule build fails on cygwin
New submission from Alexey Luchko l...@ank-sia.com: $ CFLAGS=-I/usr/include/ncursesw/ CPPFLAGS=-I/usr/include/ncursesw/ ./configure $ make ... building '_curses' extension gcc -fno-strict-aliasing -I/usr/include/ncursesw/ -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/usr/include/ncursesw/ -I/Python-2.7.3rc2/Include -I/Python-2.7.3rc2 -c /Python-2.7.3rc2/Modules/_cursesmodule.c -o build/temp.cygwin-1.7.11-i686-2.7/Python-2.7.3rc2/Modules/_cursesmodule.o /Python-2.7.3rc2/Modules/_cursesmodule.c: In function ‘PyCursesWindow_EchoChar’: /Python-2.7.3rc2/Modules/_cursesmodule.c:810:18: error: dereferencing pointer to incomplete type /Python-2.7.3rc2/Modules/_cursesmodule.c: In function ‘PyCursesWindow_NoOutRefresh’: /Python-2.7.3rc2/Modules/_cursesmodule.c:1238:22: error: dereferencing pointer to incomplete type /Python-2.7.3rc2/Modules/_cursesmodule.c: In function ‘PyCursesWindow_Refresh’: /Python-2.7.3rc2/Modules/_cursesmodule.c:1381:22: error: dereferencing pointer to incomplete type /Python-2.7.3rc2/Modules/_cursesmodule.c: In function ‘PyCursesWindow_SubWin’: /Python-2.7.3rc2/Modules/_cursesmodule.c:1448:18: error: dereferencing pointer to incomplete type /Python-2.7.3rc2/Modules/_cursesmodule.c: In function ‘PyCursesWindow_Refresh’: /Python-2.7.3rc2/Modules/_cursesmodule.c:1412:1: warning: control reaches end of non-void function /Python-2.7.3rc2/Modules/_cursesmodule.c: In function ‘PyCursesWindow_NoOutRefresh’: /Python-2.7.3rc2/Modules/_cursesmodule.c:1270:1: warning: control reaches end of non-void function /Python-2.7.3rc2/Modules/_cursesmodule.c: In function ‘PyCursesWindow_EchoChar’: /Python-2.7.3rc2/Modules/_cursesmodule.c:817:1: warning: control reaches end of non-void function CYGWIN_NT-6.1-WOW64 ... 1.7.11(0.260/5/3) 2012-02-24 14:05 i686 Cygwin gcc version 4.5.3 (GCC) Python 2.7.2 2.7.3rc2 -- components: Extension Modules messages: 157026 nosy: luch priority: normal severity: normal status: open title: _cursesmodule build fails on cygwin type: compile error versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14438 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14437] _io build fails on cygwin
Alexey Luchko l...@ank-sia.com added the comment: Checked solution by David Robinow http://mail.python.org/pipermail/python-list/2012-March/1290038.html It works. Diff follows: --- Modules/_io/_iomodule.h.orig2012-03-16 03:26:36.0 +0200 +++ Modules/_io/_iomodule.h 2012-03-29 13:54:07.094187600 +0300 @@ -72,7 +72,7 @@ PyObject *filename; /* Not used, but part of the IOError object */ Py_ssize_t written; } PyBlockingIOErrorObject; -PyAPI_DATA(PyObject *) PyExc_BlockingIOError; +PyObject * PyExc_BlockingIOError; /* * Offset type for positioning. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14437 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11098] syntax error at end of line in interactive python -u
Alexey Luchko l...@ank-sia.com added the comment: I reported the issue just because I didn't find it is already known. I don't think it is worth backporting. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11098 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11098] syntax error at end of line in interactive python -u
New submission from Alexey Luchko l...@ank-sia.com: Interactive python -u produces syntax error in win2k: python -u Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. 1+1 File stdin, line 1 1+1 ^ SyntaxError: invalid syntax import sys File stdin, line 1 import sys ^ SyntaxError: invalid syntax Tried Python 2.5.4, 2.7.1 and 3.1.2 on the same win2k machine. The problem does not exist under mac os x 10.5 and freebsd 8.1. -- components: Windows messages: 127732 nosy: luch priority: normal severity: normal status: open title: syntax error at end of line in interactive python -u versions: Python 2.5, Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11098 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9626] OderedDict.viewitems() does not preserve item order
New submission from Alexey Luchko l...@ank-sia.com:
OrderedDict.viewitems() is expected to preserve item order like items() do
from collections import OrderedDict
d = OrderedDict([(1, 2), (a, b)])
d.items()
[(1, 2), ('a', 'b')]
But it does not:
list(d.viewitems())
[('a', 'b'), (1, 2)]
--
components: Library (Lib)
messages: 114117
nosy: luch
priority: normal
severity: normal
status: open
title: OderedDict.viewitems() does not preserve item order
type: behavior
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9626
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
