[issue1029] py3k: io.StringIO.getvalue() returns \r\n
New submission from Amaury Forgeot d'Arc:
io.StrinIO.getvalue() correctly decodes bytes from the underlying
buffer, but does not translate \r\n to \n.
Python 3.0x (py3k, Aug 26 2007, 14:39:16) [MSC v.1400 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import io
>>> a = io.StringIO()
>>> a.write('\n')
2
>>> a.getvalue()
'\r\n'
The attached patch corrects this and adds a test.
--
components: Library (Lib), Windows
files: stringio.diff
messages: 55314
nosy: amaury.forgeotdarc
severity: normal
status: open
title: py3k: io.StringIO.getvalue() returns \r\n
type: behavior
versions: Python 3.0
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1029>
__
stringio.diff
Description: Binary data
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1030] py3k: Adapt _winreg.c to the new buffer API
Changes by Amaury Forgeot d'Arc: -- components: Windows files: winreg.diff severity: normal status: open title: py3k: Adapt _winreg.c to the new buffer API type: compile error versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1030> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1031] py3k: compilation with VC2005
New submission from Amaury Forgeot d'Arc: This patch is necessary to compile inside the PCBuild8 directory -- components: Windows files: vc2005.diff messages: 55315 nosy: amaury.forgeotdarc severity: normal status: open title: py3k: compilation with VC2005 type: compile error versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1031> __ vc2005.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1031] py3k: compilation with VC2005
Amaury Forgeot d'Arc added the comment: Sorry, it's probably because I somehow converted the line endings. Attached a new version of the patch. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1031> __ vc2005-2.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1029] py3k: io.StringIO.getvalue() returns \r\n
Amaury Forgeot d'Arc added the comment:
> As far as I know, StringIO should not do any string transformations.
(Not sure if you agree with the patch or not)
That's why the current behaviour is not correct: When I write('\n'),
getvalue() currently returns '\r\n'.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1029>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1031] py3k: compilation with VC2005
Amaury Forgeot d'Arc added the comment: Yes, everything compiles now. I discovered that the additional libraries not necessary if I update my VC 2005 Express installation as in this post: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=133236&SiteID=1 > The problem is that the default installation of VS 8 express > doesn't support the Platform SDK, so, after installing the > platform SDK, you need to make a few modifications... > > 1. Update the corewin_express.vsprops file (NOT the > corewin.vsprops file). (In the c:/Program Files/Microsoft Visual Studio 8/VC/VCProjectDefaults/ directory) > You need to change this... > > AdditionalDependencies="kernel32.lib" > > to this > > AdditionalDependencies="kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib" > And everything compiles fine without further modification. Thanks! __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1031> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1029] py3k: io.StringIO.getvalue() returns \r\n
Amaury Forgeot d'Arc added the comment: Here is a new version of the class, which removes the 'newline' argument from the constructor. I also removed the 'encoding' argument, since this is really an implementation detail of the underlying buffer. Index: Lib/io.py === --- Lib/io.py (revision 57564) +++ Lib/io.py (working copy) @@ -1390,10 +1390,10 @@ # XXX This is really slow, but fully functional -def __init__(self, initial_value="", encoding="utf-8", newline=None): +def __init__(self, initial_value=""): super(StringIO, self).__init__(BytesIO(), - encoding=encoding, - newline=newline) + encoding="utf-8", + newline='\n') if initial_value: if not isinstance(initial_value, basestring): initial_value = str(initial_value) __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1029> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1047] py3k: corrections for test_subprocess on windows
New submission from Amaury Forgeot d'Arc: I join three patches for py3k on Windows: 1/ getargs.diff adds the 'Z' and 'Z#' format specifiers for PyArg_ParseTuple. They mimic z and z# for unicode strings, by accepting a Unicode or None (in which case the Py_UNICODE* pointer is set to NULL). With doc and tests. 2/ subprocess.diff converts file PC/_subprocess.c to unicode. We use the Unicode version of the win32 api (and Z conversion from previous patch) 3/ stdout.diff: sys.stdout must not convert the line endings, Windows already does it. Without this patch, when redirecting the output of python, the file contains \r\r\n for each line. (test_subprocess did catch this) -- components: Interpreter Core, Windows files: getargs.diff messages: 55384 nosy: amaury.forgeotdarc severity: normal status: open title: py3k: corrections for test_subprocess on windows versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1047> __ getargs.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1047] py3k: corrections for test_subprocess on windows
Amaury Forgeot d'Arc added the comment: Did I say that test_subprocess now passes on windows? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1047> __ subprocess.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1047] py3k: corrections for test_subprocess on windows
Changes by Amaury Forgeot d'Arc: __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1047> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1048] py3k: correction for test_float on Windows
New submission from Amaury Forgeot d'Arc: test_float crashes on Windows, because the %zd format is used in a call to PyOS_snprintf(). The attached patch properly uses PY_FORMAT_SIZE_T. -- components: Windows files: formatter.diff messages: 55389 nosy: amaury.forgeotdarc severity: normal status: open title: py3k: correction for test_float on Windows type: crash versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1048> __ formatter.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1050] py3k: correction for test_marshal on Windows
New submission from Amaury Forgeot d'Arc: On Windows, debug builds insert stack probes, and recursive functions tend to exhaust the stack faster. This patch reduces the marshal maximum depth from 2000 to 1500 for debug builds only. Optimized builds are not affected. -- components: Windows files: marshall.diff messages: 55391 nosy: amaury.forgeotdarc severity: normal status: open title: py3k: correction for test_marshal on Windows versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1050> __ marshall.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1050] py3k: correction for test_marshal on Windows
Amaury Forgeot d'Arc added the comment: I forgot to say that this allows test_marshal to pass with debug builds. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1050> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040] Unicode problem with TZ
Amaury Forgeot d'Arc added the comment: I have a patch for this, which uses MBCS conversion instead of relying on the default utf-8 (here and several other places). Tested on a French version of winXP. Which leads me to the question: should Windows use MBCS encoding by default when converting between char* and PyUnicode, and not utf-8? There are some other tracker items which would benefit from this. After all, C strings can only come from 1) python code, 2) system i/o and messages, and 3) constants in source code. IMO, 1) can use the representation it prefers, 2) would clearly lead to less error if handled as MBCS and 3) only uses 7bit ascii. There is very little need for utf-8 here. -- nosy: +amaury.forgeotdarc __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1040> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1075] py3k: Unicode error in os.stat on Windows
New submission from Amaury Forgeot d'Arc:
os.stat("nonexistent") raises a UnicodeDecodeError on German, Polish and
French Windowses.
The reason: Windows returns an error message which contains accented
letters encoded as MBCS, but python decodes it with utf-8.
This patch uses the Unicode version of FormatMessageW to get the unicode
string directly.
--
files: errors.diff
messages: 55539
nosy: amaury.forgeotdarc
severity: normal
status: open
title: py3k: Unicode error in os.stat on Windows
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1075>
__
errors.diff
Description: Binary data
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1076] py3 patch: full Unicode version for winreg module
New submission from Amaury Forgeot d'Arc: With this patch, the winreg module is now completely unicode: it only uses Windows wide-char API functions, and all strings (keys, subkeys, values) are passed untranslated. str8 is banned, and byte objects are only allowed for raw binary data. Note: It seems a good approach to use the wide-char Windows API whenever possible. They fit very well with PyUnicode strings, and simplify the code... -- components: Unicode files: winreg.diff messages: 55540 nosy: amaury.forgeotdarc severity: normal status: open title: py3 patch: full Unicode version for winreg module versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1076> __ winreg.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1185] py3k: Completely remove nb_coerce slot
New submission from Amaury Forgeot d'Arc: Arguments coercion has been removed in py3k for a while, but there are still some traces of it. This patch removes the nb_coerce slot and the last usages of __coerce__. Documentation is also updated: Py_TPFLAGS_CHECKTYPES does not exists anymore. Note: I ran the testsuite on Windows only. -- components: Interpreter Core files: nocoerce.diff messages: 56067 nosy: amaury.forgeotdarc severity: normal status: open title: py3k: Completely remove nb_coerce slot type: rfe versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1185> __ nocoerce.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1189] Documentation for tp_as_number tp_as_sequence tp_as_mapping
New submission from Amaury Forgeot d'Arc: This patch adds documentation for all the fields in the tp_as_number, tp_as_sequence and tp_as_mapping structures. It may not be complete, but is still better than the XXX in the current docs. This is my first contribution to the doc, feel free to amend it! This patch describes the python3.0 situation, which is simpler since the removal of coercion. It can serve as a start for 2.6 as well; a second patch about coercion will follow. PS: it's really a pleasure to use the new ReST format. -- components: Documentation files: numbermethods-py3k.diff messages: 56087 nosy: amaury.forgeotdarc severity: normal status: open title: Documentation for tp_as_number tp_as_sequence tp_as_mapping versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1189> __ numbermethods-py3k.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1199] Documentation for tp_as_number... version 2.6
New submission from Amaury Forgeot d'Arc: This patch is similar to http://bugs.python.org/issue1189, but in line with python svn trunk (and 2.5 most probably as well): documentation of all slots of tp_as_number, tp_as_mapping, tp_as_sequence. The main difference with 3.0 is the coercion. -- components: Documentation files: numbermethods-2.6.diff messages: 56124 nosy: amaury.forgeotdarc severity: normal status: open title: Documentation for tp_as_number... version 2.6 versions: Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1199> __ numbermethods-2.6.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1297] pyconfig.h not compatible with MS VC++ Express Edition
Amaury Forgeot d'Arc added the comment: I found that BaseTsd.h is part of the Windows SDK, which is not included in the Express Edition. It can be installed separately. OTOH, the python core still compiles without the #include (using VC++ 2005 Express Edition). What about other compilers? What is this file needed for? -- nosy: +amaury.forgeotdarc __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1297> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1304] py3k compilation on Windows
New submission from Amaury Forgeot d'Arc: This patch is needed to have py3k compile on win32, since the introduction of bytes_methods.c. Also, use the recently re-added md5module.c and sha1module.c, because a precompiled openssl library is difficult to obtain on Windows. Note: I tested only with VS2005. I will watch the buildbots to verify that compilation actually succeeds. -- components: Build, Windows files: win32build.diff messages: 56573 nosy: amaury.forgeotdarc severity: normal status: open title: py3k compilation on Windows versions: Python 3.0 Added file: http://bugs.python.org/file8571/win32build.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1304> __ win32build.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1304] py3k compilation on Windows
Amaury Forgeot d'Arc added the comment: I generated the file with "svn diff", on Windows. Is it a line ending issue in the diff file? Many text files have the svn:eol-style=native property, but the PCBuild8/*/*.vcproj don't. I upload a new version of the patch, with all line endings converted to Unix mode. It should match your local copy. Added file: http://bugs.python.org/file8593/win32build.2.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1304> __ win32build.2.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1319] py3k: fixes for test_ctypes
New submission from Amaury Forgeot d'Arc:
Updates to ctypes for python 3.0 to make the tests pass.
Notable changes are:
- return bytes instead of str8
- integers in range(256) are accepted as "one char string":
libc.strchr("abcdef", 98) is now valid.
- directly use the wide-char version of the win32 function LoadLibrary.
Tested on WinXP, with Visual Studio Express 2005.
--
components: Interpreter Core
files: ctypes.diff
messages: 56696
nosy: amaury.forgeotdarc
severity: normal
status: open
title: py3k: fixes for test_ctypes
versions: Python 3.0
Added file: http://bugs.python.org/file8600/ctypes.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1319>
__
ctypes.diff
Description: Binary data
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1323] py3k: file.truncate() changes the file position
New submission from Amaury Forgeot d'Arc: This patch corrects a problem in test_file.py on Windows: f.truncate() seeks to the truncation point, but does not empty the buffers. In the test, f.tell() returns -1... Now we flush the file before, and seek to the initial position after. The same trick was present in 2.5, in fileobject.c::file_truncate. The same comments apply as well. Reviewers needed! Flushing may change the behaviour, but seems more correct to me (and closer to python2.5). Should we add specific tests for this? Also, change the test to be sure to close the file before trying to remove it (it seems that in a finally: block, the exception still references all the local variables in the traceback). Otherwise the previous problem is hidden by a "file locked" error in the finally block. -- components: Windows files: truncate.diff messages: 56732 nosy: amaury.forgeotdarc severity: normal status: open title: py3k: file.truncate() changes the file position versions: Python 3.0 Added file: http://bugs.python.org/file8606/truncate.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1323> __ truncate.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1340] correction for test_tempfile in py3k on Windows
New submission from Amaury Forgeot d'Arc:
This tiny patch correct a failure in test_tempfile on Windows: in
SpooledTemporaryFile, avoid translating the newlines twice.
Otherwise, in "universal" text mode, \n gets transformed to \r\n, then
to \r\r\n, which is read as \n\n.
Passing the encoding is OK, since the round-trip gives the same result,
and it allow encoding errors to occur at the right place.
Index: Lib/tempfile.py
===
--- Lib/tempfile.py (revision 58680)
+++ Lib/tempfile.py (working copy)
@@ -495,7 +495,7 @@
if 'b' in mode:
self._file = _io.BytesIO()
else:
-self._file = _io.StringIO(encoding=encoding, newline=newline)
+self._file = _io.StringIO(encoding=encoding)
self._max_size = max_size
self._rolled = False
self._TemporaryFileArgs = {'mode': mode, 'buffering': buffering,
--
components: Windows
messages: 56830
nosy: amaury.forgeotdarc
severity: normal
status: open
title: correction for test_tempfile in py3k on Windows
versions: Python 3.0
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1340>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1341] correction for test_fileinput in py3k on Windows
New submission from Amaury Forgeot d'Arc: This patch corrects test_fileinput on Windows: when redirecting stdout, os.open should be given O_BINARY, because the file descriptor is then wrapped in a text-mode file; os.fdopen(fd, "w"). -- files: fileinput.diff messages: 56833 nosy: amaury.forgeotdarc severity: normal status: open title: correction for test_fileinput in py3k on Windows Added file: http://bugs.python.org/file8623/fileinput.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1341> __ fileinput.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1341] correction for test_fileinput in py3k on Windows
Changes by Amaury Forgeot d'Arc: -- components: +Windows versions: +Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1341> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1359] py3k: out of bounds read in PyUnicode_DecodeUnicodeEscape
New submission from Amaury Forgeot d'Arc:
A correction for the problem found by GvR in change 58692:
> There's one mystery: if I remove ob_sstate from the PyStringObject struct,
> some (unicode) string literals are mutilated, e.g. ('\\1', '\1') prints
> ('\\1', '\t'). This must be an out of bounds write or something that I
> can't track down. (It doesn't help that it doesn't occur in debug mode.
> And no, make clean + recompilation doesn't help either.)
>
> So, in the mean time, I just keep the field, renamed to 'ob_placeholder'.
I think I found the problem. It reproduces on Windows, with a slightly
different input
>>> ('\\2','\1')
('\\2', '\n')
(the win32 release build is of the kind "optimized with debug info", so
using the debugger is possible)
The problem is in unicodeobject.c::PyUnicode_DecodeUnicodeEscape:
- the input buffer is not null-terminated
- when decoding octal escape, we increment s without checking if it is
still in the limits.
In my case, the "\1" was followed by a "2" in memory, hence the bogus
chr(0o12) == '\n'.
Also corrected a potential problem when the string ends with a \:
PyUnicode_DecodeUnicodeEscape("\\t", 1) should return an error.
--
components: Interpreter Core
files: unicodeEscape.diff
messages: 56933
nosy: amaury.forgeotdarc, gvanrossum
severity: normal
status: open
title: py3k: out of bounds read in PyUnicode_DecodeUnicodeEscape
versions: Python 3.0
Added file: http://bugs.python.org/file8658/unicodeEscape.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1359>
__
unicodeEscape.diff
Description: Binary data
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1359] py3k: out of bounds read in PyUnicode_DecodeUnicodeEscape
Amaury Forgeot d'Arc added the comment: I don't like this assert either: this function is part of the public API, and should not crash the interpreter just because of a trailing \. To test easily: import ctypes decode = ctypes.pythonapi.PyUnicodeUCS2_DecodeUnicodeEscape decode.restype = ctypes.py_object decode(b'\\1', 1, None) This should gently raise a UnicodeDecodeError IMO. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1359> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1382] py3k-pep3137: patch for test_ctypes
New submission from Amaury Forgeot d'Arc: This patch corrects test_ctypes in the py3k-pep3137 branch. Replacing PyBytes_* by PyString_* was 99% of the task. Also had to modify binascii, which used to return buffers instead of bytes strings. Tested on winXP. -- components: Tests files: ctypes3.diff messages: 57099 nosy: amaury.forgeotdarc, gvanrossum, tiran severity: normal status: open title: py3k-pep3137: patch for test_ctypes versions: Python 3.0 Added file: http://bugs.python.org/file8686/ctypes3.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1382> __ ctypes3.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1386] py3k-pep3137: patch to ensure that all codecs return bytes
New submission from Amaury Forgeot d'Arc: Most codecs return buffer objects, when the rule is now to return bytes. This patch adds a test, and corrects failing codecs. (more PyBytes_* -> PyString_* replacements) -- components: Unicode files: codecs.diff messages: 57109 nosy: amaury.forgeotdarc, tiran severity: normal status: open title: py3k-pep3137: patch to ensure that all codecs return bytes versions: Python 3.0 Added file: http://bugs.python.org/file8690/codecs.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1386> __ codecs.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1387] py3k-pep3137: patch for hashlib on Windows
New submission from Amaury Forgeot d'Arc: On Windows, openssl is not always available, in this case python uses its own implementation of md5, sha1 &co. This patch correct the failing tests (test_hashlib and test_uuid), by returning bytes instead of buffers. -- components: Windows files: hashlib.diff messages: 57110 nosy: amaury.forgeotdarc, tiran severity: normal status: open title: py3k-pep3137: patch for hashlib on Windows versions: Python 3.0 Added file: http://bugs.python.org/file8691/hashlib.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1387> __ hashlib.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1384] Windows fix for inspect tests
Amaury Forgeot d'Arc added the comment: A slightly modified patch, which uses os.path.normcase before comparing file names. -- nosy: +amaury.forgeotdarc Added file: http://bugs.python.org/file8700/py3k_inspect_2.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1384> __ py3k_inspect_2.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1395] py3k: duplicated line endings when using read(1)
New submission from Amaury Forgeot d'Arc: When reading a Windows text file one byte at a time, \r\n get split into two function calls, and the user receives two \n. The following test fails (put it somewhere in test_io.py, inside TextIOWrapperTest for example) def testReadOneByOne(self): txt = io.TextIOWrapper(io.BytesIO(b"AA\r\nBB")) reads = "" while True: c = txt.read(1) if not c: break reads += c self.assertEquals(reads, "AA\nBB") # AssertionError: 'AA\n\nBB' != 'AA\nBB' Note that replacing read(1) by read(2) gives the correct result. This problem is why test_netrc fails on Windows. It may also be the root cause for issue 1142 (when \r\n position is just a multiple of the _CHUNK_SIZE). It also possible that the correction to this problem will have good effects on test_mailbox, which uses tell() and seek() intensively. -- messages: 57147 nosy: amaury.forgeotdarc, gvanrossum, tiran severity: normal status: open title: py3k: duplicated line endings when using read(1) versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1395> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1384] Windows fix for inspect tests
Amaury Forgeot d'Arc added the comment: Yes, the patch is needed. The problem arises when you run the python executable in different ways WITHOUT deleting the .pyc files. Example on my machine: Note that the exact path to run python is not the same: >cd C:\dev\python\py3k\PCbuild8 >del /s ..\*.pyc >c:\dev\python\py3k\PCbuild8\win32debug\python_d.exe -E -tt ../lib/test/regrtest.py -v test_inspect [test OK] >C:\dev\python\py3k\PCbuild8\win32debug\python_d.exe -E -tt ../lib/test/regrtest.py -v test_inspect [test FAILED] If I always use the same path the tests succeed. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1384> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1395] py3k: duplicated line endings when using read(1)
Amaury Forgeot d'Arc added the comment: Some thoughts: - is it ok to call replacenl multiple times on the same string? \r\r\n and other combinations like this. - I wonder if it is possible to correctly handle \r\n at the CHUNK_SIZE limit without an incremental decoder. it seems that we need at least a flag saying "\r was previously read, ignore the next \n" __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1395> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1395] py3k: duplicated line endings when using read(1)
Amaury Forgeot d'Arc added the comment: This patch goes in the right direction, but has several problems IMO: - it reads a complete chunk for just one more byte - the re-read should be disabled when lineends are not translated these two are minor annoyance and can be easily corrected, but: - there is no limit to the re-read; it can exhaust the memory if the source is a big file with many \r (like a Mac text file) - How does this behave if the underlying stream has not yet available data (a socket, a terminal, or an opened file): will the re-read block at the 129th byte until more data is available? If so, it is annoying for a simple call to read(1). I will try to write these test cases if you want. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1395> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1395] py3k: duplicated line endings when using read(1)
Amaury Forgeot d'Arc added the comment: > The new patch fixes test_netrc for me but test_csv and test_mailbox are > still broken. For test_mailbox at least, I think I have a clue: the _pending member now contains translated newlines. But in tell(), we use its length and compare it with the length of a previous "pending" value stored in self._snapshot... Can we try to somehow move the replacenl() call inside the _get_chunk function? Not sure it will work. This gets more and more obscure... __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1395> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1395] py3k: duplicated line endings when using read(1)
Amaury Forgeot d'Arc added the comment: > io3.diff does replacenl() in adjust_chunk() (trying Amaury's > suggestion). Can you see if it fixes test_mailbox failures? Unfortunately, it does not. And some tests now fail in test_io (correcting testTelling seems a good start point, since we just changed the tell() behaviour) __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1395> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1395] py3k: duplicated line endings when using read(1)
Amaury Forgeot d'Arc added the comment: OK, I have taken another approach which seems to work (see io4.diff): It uses an IncrementalNewlineDecoder, which wraps the initial (e.g. utf-8) decoder. All the tests in test_io pass on Windows, including those added by io.diff and io2.diff. This was not the case with the other proposed patches. While not completely finished, this approach seems much saner to me: it is simple, does not introduce obscure variables or functions, and is compatible with the (complex) code in tell() which reconstruct the file position. Next steps are: - move _seennl management inside this decoder, and remove _replacenl - make the decoder directly inherit from codecs.IncrementalDecoder; code may be easier to understand. - fix test_mailbox. About mailbox.py: it seems that the code cannot work: it uses statements like self._file.read(stop - self._file.tell()) where 'stop' was previously initialized with some other call to self._file.tell(). But read() counts characters, whereas tell() returns byte counts. The question is now: how does it work with python2.5? I'll try to add debug prints to see where the differences are. Added file: http://bugs.python.org/file8711/io4.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1395> __ io4.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1395] py3k: duplicated line endings when using read(1)
Amaury Forgeot d'Arc added the comment: Sorry, I think I corrupted the file by hand. Here is another version Added file: http://bugs.python.org/file8712/io4.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1395> __ io4.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1395] py3k: duplicated line endings when using read(1)
Amaury Forgeot d'Arc added the comment: > About mailbox.py: it seems that the code cannot work Of course: the file mode was recently changed from rb+ to r+ (revision 57809). This means that every occurrence of os.linesep has to disappear. Oh my. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1395> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1395] py3k: duplicated line endings when using read(1)
Amaury Forgeot d'Arc added the comment: > The new io4.diff breaks test_io and test_univnewlines on Linux oops, I missed this one. Here is a new version: io5.diff, which should handle the "seen newlines" better. Two more bug fixes found by test_univnewlines: - write() should return the number of characters written, but before they are newline-translated. - a problem in tell(), my decoder can return two characters even when you feed only one (example: decode(b'\r') holds the \r and returns nothing. then a decode(b'x') returns both chars "\rx") Added file: http://bugs.python.org/file8714/io5.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1395> __ io5.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1395] py3k: duplicated line endings when using read(1)
Amaury Forgeot d'Arc added the comment: Updated patch (io6.diff): - simplifications in readline - seennl is now completely handled by the NewlineDecoder Added file: http://bugs.python.org/file8719/io6.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1395> __ io6.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1415] py3k: pythonw.exe fails because std streams a missing
Amaury Forgeot d'Arc added the comment:
I made some checks with the vc2005 (msvcr80) runtime library:
- fd==-2 corresponds to the _NO_CONSOLE_FILENO constant.
A comment in the CRT code says:
/*
* For stdin, stdout & stderr, we use _NO_CONSOLE_FILENO (a value
* different from _INVALID_HANDLE_VALUE to distinguish between
* a failure in opening a file & a program run without a console.
*/
- in this case, stderr is a buffered FILE*, but the flush() method
always fails. This makes not difference for python2.5, because it never
looks at the return value of fprintf (which is not very consistent, BTW).
Since pythonw (2.5) silently discards any output to stderr, we could
achieve the same by opening the nul file...
--- c:/temp/t 2007-11-12 13:54:34.105463200 +0100
+++ c:/afa/python/py3k/Modules/_fileio.c2007-11-12 13:52:42.576675100
+0100
@@ -149,6 +149,15 @@
if (PyArg_ParseTupleAndKeywords(args, kwds, "i|si:fileio",
kwlist, &fd, &mode, &closefd)) {
+#ifdef MS_WINDOWS
+ /* Windows sets the descriptor to _NO_CONSOLE_FILENO when */
+ /* the program is run without a console */
+ if (fd == -2)
+ {
+ fd = open("nul", "r+");
+ }
+ else
+#endif
if (fd < 0) {
PyErr_SetString(PyExc_ValueError,
"Negative filedescriptor");
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1415>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1415] py3k: pythonw.exe fails because std streams a missing
Amaury Forgeot d'Arc added the comment: Doh, you're right: > c:\python24\pythonw -c "import sys;print sys.stderr.fileno()"|more -1 > c:\python24-vc8\pythonw -c "import sys;print sys.stderr.fileno()"|more -2 /me needs to get the code of msvcrt7. We could simply check for (fd<0) instead, but it's better to reserve this special processing to stdin/stdout/stderr. maybe somewhere in pythonrun.c. I'll try a patch later tonight. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1415> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1265] pdb bug with "with" statement
Amaury Forgeot d'Arc added the comment:
Corrected by revision 58958.
"with" is innocent. The problem is this function in abc.py which uses a
generator expression:
def __instancecheck__(cls, instance):
"""Override for isinstance(instance, cls)."""
return any(cls.__subclasscheck__(c)
for c in {instance.__class__, type(instance)})
It is called both by pdb (deep inside 'print') and the debugged code (in
PyObject_MethodCall), and this reveals the bug.
--
nosy: +amaury.forgeotdarc
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1265>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1265] pdb bug with "with" statement
Amaury Forgeot d'Arc added the comment: __instancecheck__ should be simpler: all classes are new-style, how is it possible to have different results for instance.__class__ and type(instance) ? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1265> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1265] pdb bug with "with" statement
Amaury Forgeot d'Arc added the comment: > BTW**2: I've noticed that abc.py's __instancecheck__ gets called a lot > at times when I don't expect it. Can you research this a bit? In classobject.c, method_call() calls PyObject_IsInstance() on the first arg when the method is unbound. This happens a lot in io.py, each time the code calls a base class method. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1265> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1415] py3k: pythonw.exe fails because std streams a missing
Amaury Forgeot d'Arc added the comment: (Sorry, I cannot test just now) What happens if pythonw.exe calls the print() function? Please tell me that it does not throw an exception. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1415> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1415] py3k: pythonw.exe fails because std streams a missing
Amaury Forgeot d'Arc added the comment: Is it the only possibility? On Windows, it is quite common to print to stdout for debugging purposes, then deploy the application with pythonw.exe which suppresses the console. Without any change to the code. Most pygame programs I know work this way, and C programs have the same behaviour. Prints should work, even if they discard their output. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1415> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1415] py3k: pythonw.exe fails because std streams a missing
Amaury Forgeot d'Arc added the comment: > As far as I can see print() works if sys.stdout is either None > (discard output ASAP) or a file like object. Even > print(file=syst.stderr) works. Ah, I prefer this. > sys.stdout.write() is going to fail when sys.stdout is None > but that's not my concern. It's not very important indeed. I'm happy with the current behaviour. Let's close this issue. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1415> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1134] Parsing a simple script eats all of your memory
Amaury Forgeot d'Arc added the comment: fp_readl is indeed broken in several ways: - decoding_buffer should be reset to NULL when all data has been read (buflen <= size). - the (buflen > size) case will cause an error on the next pass, since the function cannot handle PyBytesObject. IOW, the function is always wrong ;-) I have a correction ready (jafo's patch already addresses the first case), but cannot access svn here. I will try to provide a patch + test cases later tonight. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1134> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1134] Parsing a simple script eats all of your memory
Amaury Forgeot d'Arc added the comment: Corrected in revision 59001, with a modified patch. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1134> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1452] subprocess's popen.stdout.seek(0) doesn't raise an error
Amaury Forgeot d'Arc added the comment: Python 2.5 on Windows has the same behaviour, it does not fail. In general, python does not try to hide this kind of differences. -- nosy: +amaury.forgeotdarc __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1452> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1395] py3k: duplicated line endings when using read(1)
Amaury Forgeot d'Arc added the comment: Committed the patch in r59060. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1395> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1342] Crash on Windows if Python runs from a directory with umlauts
Amaury Forgeot d'Arc added the comment: Assign to myself. Among the things to do, use Py_FileSystemDefaultEncoding (=mbcs on Windows) to encode sys.path items; likewise in NullImporter_init and other functions. So many places to change, we need serious testcases. -- assignee: -> amaury.forgeotdarc nosy: +amaury.forgeotdarc __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1342> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1193] os.system() encoding bug on Windows
Amaury Forgeot d'Arc added the comment:
Note that the final .encode("cp936") is now invalid: os.system accepts
unicode strings, not bytes:
>>> os.system(("echo " + sys.stdin.readline().rstrip("\n")))
Corrected as r59065.
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1193>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1342] Crash on Windows if Python runs from a directory with umlauts
Amaury Forgeot d'Arc added the comment: Agreed. I will try to stay with PyObjects* until really needed by a system call. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1342> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1460] codecs utf7 decoding error
Amaury Forgeot d'Arc added the comment: The utf-7 incremental decoder was indeed losing its state between two chunks of data. Corrected as r59076. -- nosy: +amaury.forgeotdarc resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1460> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1402] Interpreter cleanup: order of _PyGILState_Fini and PyInterpreterState_Clear
Amaury Forgeot d'Arc added the comment: I managed to reproduce the problem consistently with the following code: import ctypes, sys, time, thread # Module globals are cleared before __del__ is run # So save the functions in class dict class C: ensure = ctypes.pythonapi.PyGILState_Ensure release = ctypes.pythonapi.PyGILState_Release def __del__(self): state = self.ensure() self.release(state) def waitingThread(): x = C() time.sleep(100) thread.start_new_thread(waitingThread, ()) time.sleep(1) sys.exit(42) On exit, PyInterpreterState_Clear stops the sleeping thread and free its local variables. But at this time _PyGILState_Fini has already been called... The initial patch also corrects this problem. I join another patch, which adds the above code in a testcase. Ready to check-in, but can someone have a look? -- nosy: +amaury.forgeotdarc Added file: http://bugs.python.org/file8798/test_gilstate.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1402> __ test_gilstate.patch Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1409] new keyword-only function parameters interact badly with nested functions
Amaury Forgeot d'Arc added the comment: Corrected as r59155. Thanks for the report! -- nosy: +amaury.forgeotdarc resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1409> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1442] pythonstartup addition of minor error checking
Amaury Forgeot d'Arc added the comment: Shall we close this issue? -- nosy: +amaury.forgeotdarc __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1442> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1445] SystemError accessing uninitialised cell contents
Amaury Forgeot d'Arc added the comment: Fixed in r59170 (trunk) and r59171 (release25-maint). -- nosy: +amaury.forgeotdarc resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1445> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1402] Interpreter cleanup: order of _PyGILState_Fini and PyInterpreterState_Clear
Amaury Forgeot d'Arc added the comment: > The _PyGILState_Fini function might cause user code to run as well, > it removes the thread-local variable that contains the PyThreadState > for threads, and that contains some Python objects that might contain > arbitrary values (such as the last exception value). No, _PyGILState_Fini does not invoke any python code; it only clears C variables. The last exception value is deleted during the call to PyInterpreterState_Clear() (inside PyThreadState_Clear). __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1402> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1045] Performance regression in 2.5
Amaury Forgeot d'Arc added the comment: The slowdown is due to the new function _PyObject_LengthHint: on my Win2K machine, the command python -m timeit "tuple(1 for _ in xrange(3))" answers: 10 loops, best of 3: 4.14 usec per loop By adding a line "return rv;" on the second line of _PyObject_LengthHint, I get: 10 loops, best of 3: 2.71 usec per loop Should we disable this function for some known built-in types? -- nosy: +amaury.forgeotdarc __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1045> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1509] Documentation lacking for the sqlite3 module.
Amaury Forgeot d'Arc added the comment: > I thought that at one point those methods were documented sqlite3 implements the DB-API: http://www.python.org/dev/peps/pep-0249/ is it the documentation you had in mind? -- nosy: +amaury.forgeotdarc __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1509> __ ___ 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
Amaury Forgeot d'Arc added the comment: I don't have any 64bit machine to test with, but it seems to me that there is a problem in the function getargs.c::convertsimple(): the t# and w# formats use the buffer interface, but the code uses an int to store its length! Look for the variables declared as "int count;". I suggest to replace it with a Py_ssize_t in both places. Shouldn't the compiler emit some warning in this case? -- nosy: +amaury.forgeotdarc __ 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
[issue1521] string.decode() fails on long strings
Amaury Forgeot d'Arc added the comment: Here is a patch, with a unit test (I was surprised that test_bigmem.py already contained a test_decode function, which was left empty). But I still don't have access to any 64bit machine. Can someone try and see if the new tests in test_bigmem.py fail, and that the patch in getargs.c corrects the problem? Added file: http://bugs.python.org/file8832/getargs.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1521> __ getargs.patch Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1402] Interpreter cleanup: order of _PyGILState_Fini and PyInterpreterState_Clear
Amaury Forgeot d'Arc added the comment: Committed revision 59231 in trunk. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1402> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1529] Error when passing a file object to tarfile.open()
Amaury Forgeot d'Arc added the comment: This problem was fixed in r57617. Can you check with a more recent build? -- nosy: +amaury.forgeotdarc resolution: -> works for me __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1529> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12881] ctypes: segfault with large structure field names
Amaury Forgeot d'Arc added the comment: Note that there is at least one other place where alloca() is used with potentially large values: the POINTER() function in callproc.c. Also, PyUnicode_FromFormat could be used instead of sprintf. -- ___ Python tracker <http://bugs.python.org/issue12881> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12483] CThunkObject_dealloc should call PyObject_GC_UnTrack?
Amaury Forgeot d'Arc added the comment:
I was going to say that the patch has no visible effect, since
PyObject_GC_Del() calls something which has the same effect as
PyObject_GC_Untrack...
But the following code crashes the interpreter! And of course the patch fixes
it...
import ctypes, gc
class Nasty:
def __del__(self):
gc.collect()
ctypes.CFUNCTYPE(None)(lambda x=Nasty(): None)
print("OK")
--
___
Python tracker
<http://bugs.python.org/issue12483>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12483] CThunkObject_dealloc should call PyObject_GC_UnTrack?
Amaury Forgeot d'Arc added the comment: Thanks for your help! I fear they are many other places like this one in CPython code. -- ___ Python tracker <http://bugs.python.org/issue12483> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12946] PyModule_GetDict() claims it can never fail, but it can
Amaury Forgeot d'Arc added the comment: The path with PyDict_New() is never taken, because PyModule_New already fills md_dict. -- nosy: +amaury.forgeotdarc ___ Python tracker <http://bugs.python.org/issue12946> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Amaury Forgeot d'Arc added the comment: I'm a bit worried by the Windows version: - liblzma can't be compiled by Visual Studio: too many C99 isms, mostly variables declared in the middle of a block. It's doable for sure, but it's a lot of work. - liblzma is normally compiled with mingw, but we have to be sure that is uses the correct MSCRT C runtime, and what about debug builds? - All extension modules use static libraries: zlib, expat, sqlite. But a gcc static library can't be used by Visual Studio. - The way recommended by XZ is to use a precompiled liblzma.dll; Then it should be easy to build an extension module, but its would be the first time that we distribute an extension module which needs a non-system DLL. Is it enough to copy it next to _lzma.pyd? Is there some work to do in the installer? Too many "but"s :) -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13006] bug in core python variable binding
Amaury Forgeot d'Arc added the comment:
This is a bug in the script; the code is similar to the following::
>>> funclist = []
>>> global_list = []
>>> funclist.append(global_list)
>>> global_list.append(1)
>>> funclist.append(global_list)
>>> print funclist
[[1], [1]]
i.e the same object is added twice to "funclist", any modification to the first
item is a modification to the second. See also
http://www.python.org/doc//current/faq/programming.html#how-do-i-create-a-multidimensional-list
In your script, it's certainly happens because there are multiple nested blocks
('{' '}') in the same function ('$FUNC'), so global_list is still the *same*
list.
--
nosy: +amaury.forgeotdarc
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue13006>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13044] pdb throws AttributeError at end of debugging session
Amaury Forgeot d'Arc added the comment:
By modifying a bit the Python intepreter, I got this traceback:
Traceback (most recent call last):
File "/home/amauryfa/python/cpython2.7/Lib/_weakrefset.py", line 38, in
_remove
def _remove(item, selfref=ref(self)):
File "/home/amauryfa/python/cpython2.7/Lib/bdb.py", line 50, in trace_dispatch
return self.dispatch_call(frame, arg)
File "/home/amauryfa/python/cpython2.7/Lib/bdb.py", line 76, in dispatch_call
if not (self.stop_here(frame) or self.break_anywhere(frame)):
File "/home/amauryfa/python/cpython2.7/Lib/bdb.py", line 147, in
break_anywhere
return self.canonic(frame.f_code.co_filename) in self.breaks
File "/home/amauryfa/python/cpython2.7/Lib/bdb.py", line 33, in canonic
canonic = os.path.abspath(filename)
AttributeError: 'NoneType' object has no attribute 'path'
Here is the gdb stack when the error is printed:
#0 PyErr_Print () at Python/pythonrun.c:1040
#1 0x00480c1d in handle_callback (object=) at
Objects/weakrefobject.c:884
#2 PyObject_ClearWeakRefs (object=) at
Objects/weakrefobject.c:966
#3 0x00423a37 in class_dealloc (op=0x77f68890) at
Objects/classobject.c:193
#4 0x0046a7ed in tupledealloc (op=0x77f89410) at
Objects/tupleobject.c:220
#5 0x00423afb in class_dealloc (op=0x77f7ed50) at
Objects/classobject.c:194
#6 0x004270cb in instance_dealloc (inst=0x77f8a518) at
Objects/classobject.c:670
#7 0x0044de47 in insertdict (mp=0x7f7800, key='environ',
hash=-5347984860299468300, value=None)
at Objects/dictobject.c:530
#8 0x00450287 in PyDict_SetItem (op=
{'WTERMSIG': None, 'lseek': None, 'EX_IOERR': None, 'EX_NOHOST': None,
'seteuid': None, 'pathsep': None, 'execle': None, 'major': None, '_Environ':
None, 'fstatvfs': None, 'uname': None, 'kill': None, 'urandom': None, 'execlp':
None, 'getegid': None, 'getresgid': None, 'EX_OSFILE': None, 'umask': None,
'linesep': None, 'fchmod': None, 'lchown': None, 'setgid': None, 'tmpnam':
None, 'devnull': None, 'EX_NOINPUT': None, 'makedev': None, 'fstat': None,
'getlogin': None, 'O_CREAT': None, 'dup2': None, 'read': None, '__file__':
None, 'getppid': None, 'fchown': None, 'getloadavg': None, 'WIFSTOPPED': None,
'getpgrp': None, '_spawnvef': None, 'TMP_MAX': None, 'utime': None, 'execl':
None, 'F_OK': None, '_make_stat_result': None, 'name': None, 'fsync': None,
'tcsetpgrp': None, 'statvfs': None, 'setreuid': None, 'remove': None,
'setegid': None, 'P_NOWAITO': None, '_copy_reg': None, 'execv': None, 'spawnv':
None, 'spawnvpe': None, 'EX_OSERR': None, 'ttyname': None, 'pardir': None,
'tempnam': None, 'tmpfile': None, 'sep...(truncated), key='environ',
value=None) at Objects/dictobject.c:775
#9 0x0045268e in _PyModule_Clear (m=) at
Objects/moduleobject.c:138
#10 0x004bfa17 in PyImport_Cleanup () at Python/import.c:498
#11 0x004cd9ef in Py_Finalize () at Python/pythonrun.c:447
So, when the interpreter shuts down, the debugger is still active...
Python 3 does not seem to be affected by this issue. And indeed if I make
UserDict a new-style class, I don't reproduce the error on 2.7 either.
A possible fix is to reset the trace function to None in Py_Finalize.
--
nosy: +amaury.forgeotdarc
___
Python tracker
<http://bugs.python.org/issue13044>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13091] ctypes: memory leak
Amaury Forgeot d'Arc added the comment: How did you obtain this? the resize() function is not called by test_multiprocessing. And are you sure that it's not some kind of reference leak? (this pointer is tied to a CDataObject; its tp_alloc should free the memory) -- ___ Python tracker <http://bugs.python.org/issue13091> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13071] IDLE refuses to open on windows 7
Amaury Forgeot d'Arc added the comment: This issue is very similar to issue5707: it is possible to define a custom key binding to "" or "": just click the Alt box and don't select a letter. There is no check, it's possible to save this buggy key binding, and IDLE won't start anymore. IDLE should: - check the validity of the binding and refuse to save it when it is invalid - gracefully skip invalid bindings from the config file -- nosy: +amaury.forgeotdarc ___ Python tracker <http://bugs.python.org/issue13071> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13071] IDLE refuses to open on windows 7
Amaury Forgeot d'Arc added the comment: What did you do to solve the problem? -- ___ Python tracker <http://bugs.python.org/issue13071> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13070] segmentation fault in pure-python multi-threaded server
Amaury Forgeot d'Arc added the comment: An "unraisable exception" warning will be displayed. -- ___ Python tracker <http://bugs.python.org/issue13070> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Amaury Forgeot d'Arc added the comment: For bz2, Tools/buildbot/external-common.bat has code to download bz2 source, and PCbuild/_bz2.vcproj include and compile these files together with _bz2.pyd. The _ssl module does a similar thing, except that libeay32.lib and libssleay32.lib are built in a separate step. -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13103] copy of an asyncore dispatcher causes infinite recursion
Amaury Forgeot d'Arc added the comment: So, in 3.1 hasattr(y, '__setstate__') *did* recurse and hit the limit, but the exception was caught and hasattr returned False? I think I prefer the new behavior... The patch looks good, I would simply have raised AttributeError(name) though. -- nosy: +amaury.forgeotdarc ___ Python tracker <http://bugs.python.org/issue13103> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13103] copy of an asyncore dispatcher causes infinite recursion
Amaury Forgeot d'Arc added the comment: Let's add the test to 3.3 nonetheless. -- ___ Python tracker <http://bugs.python.org/issue13103> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13070] segmentation fault in pure-python multi-threaded server
Amaury Forgeot d'Arc added the comment: Your application does not segfault with 2.7 because buffered files and sockets use a very different implementation. The io module is present in all versions, but only Python3 uses it for all file-like objects. If the unit test (test_rwpair_cleared_before_textio) crashes 2.7, the fix should be applied. -- ___ Python tracker <http://bugs.python.org/issue13070> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Amaury Forgeot d'Arc added the comment: On http://tukaani.org/xz, I downloaded the file named xz-5.0.3-windows.zip. It contains precompiled dlls for both platforms: bin_i486/liblzma.dll and bin_x86_64/liblzma.dll Unfortunately, there is no import library for VS. It should not be too difficult to make one, though: the provided headers are C89, so it's enough to write stubs for the functions used by the extension module. -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Amaury Forgeot d'Arc added the comment: Ah indeed, the zip archive contains a doc/liblzma.def which can be used to build a liblzma.lib -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Amaury Forgeot d'Arc added the comment: Hey, today I learnt something about mingw! """Rename liblzma.a to e.g. liblzma_static.lib and tell MSVC to link against it.""" Apparently mingw can generate COFF libraries. This may simplify things *a lot*. -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13119] Newline for print() is \n on Windows, and not \r\n as expected
Amaury Forgeot d'Arc added the comment: To people who open the file in their browser: text files are very similar, but newline_3.1.txt has CRLF line endings and newline_3.2.txt has LF line endings. M.Z, how did you obtain them? did you start a subprocess? -- nosy: +amaury.forgeotdarc, haypo ___ Python tracker <http://bugs.python.org/issue13119> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13118] Py_BuildValue format f incorrect description.
Amaury Forgeot d'Arc added the comment: I've checked in the code: 'f' and 'd' are really the same (Python/modsupport.c). And in http://en.wikipedia.org/wiki/Stdarg.h, you can read: """A float will automatically be promoted to a double.""" -- nosy: +amaury.forgeotdarc ___ Python tracker <http://bugs.python.org/issue13118> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13119] Newline for print() is \n on Windows, and not \r\n as expected
Amaury Forgeot d'Arc added the comment: > If the output is redirected (e.g. into a file), > TextIOWrapper is created with line_buffering=False. How does this affect the \r\n translation? -- ___ Python tracker <http://bugs.python.org/issue13119> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13133] FD leaks in ZipFile.read(), ZipFile.extract() and also using explicit arc_member.close()
Amaury Forgeot d'Arc added the comment: Yes, in 2.7 many parts of the stdlib relies on reference counting to close files. But 3.2 introduced a ResourceWarning which is emitted (in debug mode) each time a __del__ closes a valuable resource like a file or a socket. This was done exactly for this reason - help other implementations with a different garbage collector. Now Lib/zipfile.py is probably much more gc-friendly: see how it uses a new member "close_fileobj", and the "with" statement in ZipFile.read(). PyPy will benefit of this when it migrates to 3.2; meanwhile, you could apply the same changes in pypy's own copy of zipfile.py. -- nosy: +amaury.forgeotdarc resolution: -> out of date status: open -> pending ___ Python tracker <http://bugs.python.org/issue13133> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Amaury Forgeot d'Arc added the comment: *Very* good news for lzma on windows: The precompiled static library liblzma.a works very well with MSVC (tested with VS2008 on Windows XP, 32bit). This was a surprise for me... Here is a patch for the win32 build files, to be applied after Nadeem's. I did not update the svn "external" repository, for my local copy I simply extracted xz-5.0.3-windows.zip. Tests pass in release and debug builds, and depends.exe shows no special requirements for _lzma.pyd. I could not test win64. Nadeem, in test.support precisionbigmemtest was recently renamed to bigmemtest, could you update your patch? -- Added file: http://bugs.python.org/file23371/lzma-win32.diff ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4431] Distutils MSVC doesn't create manifest file
Amaury Forgeot d'Arc added the comment: > If I can provide the patch to support Visual Studio 2010 and setup a > builtbot that will pass most of the tests, could we get Python > supported on this platform? Yes. Even if VS2008 remains the preferred compiler to build Python, and the only one used for official binary distributions, there are already project files for VS8 and even VC6 (in PC/VS8.0 and PC/VC6). They are not guaranteed to always work, but are updated from time to time by volunteers. Please open another issue. -- ___ Python tracker <http://bugs.python.org/issue4431> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12760] Add create mode to open()
Amaury Forgeot d'Arc added the comment: issue12797 would allow things like: def create_exclusive_file(filename): return open(filename, "w", opener=lambda path, mode: os.open(path, mode|os.O_CREAT|os.O_EXCL)) -- ___ Python tracker <http://bugs.python.org/issue12760> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12797] io.FileIO and io.open should support openat
Amaury Forgeot d'Arc added the comment: Is "an open file descriptor" correct in English? I'd have written "an opened file descriptor" instead (in 5 places). -- ___ Python tracker <http://bugs.python.org/issue12797> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12105] open() does not able to set flags, such as O_CLOEXEC
Amaury Forgeot d'Arc added the comment: And to be explicit, you can now write: def open_cloexex(filename, mode='r'): return open(filename, mode, opener=lambda path, mod: os.open(path, mod|os.O_CLOEXEC)) -- ___ Python tracker <http://bugs.python.org/issue12105> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12105] open() does not able to set flags, such as O_CLOEXEC
Amaury Forgeot d'Arc added the comment: > So why not to add 'e' character You said it: because it can't be written consistently on all platforms. For example, python does not use CreateFile on Windows, see #12939. -- ___ Python tracker <http://bugs.python.org/issue12105> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12939] Add new io.FileIO using the native Windows API
Amaury Forgeot d'Arc added the comment: An implementation of RawIO with the win32 API can be useful (and I'd be interested to compare the performance) But maybe not for all usages: some Python interfaces are defined in terms of file descriptors, imp.load_module(), and PyTokenizer_FindEncoding for example. -- ___ Python tracker <http://bugs.python.org/issue12939> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
