[issue13870] Out-of-date comment in collections/__init__.py ordered dict
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset f7283825effa by Raymond Hettinger in branch '3.2': Issue 13870: Fix out of date comment. http://hg.python.org/cpython/rev/f7283825effa -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13870 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13870] Out-of-date comment in collections/__init__.py ordered dict
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13870 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13863] import.c sometimes generates incorrect timestamps on Windows + NTFS
Mark Dickinson dicki...@gmail.com added the comment: Also seen on Windows Vista; seems to be a general Windows + NTFS problem. Changing title to make it clearer that this is a core language issue. It seems as though the correct fix would be to use something like GetFileInformationByHandle in place of the fstat calls in import.c. -- title: Using py_compile does not prevent recompilation due to 'bad mtime'. - import.c sometimes generates incorrect timestamps on Windows + NTFS ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13863 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13435] Copybutton does not hide tracebacks
Ezio Melotti ezio.melo...@gmail.com added the comment: This should be fixed now. -- resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13435 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13455] Reorganize tracker docs in the devguide
Changes by Ezio Melotti ezio.melo...@gmail.com: -- stage: needs patch - patch review type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13455 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11457] os.stat(): add new fields to get timestamps as Decimal objects with nanosecond resolution
STINNER Victor victor.stin...@haypocalc.com added the comment: Have you researched how other languages plan to expose sub-millisecond times? The isn't an API that will get points for originality. Also, it needs to be an API that is time efficient (many scripts use os.stat() frequently to scan files for changes and that check needs to be fast). Using decimal timestamps should be an option, float timestamps must remain the default. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11457 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11457] os.stat(): add new fields to get timestamps as Decimal objects with nanosecond resolution
Larry Hastings la...@hastings.org added the comment: Victor: I *think* Raymond's comments were directed at my patch, not yours. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11457 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13872] socket.detach doesn't mark socket._closed
New submission from Matt Joiner anacro...@gmail.com: socket.socket.detach doesn't mark the socket._closed flag. The flag is specific to the Python wrapper, so the fix is put there. Test included. -- components: Library (Lib) files: socket-detach-mark-closed.patch keywords: patch messages: 152005 nosy: anacrolix priority: normal severity: normal status: open title: socket.detach doesn't mark socket._closed type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file24327/socket-detach-mark-closed.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13872 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5210] zlib does not indicate end of compressed stream properly
Changes by Nadeem Vawda nadeem.va...@gmail.com: -- nosy: +nadeem.vawda ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8536] Support new features of ZLIB 1.2.4
Changes by Nadeem Vawda nadeem.va...@gmail.com: -- nosy: +nadeem.vawda ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8536 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5784] raw deflate format and zlib module
Changes by Nadeem Vawda nadeem.va...@gmail.com: -- nosy: +nadeem.vawda ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5784 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5804] Add an 'offset' argument to zlib.decompress
Changes by Nadeem Vawda nadeem.va...@gmail.com: -- nosy: +nadeem.vawda ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5804 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13873] SIGBUS in test_zlib on Debian bigmem buildbot
New submission from Nadeem Vawda nadeem.va...@gmail.com: http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/58/steps/test/logs/stdio -- assignee: nadeem.vawda messages: 152006 nosy: nadeem.vawda priority: normal severity: normal stage: needs patch status: open title: SIGBUS in test_zlib on Debian bigmem buildbot type: crash ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13873 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13874] test_faulthandler: read_null test fails with current clang
New submission from Stefan Krah stefan-use...@bytereef.org:
In non-debug mode the read_null test fails with clang-3.0:
==
FAIL: test_disable (test.test_faulthandler.FaultHandlerTests)
--
Traceback (most recent call last):
File /usr/home/stefan/hg/cpython/Lib/test/test_faulthandler.py, line 235,
in test_disable
self.assertNotEqual(exitcode, 0)
AssertionError: 0 == 0
clang optimizes the undefined behavior into a simple assignment:
$ ~/usr/bin/clang --version
clang version 3.0 (tags/RELEASE_30/final)
Target: x86_64-unknown-freebsd9.0
Thread model: posix
$
$ cat read_null.c
#include stdio.h
int
main(void)
{
int *x = NULL, y;
y = *x;
printf(%d\n, y);
return 0;
}
$
$ ~/usr/bin/clang -Wall -O0 -g -o read_null read_null.c
$ ./read_null
Segmentation fault: 11 (core dumped)
$ ~/usr/bin/clang -Wall -O3 -g -o read_null read_null.c
$ ./read_null
0
--
components: Tests
messages: 152007
nosy: haypo, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: test_faulthandler: read_null test fails with current clang
type: behavior
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13874
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13874] test_faulthandler: read_null test fails with current clang
STINNER Victor victor.stin...@haypocalc.com added the comment: Can you try x = (int *)1; instead of x = NULL; ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13874 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13863] import.c sometimes generates incorrect timestamps on Windows + NTFS
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13863 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13863] import.c sometimes generates incorrect timestamps on Windows + NTFS
Antoine Pitrou pit...@free.fr added the comment: Hmm, interesting. This is exactly what happened recently when debugging pyc timestamp issues under Windows: http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%202.7/builds/1204/steps/test/logs/stdio Some decoding of the above crash: - the test would set the .py file's timestamps to 2**33 - this is truncated (module 2**32) and therefore should become 0 in the .pyc file's embedded timestamp - in reality, the .pyc file's embedded timestamps is equal to 4294963696. Which is 2**32 - 3600. As a sidenote, we don't have any tests that the pyc file is re-used when it is fresh enough. Perhaps by running an interpreter in a subprocess with -v we could examine the verbose messages printed out in import.c. It seems as though the correct fix would be to use something like GetFileInformationByHandle in place of the fstat calls in import.c. We must probably also replace the stat() call (through _Py_stat) with GetFileAttributesEx, or make _Py_stat re-use GetFileAttributesEx. -- components: +Windows nosy: +brian.curtin, pitrou, tim.golden priority: normal - high stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13863 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13875] cmd: no user documentation
New submission from anatoly techtonik techto...@gmail.com: http://docs.python.org/library/cmd.html# Documentation for cmd module is poor to explain the value of this module to users. Intro is too abstract - phrase simple framework for writing line-oriented command interpreters doesn't mean much. Perhaps word interactive is missing? So, there is no part explaining the what cmd does exactly (intro fails) and no part explaining the main principle - How exactly does this framework allows to do this in a simple way? (I guess reference part under 'Cmd objects - Cmd.cmdloop([intro]) - p[4]` does that, but it is not the place you'd usually expect this info. At the very least what could be done is a link to Doug's tutorial http://www.doughellmann.com/PyMOTW/cmd/ -- assignee: docs@python components: Documentation messages: 152010 nosy: docs@python, techtonik priority: normal severity: normal status: open title: cmd: no user documentation ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13875 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13874] test_faulthandler: read_null test fails with current clang
Stefan Krah stefan-use...@bytereef.org added the comment: STINNER Victor rep...@bugs.python.org wrote: Can you try x = (int *)1; instead of x = NULL; ? This works. - I must say that I find this new behavior of clang slightly dangerous... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13874 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13876] Sporadic failure in test_socket
New submission from Nadeem Vawda nadeem.va...@gmail.com: When running the test suite, I occasionally get the following failure: ERROR: testRecvmsgEOF (test.test_socket.RecvmsgSCTPStreamTest) -- Traceback (most recent call last): File /home/nadeem/code/src/cpython/def/Lib/test/test_socket.py, line 2187, in testRecvmsgEOF msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, 1024) File /home/nadeem/code/src/cpython/def/Lib/test/test_socket.py, line 1678, in doRecvmsg result = sock.recvmsg(bufsize, *args) OSError: [Errno 107] Transport endpoint is not connected The machine in question is running Ubuntu 11.10 64-bit. I haven't seen anything similar on any of the buildbots. -- messages: 152012 nosy: nadeem.vawda priority: normal severity: normal stage: needs patch status: open title: Sporadic failure in test_socket type: behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13876 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13875] cmd: no user documentation
R. David Murray rdmur...@bitdance.com added the comment: Well, since it isn't limited to interactive use, I don't think 'interactive' is missing. MOTW links are a more global issue that was discussion on python-dev (I forget the outcome, but I think it was no). I don't see anything that needs done here, but if you want to suggest a patch for consideration, feel free. -- nosy: +r.david.murray priority: normal - low resolution: - works for me status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13875 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13875] cmd: no user documentation
anatoly techtonik techto...@gmail.com added the comment: What do you mean by saying it is not limited for interactive use? I thought it is used to provide command prompt for typing commands. What other use cases does it support? -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13875 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13840] create_string_buffer rejects str init_or_size parameter
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset be9d02536a81 by Meador Inge in branch '3.2': - Issue #13840: Fix ctypes.create_string_buffer exception message and docs. http://hg.python.org/cpython/rev/be9d02536a81 New changeset 52f68c95e025 by Meador Inge in branch 'default': - Issue #13840: Fix ctypes.create_string_buffer exception message and docs. http://hg.python.org/cpython/rev/52f68c95e025 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13840 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13840] create_string_buffer rejects str init_or_size parameter
Meador Inge mead...@gmail.com added the comment: I just fixed the docs and error message for now. I might revisit the ASCII decoding later. Thanks for the bug report Vincent. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13840 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13875] cmd: no user documentation
R. David Murray rdmur...@bitdance.com added the comment: You can feed a cmd driven interface from stdin or via cmd.onecmd. However, I agree that the intended and primary use case is interactive. There wouldn't be much point in using cmd if the primary intent of your program wasn't interactive. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13875 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1003195] segfault when running smtplib example
Jon Bringhurst j...@bringhurst.org added the comment:
I just ran into this while using the smtplib example on:
2.6 (r26:66714, Jan 17 2012, 11:02:11)
GCC 4.1.2 20080704 (Red Hat 4.1.2-44)
Running the program simply gives a Segmentation Fault (core dumped)
Running it under gdb...
[Thread debugging using libthread_db enabled]
[New Thread 0x2b0257007b80 (LWP 2567)]
Program received signal SIGSEGV, Segmentation fault.
PyEval_EvalFrameEx (f=0x17701d00, throwflag=value optimized out) at
Python/ceval.c:4342
4342if (!PyDict_Check(gobals)) {
--
nosy: +Jon.Bringhurst
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1003195
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1003195] segfault when running smtplib example
Changes by Jon Bringhurst j...@bringhurst.org: -- type: - crash versions: +Python 2.6 -Python 2.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1003195 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8828] Atomic function to rename a file
Antoine Pitrou pit...@free.fr added the comment: Here is a patch adding os.replace(). -- keywords: +patch stage: needs patch - patch review Added file: http://bugs.python.org/file24328/osreplace.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8828 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13877] segfault when running smtplib example
New submission from Jon Bringhurst j...@bringhurst.org:
I just ran into this while using the smtplib example on:
2.6 (r26:66714, Jan 17 2012, 11:02:11)
GCC 4.1.2 20080704 (Red Hat 4.1.2-44)
Running the program simply gives a Segmentation Fault (core dumped)
Running it under gdb...
[Thread debugging using libthread_db enabled]
[New Thread 0x2b0257007b80 (LWP 2567)]
Program received signal SIGSEGV, Segmentation fault.
PyEval_EvalFrameEx (f=0x17701d00, throwflag=value optimized out) at
Python/ceval.c:4342
4342if (!PyDict_Check(gobals)) {
See (permanently closed?) similar bug at:
http://bugs.python.org/issue1003195
--
components: Interpreter Core
messages: 152020
nosy: Jon.Bringhurst
priority: normal
severity: normal
status: open
title: segfault when running smtplib example
type: crash
versions: Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13877
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13877] segfault when running smtplib example
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Do you have a more complete traceback by any chance? Also, does the New Thread... message indicate that a new thread is created? Why? This is not what I see here. -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13877 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13878] test_sched failures on Windows buildbot
New submission from Nadeem Vawda nadeem.va...@gmail.com:
http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/4072/steps/test/logs/stdio:
FAIL: test_enter (test.test_sched.TestCase)
--
Traceback (most recent call last):
File D:\Buildslave\3.x.moore-windows\build\lib\test\test_sched.py, line
18, in test_enter
self.assertEqual(l, [0.01, 0.02, 0.03, 0.04, 0.05])
AssertionError: Lists differ: [0.01, 0.02, 0.03, 0.05, 0.04] != [0.01,
0.02, 0.03, 0.04, 0.05]
First differing element 3:
0.05
0.04
- [0.01, 0.02, 0.03, 0.05, 0.04]
?--
+ [0.01, 0.02, 0.03, 0.04, 0.05]
?++
http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/4062/steps/test/logs/stdio:
FAIL: test_queue (test.test_sched.TestCase)
--
Traceback (most recent call last):
File D:\Buildslave\3.x.moore-windows\build\lib\test\test_sched.py, line
74, in test_queue
self.assertEqual(list(scheduler.queue), [e1, e2, e3, e4, e5])
AssertionError: Lists differ: [Event(time=1327366698.525, pr... !=
[Event(time=1327366698.525, pr...
First differing element 3:
Event(time=1327366698.565, priority=1, action=function
TestCase.test_queue.locals.lambda at 0x03419158, argument=[], kwargs={})
Event(time=1327366698.570, priority=1, action=function
TestCase.test_queue.locals.lambda at 0x03419158, argument=[], kwargs={})
Diff is 1268 characters long. Set self.maxDiff to None to see it.
--
messages: 152022
nosy: giampaolo.rodola, nadeem.vawda
priority: normal
severity: normal
stage: needs patch
status: open
title: test_sched failures on Windows buildbot
type: behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13878
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13878] test_sched failures on Windows buildbot
Nadeem Vawda nadeem.va...@gmail.com added the comment: Oops, those links should be: http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/4072/steps/test/logs/stdio and: http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/4062/steps/test/logs/stdio -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13878 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13879] Argparse does not support subparser aliases in 2.7
New submission from Tim Willis schadenfreude...@gmail.com: Argparse documentation in 2.7 indicates support for an 'aliases' kwarg. (Fourth example down from http://docs.python.org/dev/library/argparse.html#sub-commands) While aliases work as expected in 3.2, use in 2.7 results in TypeError: __init__() got an unexpected keyword argument 'aliases' -- components: Library (Lib) messages: 152024 nosy: Tim.Willis priority: normal severity: normal status: open title: Argparse does not support subparser aliases in 2.7 type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13879 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13876] Sporadic failure in test_socket
Changes by Ross Lagerwall rosslagerw...@gmail.com: -- nosy: +rosslagerwall ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13876 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13874] test_faulthandler: read_null test fails with current clang
STINNER Victor victor.stin...@haypocalc.com added the comment: There was a similar bug which was declared as a vulnerability in the Linux kernel: http://isc.sans.edu/diary.html?storyid=6820 GCC has an option to disable this optimization: -fno-delete-null-pointer-checks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13874 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10580] Installer sentence in bold
Boštjan Mejak bostjan.me...@gmail.com added the comment: After more than a year the patch is finally made. Can someone please applies this patch and closes this issue report? Thanks. -- keywords: +patch versions: +Python 3.3 Added file: http://bugs.python.org/file24329/issue10580.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10580 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13880] pydoc -k throws AssertionError: distutils has already been patched by class py2exe.Distribution at 0x0000000005987408
New submission from __KFL__ luke...@gmail.com: Pydoc fails on the following exception. There is a mail discussing it: http://mail.python.org/pipermail/python-list/2009-December/1230790.html C:\Python27\Libpydoc -k file ... ... Traceback (most recent call last): File C:\Python27\Lib\pydoc.py, line 2338, in module if __name__ == '__main__': cli() File C:\Python27\Lib\pydoc.py, line 2277, in cli apropos(val) File C:\Python27\Lib\pydoc.py, line 1974, in apropos ModuleScanner().run(callback, key) File C:\Python27\Lib\pydoc.py, line 1939, in run for importer, modname, ispkg in pkgutil.walk_packages(onerror=onerror): File C:\Python27\Lib\pkgutil.py, line 110, in walk_packages __import__(name) File C:\Python27\lib\site-packages\pypm\__init__.py, line 22, in module import setuptools File C:\Python27\lib\site-packages\setuptools\__init__.py, line 2, in module from setuptools.extension import Extension, Library File C:\Python27\lib\site-packages\setuptools\extension.py, line 2, in module from setuptools.dist import _get_unpatched File C:\Python27\lib\site-packages\setuptools\dist.py, line 28, in module _Distribution = _get_unpatched(_Distribution) File C:\Python27\lib\site-packages\setuptools\dist.py, line 24, in _get_unpatched distutils has already been patched by %r % cls AssertionError: distutils has already been patched by class py2exe.Distribution at 0x05987408 -- messages: 152027 nosy: __KFL__ priority: normal severity: normal status: open title: pydoc -k throws AssertionError: distutils has already been patched by class py2exe.Distribution at 0x05987408 type: crash versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13880 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13455] Reorganize tracker docs in the devguide
Terry J. Reedy tjre...@udel.edu added the comment: Antoine, what reference other than the devguide are you referring to? If you keep info I need out of the devguide, where am I supposed to find it? python.org/dev now redirects to python.org/devguide. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13455 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13881] Stream encoder for zlib_codec doesn't use the incremental encoder
New submission from Andrew McNabb amcn...@mcnabbs.org:
The stream encoder for the zlib_codec doesn't use the incremental encoder, so
it has limited usefulness in practice. This is easiest to show with an example.
Here is the behavior with the stream encoder:
filelike = io.BytesIO()
wrapped = codecs.getwriter('zlib_codec')(filelike)
wrapped.write(b'hello')
filelike.getvalue()
b'x\x9c\xab\x00\x00\x00y\x00y'
wrapped.write(b'x')
filelike.getvalue()
b'x\x9c\xab\x00\x00\x00y\x00yx\x9c\xab\x00\x00\x00y\x00y'
However, this is the behavior of the incremental encoder:
ienc = codecs.getincrementalencoder('zlib_codec')()
ienc.encode(b'x')
b'x\x9c'
ienc.encode(b'x', final=True)
b'\xab\xa8\x00\x00\x01j\x00\xf1'
The stream encoder is apparently encoding each write as an individual block,
but the incremental encoder buffers until it gets a block that's large enough
to be meaningfully compressed.
Fixing this may require addressing a separate issue with stream encoders.
Unlike with the GzipFile module, closing a stream encoder closes the underlying
file. If this underlying file is a BytesIO, then closing makes it free its
buffer, making it impossible to get at the completed file.
--
components: IO
messages: 152029
nosy: amcnabb
priority: normal
severity: normal
status: open
title: Stream encoder for zlib_codec doesn't use the incremental encoder
type: behavior
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13881
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Martin v. Löwis mar...@v.loewis.de added the comment: I'd like to propose an entirely different approach: use AVL trees for colliding strings, for dictionaries containing only unicode or byte strings. A prototype for this is in http://hg.python.org/sandbox/loewis/branches#avl It is not fully working yet, but I'm now confident that this is a feasible approach. It has the following advantages over the alternatives: - performance in case of collisions is O(log(N)), where N is the number of colliding keys - no new exceptions are raised, except for MemoryError if it runs out of memory for allocating nodes in the tree - the hash values do not change - the dictionary order does not change as long as no keys collide on hash values (which for all practical purposes should mean that the dictionary order does not change in all places where it matters) -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13882] Add format argument for time.time(), time.clock(), ... to get a timestamp as a Decimal object
New submission from STINNER Victor victor.stin...@haypocalc.com:
Attached patch adds an optional format argument to time.time(), time.clock(),
time.wallclock(), time.clock_gettime() and time.clock_getres() to get the
timestamp as a different format. By default, the float type is still used, but
it will be possible to pass format to get the timestamp as a decimal.Decimal
object.
Some advantages of using decimal.Decimal instead of float:
- no loss of precision during conversion from base 2 to base 10 (converting
the float to a string)
- the resolution of the clock is stored in the Decimal object
- for big number, Decimal doesn't loose precision
Using Decimal is also motivated by the fact than Python 3.3 has now access to
clock having a resolution of 1 nanosecond: clock_gettime(CLOCK_REALTIME). Well,
it doesn't mean that the clock is accurate, but Python should not loose
precision just because it uses floatting point instead of integers.
About the API: I chose to add a string argument to allow maybe later to support
user defined formats, or at least add new builtin formats. For example, someone
proposed 128 bits float in the issue #11457.
--
The internal format is:
typedef struct {
time_t seconds;
/* floatpart can be zero */
size_t floatpart;
/* divisor cannot be zero */
size_t divisor;
/* log10 of the clock resoltion, the real resolution is 10^resolution,
resolution is in range [-9; 0] */
int resolution;
} _PyTime_t;
I don't know if size_t is big enough to store any floatpart value:
time.clock() uses a LARGE_INTEGER internally. I tested my patch on Linux 32 and
64 bits, but not yet on Windows.
The internal function encoding a timestamp to Decimal caches the resolution
objects (10^resolution, common clock resolutions: 10^-6, 10^-9) in a dict, and
a Context object.
I computed that 22 decimal digits should be enough to compute a timestamp of
10,000 years. Extract of my patch:
Use 12 decimal digits to store 10,000 years in seconds + 9 decimal digits for
the floating part in nanoseconds + 1 decimal digit to round correctly
str(int(3600*24*365.25*1))
'31557600'
len(str(int(3600*24*365.25*1)))
12
--
See also the issue #11457 which is linked to this topic, but not exactly the
same because it concerns a low level function (os.stat()).
--
components: Library (Lib)
files: time_decimal-2.patch
keywords: patch
messages: 152031
nosy: belopolsky, haypo, loewis
priority: normal
severity: normal
status: open
title: Add format argument for time.time(), time.clock(), ... to get a
timestamp as a Decimal object
versions: Python 3.3
Added file: http://bugs.python.org/file24330/time_decimal-2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13882
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13882] Add format argument for time.time(), time.clock(), ... to get a timestamp as a Decimal object
STINNER Victor victor.stin...@haypocalc.com added the comment:
Some examples of the API:
$ ./python
Python 3.3.0a0 (default:52f68c95e025+, Jan 26 2012, 21:54:31)
import time
time.time()
1327611705.948446
time.time('decimal')
Decimal('1327611708.988419')
t1=time.time('decimal'); t2=time.time('decimal'); t2-t1
Decimal('0.000550')
t1=time.time('float'); t2=time.time('float'); t2-t1
5.9604644775390625e-06
time.clock_gettime(time.CLOCK_MONOTONIC, 'decimal')
Decimal('1211833.389740312')
time.clock_getres(time.CLOCK_MONOTONIC, 'decimal')
Decimal('1E-9')
time.clock()
0.12
time.clock('decimal')
Decimal('0.12')
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13882
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Alex Gaynor alex.gay...@gmail.com added the comment: On Thu, Jan 26, 2012 at 4:00 PM, Martin v. Löwis rep...@bugs.python.orgwrote: Martin v. Löwis mar...@v.loewis.de added the comment: I'd like to propose an entirely different approach: use AVL trees for colliding strings, for dictionaries containing only unicode or byte strings. A prototype for this is in http://hg.python.org/sandbox/loewis/branches#avl It is not fully working yet, but I'm now confident that this is a feasible approach. It has the following advantages over the alternatives: - performance in case of collisions is O(log(N)), where N is the number of colliding keys - no new exceptions are raised, except for MemoryError if it runs out of memory for allocating nodes in the tree - the hash values do not change - the dictionary order does not change as long as no keys collide on hash values (which for all practical purposes should mean that the dictionary order does not change in all places where it matters) -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ Martin, What happens if, instead of putting strings in a dictionary directly, I have them wrapped in something. For example, the classes Antoine and I pasted early. These define hash and equal as being strings, but don't have an ordering. Alex -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13883] PYTHONCASEOK docs mistakenly says it is limited to Windows
New submission from Brett Cannon br...@python.org: The docs for PYTHONCASEOK say it is limited to Windows, but in actuality in Python 3.x it applies to both Windows (including cygwin) and OS X. On Python 2.7 it applies to those plus RISCOS OS/2. -- assignee: docs@python components: Documentation messages: 152034 nosy: brett.cannon, docs@python priority: normal severity: normal stage: needs patch status: open title: PYTHONCASEOK docs mistakenly says it is limited to Windows versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13883 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13882] Add format argument for time.time(), time.clock(), ... to get a timestamp as a Decimal object
STINNER Victor victor.stin...@haypocalc.com added the comment: Windows code (win32_clock) was wrong in time_decimal-2.patch: it is fixed in patch version 3. Some tests on Windows made me realize that time.time() has a resolution of 1 millisecond (10^-3) and not of a microsecond (10^-6) on Windows! It is time to use GetSystemTimeAsFileTime! = see issue #13845. -- Added file: http://bugs.python.org/file24331/time_decimal-3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13882 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13845] Use GetSystemTimeAsFileTime() to get a resolution of 100 ns on Windows
STINNER Victor victor.stin...@haypocalc.com added the comment: Using the patch of #13882, I realize that time.time() has a resolution of 1 millisecond (10^-3) and not of a microsecond (10^-6) on Windows! Windows doesn't provide gettimeofday(). Using GetSystemTimeAsFileTime() would provide a much better resolution! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13845 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Dave Malcolm dmalc...@redhat.com added the comment:
On Thu, 2012-01-26 at 21:04 +, Alex Gaynor wrote:
Alex Gaynor alex.gay...@gmail.com added the comment:
On Thu, Jan 26, 2012 at 4:00 PM, Martin v. Löwis
rep...@bugs.python.orgwrote:
Martin v. Löwis mar...@v.loewis.de added the comment:
I'd like to propose an entirely different approach: use AVL trees for
colliding strings, for dictionaries containing only unicode or byte strings.
A prototype for this is in
http://hg.python.org/sandbox/loewis/branches#avl
It is not fully working yet, but I'm now confident that this is a feasible
approach.
It has the following advantages over the alternatives:
- performance in case of collisions is O(log(N)), where N is the number of
colliding keys
- no new exceptions are raised, except for MemoryError if it runs out of
memory for allocating nodes in the tree
- the hash values do not change
- the dictionary order does not change as long as no keys collide on hash
values (which for all practical purposes should mean that the dictionary
order does not change in all places where it matters)
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13703
___
Martin,
What happens if, instead of putting strings in a dictionary directly, I
have them wrapped in something. For example, the classes Antoine and I
pasted early. These define hash and equal as being strings, but don't have
an ordering.
[Obviously I'm not Martin, but his idea really interests me]
Looking at:
http://hg.python.org/sandbox/loewis/file/58be269aa0b1/Objects/dictobject.c#l517
as soon as any key insertion or lookup occurs where the key isn't
exactly one of the correct types, the dict flattens any AVL trees back
into the regular flat representation (and switches to lookdict for
ma_lookup), analogous to the existing ma_lookup transition on dicts.
From my reading of the code, if you have a dict purely of bytes/str,
collisions on a hash value lead to the PyDictEntry's me_key being set to
an AVL tree. All users of the ma_lookup callback within dictobject.c
check to see if they're getting such PyDictEntry back. If they are,
they call into the tree, which leads to TREE_FIND(), TREE_INSERT() and
TREE_DELETE() invocations as appropriate; ultimately, the AVL macros
call back to within node_cmp():
PyObject_Compare(left-key, right-key)
[Martin, I'm sorry if I got this wrong]
So *if* I'm reading the code correctly, it might be possible to
generalize it from {str, bytes} to any set of types within which
ordering and equality checking of instances from any type is sane,
which loosely, would seem to be: that we can reliably compare all
objects from any type within the set, so that we can use the comparisons
to perform a search to hone in on a pair of keys that compare as
equal, without any chance of raising exceptions, or missing a valid
chance for two objects to be equal etc.
I suspect that you can't plug arbitrary user-defined types into it,
since there's no way to guarantee that ordering and comparison work in
the ways that the AVL lookup requires.
But I could be misreading Martin's code. [thinking aloud, if a pair of
objects don't implement comparison at the PyObject_Compare level, is it
possible to instead simply compare the addresses of the objects? I
don't think so, since you have a custom equality implementation in your
UDT, but maybe I've missed something?]
Going higher-level, I feel that there are plenty of attacks against
pure-str/bytes dicts, and having protection against them is worthwhile -
even if there's no direct way to use it to protect the use-case you
describe.
Hope this is helpful
Dave
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13703
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13666] datetime documentation typos
Stephen Kelly steve...@gmail.com added the comment: There are actually other bugs in the same code example: ... def __init__(self): # DST starts last Sunday in March ... d = datetime(dt.year, 4, 1) # ends last Sunday in October ... self.dston = d - timedelta(days=d.weekday() + 1) ... d = datetime(dt.year, 11, 1) ... self.dstoff = d - timedelta(days=d.weekday() + 1) where does dt come from? this fragment should be in the implementation of dst (in both the GMT1 and GMT2 classes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13666 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Martin v. Löwis mar...@v.loewis.de added the comment: as soon as any key insertion or lookup occurs where the key isn't exactly one of the correct types, the dict flattens any AVL trees back into the regular flat representation (and switches to lookdict for ma_lookup), analogous to the existing ma_lookup transition on dicts. Correct. TREE_DELETE() invocations as appropriate; ultimately, the AVL macros call back to within node_cmp(): PyObject_Compare(left-key, right-key) Correct. I suspect that you can't plug arbitrary user-defined types into it, since there's no way to guarantee that ordering and comparison work in the ways that the AVL lookup requires. That's all true. It would be desirable to automatically determine which types also support total order in addition to hashing, alas, there is currently no protocol for it. On the contrary, Python has moved away of assuming that all objects form a total order. [thinking aloud, if a pair of objects don't implement comparison at the PyObject_Compare level, is it possible to instead simply compare the addresses of the objects? 2.x has an elaborate logic to provide a total order on objects. It took the entire 1.x and 2.x series to fix issues with that order, only to recognize that it is not feasible to provide one - hence the introduction of rich comparisons and the omission of cmp in 3.x. For the dictionary, using addresses does not work: the order of objects needs to be consistent with equality (i.e. x y and x == y must not simultaneously hold, as must x == y and y z imply that also x z, else the tree lookup won't find the equal keys). Going higher-level, I feel that there are plenty of attacks against pure-str/bytes dicts, and having protection against them is worthwhile - even if there's no direct way to use it to protect the use-case you describe. Indeed. This issue doesn't need to fix *all* possible attacks using hash collisions. Instead, it needs to cover the common case, and it needs to allow users to rewrite their code so that they can protect it against this family of attacks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Martin v. Löwis mar...@v.loewis.de added the comment: What happens if, instead of putting strings in a dictionary directly, I have them wrapped in something. For example, the classes Antoine and I pasted early. These define hash and equal as being strings, but don't have an ordering. As Dave has analysed: the dictionary falls back to the current implementation. So wrt. your question Is it still able to find the value?, the answer is Yes, certainly. It's fully backwackwards compatible, with the limitation in msg152030 (i.e. the dictionary order may change for dictionaries with string keys colliding in their hash() values). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Alex Gaynor alex.gay...@gmail.com added the comment: On Thu, Jan 26, 2012 at 5:42 PM, Martin v. Löwis rep...@bugs.python.orgwrote: Martin v. Löwis mar...@v.loewis.de added the comment: What happens if, instead of putting strings in a dictionary directly, I have them wrapped in something. For example, the classes Antoine and I pasted early. These define hash and equal as being strings, but don't have an ordering. As Dave has analysed: the dictionary falls back to the current implementation. So wrt. your question Is it still able to find the value?, the answer is Yes, certainly. It's fully backwackwards compatible, with the limitation in msg152030 (i.e. the dictionary order may change for dictionaries with string keys colliding in their hash() values). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ But using non-__builtin__.str objects (such as UserString) would expose the user to an attack? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
Ethan Furman et...@stoneleaf.us added the comment: Okay, here is a patch implementing the 'raise ... from None' method. All critiques appreciated (especially if they include links to learn from!). -- keywords: +patch Added file: http://bugs.python.org/file24332/raise_from_none.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Martin v. Löwis mar...@v.loewis.de added the comment: But using non-__builtin__.str objects (such as UserString) would expose the user to an attack? Not necessarily: only if they use these strings as dictionary keys, and only if they do so in contexts where arbitrary user input is consumed. In these cases, users need to rewrite their code to replace the keys. Using dictionary wrappers (such as UserDict), this is possible using only local changes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13847] Catch time(), ftime(), localtime() and clock() errors
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 9ee4a104e33d by Victor Stinner in branch 'default': Issue #13847: time.localtime() and time.gmtime() now raise an OSError instead http://hg.python.org/cpython/rev/9ee4a104e33d -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
Ethan Furman et...@stoneleaf.us added the comment: I went with raise ... from None instead of raise as ... because there seemed to me more support for 'from None' on python-dev, possible confusion with 'raise as', and 'from None' follows the existing systax of raise SomeError() from SomeOtherError() -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Alex Gaynor alex.gay...@gmail.com added the comment: I'm sorry then, but I'm a little confused. I think we pretty clearly established earlier that requiring users to make changes anywhere they stored user data would be dangerous, because these locations are often in libraries or other places where the code creating and modifying the dictionary has no idea it's user data in it. The proposed AVL solution fails if it requires users to fundamentally restructure their data depending on it's origin. We have solution that is known to work in all cases: hash randomization. There were three discussed issues with it: a) Code assuming a stable ordering to dictionaries b) Code assuming hashes were stable across runs. c) Code reimplementing the hashing algorithm of a core datatype that is now randomized. I don't think any of these are realistic issues the way doesn't protect all cases is. (a) was never a documented, or intended property, indeed it breaks all the time, if you insert keys in the wrong order, use a different platform, or anything else can change. (b) For the same reasons code relying on (b) only worked if you didn't change anything, and in practice I'm convinced neither of these were common (if ever existed). Finally (c), while it's a concern, I've reviewed Django, SQLAlchemy, PyPy, and the stdlib: there is only one place where compatibility with a core-hash is attempted, decimal.Decimal. In summary, I think the case against hash-randomization has been seriously overstated, and in no way is more dangerous than having a solution that fails to solve the problem comprehensively. Further, I think it is imperative that we reach a consensus on this quickly, as the only reason this hasn't been widely exploited yet is the lack of availability of the data, when it becomes available I firmly expect just about every high profile Python site on the internet (of which there are many) to be attacked. On Thu, Jan 26, 2012 at 6:03 PM, Martin v. Löwis rep...@bugs.python.orgwrote: Martin v. Löwis mar...@v.loewis.de added the comment: But using non-__builtin__.str objects (such as UserString) would expose the user to an attack? Not necessarily: only if they use these strings as dictionary keys, and only if they do so in contexts where arbitrary user input is consumed. In these cases, users need to rewrite their code to replace the keys. Using dictionary wrappers (such as UserDict), this is possible using only local changes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13873] SIGBUS in test_zlib on Debian bigmem buildbot
Torsten Landschoff t.landsch...@gmx.net added the comment: I tried to reproduce this crash on my desktop system. AMD64, 8 GB RAM (only) and on Debian unstable from today. Testing the exact same Python version (hg update d2cf8a34ddf90fb1bc8938de0f736694e61f73fa) the test passes just fine here... -- nosy: +torsten ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13873 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13883] PYTHONCASEOK docs mistakenly says it is limited to Windows
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 524795e8abe1 by Brett Cannon in branch '3.2': Issue #13883: Document all platforms PYTHONCASEOK works on. http://hg.python.org/cpython/rev/524795e8abe1 New changeset 0f00010c88f0 by Brett Cannon in branch 'default': Issue #13883: PYTHONCASEOK also works with OS X. http://hg.python.org/cpython/rev/0f00010c88f0 New changeset f18662285248 by Brett Cannon in branch '2.7': Issue #13883: Document all platforms PYTHONCASEOK works on. http://hg.python.org/cpython/rev/f18662285248 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13883 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13883] PYTHONCASEOK docs mistakenly says it is limited to Windows
Changes by Brett Cannon br...@python.org: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13883 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13847] Catch time(), ftime(), localtime() and clock() errors
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 94b7eb09d0b3 by Victor Stinner in branch 'default': Issue #13847: time.clock() now raises a RuntimeError if the processor time used http://hg.python.org/cpython/rev/94b7eb09d0b3 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13884] IDLE 2.6.5 Recent Files undocks
New submission from Tim McGreevy mcgrete@gmail.com: When selecting from menu: File -- Recent Files the 'Recent Files' dropdown list undocks from the IDLE gui / File dropdown list. Even after selecting a past file, it remains open until closed manually. Ubuntu LUCID amd64 IDLE 2.6.5 TK version 8.5 All installed using Ubuntu supported PPA (Synaptic) After closing 'Recent Files' subwindow, problem no longer persists until IDLE is terminated and restarted. -- components: IDLE files: IDLE2.6.5_RecentFilesUndocked.png messages: 152050 nosy: mcgrete priority: normal severity: normal status: open title: IDLE 2.6.5 Recent Files undocks versions: Python 2.6 Added file: http://bugs.python.org/file24333/IDLE2.6.5_RecentFilesUndocked.png ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13884 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Martin v. Löwis mar...@v.loewis.de added the comment: I'm sorry then, but I'm a little confused. I think we pretty clearly established earlier that requiring users to make changes anywhere they stored user data would be dangerous, because these locations are often in libraries or other places where the code creating and modifying the dictionary has no idea it's user data in it. I don't consider that established for the specific case of string-like objects. Users can easily determine whether they use string-like objects, and if so, in what places, and what data gets put into them. The proposed AVL solution fails if it requires users to fundamentally restructure their data depending on it's origin. It doesn't fail at all. User don't *have* to restructure their code, let alone fundamentally. Their code may currently be vulnerable, yet not use string-like objects at all. With the proposed solution, such code will be fixed for good. It's true that the solution does not fix all cases of the vulnerability, but neither does any other proposed solution. We have solution that is known to work in all cases: hash randomization. Well, you *believe* that it fixes the problem, even though it actually may not, assuming an attacker can somehow reproduce the hash function. There were three discussed issues with it: a) Code assuming a stable ordering to dictionaries b) Code assuming hashes were stable across runs. c) Code reimplementing the hashing algorithm of a core datatype that is now randomized. I don't think any of these are realistic issues I'm fairly certain that code will break in massive ways, despite any argumentation that it should not. The question really is Do we break code in a massive way, or do we fix the vulnerability for most users with no code breakage? I clearly value compatibility much higher than 100% protection against a DoS-style attack (which has many other forms of protecting against available also). (a) was never a documented, or intended property, indeed it breaks all the time, if you insert keys in the wrong order, use a different platform, or anything else can change. Still, a lot of code relies on dictionary order, and successfully so, in practice. Practicality beats purity. (b) For the same reasons code relying on (b) only worked if you didn't change anything That's not true. You cannot practically change the way string hashing works other than by changing the interpreter source. Hashes *are* currently stable across runs. and in practice I'm convinced neither of these were common (if ever existed). Are you willing to bet the trust people have in Python's bug fix policies on that? I'm not. In summary, I think the case against hash-randomization has been seriously overstated, and in no way is more dangerous than having a solution that fails to solve the problem comprehensively. Further, I think it is imperative that we reach a consensus on this quickly Well, I cannot be part of a consensus that involves massive code breakage in a bug fix release. Lacking consensus, either the release managers or the BDFL will have to pronounce. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13847] Catch time(), ftime(), localtime() and clock() errors
STINNER Victor victor.stin...@haypocalc.com added the comment: I added tests on localtime() and clock(). I read more carefully time(), ftime() and gettimeofday() manpage: it is not possible that they fail if the argument is an invalid pointer, the current code is correct. I don't want to backport changes because they are incompatible. -- There is a failure on FreeBSD 8.2: == FAIL: test_localtime_failure (test.test_time.TimeTestCase) -- Traceback (most recent call last): File /usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_time.py, line 358, in test_localtime_failure self.assertRaises(OSError, time.localtime, invalid_time_t) AssertionError: OSError not raised by localtime http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/1746/steps/test/logs/stdio test_localtime_failure() should be removed or at least skipped on FreeBSD, except if someone knows another invalid time_t value on this platform. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13847] Catch time(), ftime(), localtime() and clock() errors
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 516d42a6e518 by Victor Stinner in branch 'default': Issue #13847: Fix test_mktime(), time.localtime() now raises OSError http://hg.python.org/cpython/rev/516d42a6e518 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13884] IDLE 2.6.5 Recent Files undocks
Ezio Melotti ezio.melo...@gmail.com added the comment: Could you try with IDLE 2.7/3.2? -- nosy: +ezio.melotti, terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13884 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13847] Catch time(), ftime(), localtime() and clock() errors
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 856f0864437a by Victor Stinner in branch 'default': Issue #13847: Make test_localtime_failure() more robust http://hg.python.org/cpython/rev/856f0864437a -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13847] Catch time(), ftime(), localtime() and clock() errors
STINNER Victor victor.stin...@haypocalc.com added the comment: The issue should be done with the last commit. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Antoine Pitrou pit...@free.fr added the comment: There were three discussed issues with it: a) Code assuming a stable ordering to dictionaries b) Code assuming hashes were stable across runs. c) Code reimplementing the hashing algorithm of a core datatype that is now randomized. I don't think any of these are realistic issues I'm fairly certain that code will break in massive ways, despite any argumentation that it should not. The question really is Do we break code in a massive way, or do we fix the vulnerability for most users with no code breakage? I clearly value compatibility much higher than 100% protection against a DoS-style attack (which has many other forms of protecting against available also). If I your read patch correctly, collisions will produce additional allocations of one distinct PyObject (i.e. AVL node) per colliding key. That's a pretty massive change in memory consumption for string dicts (and also in memory fragmentation and cache friendliness, probably). The performance effect in most situations is likely to be negative too, despite the better worst-case complexity. IMO that would be a rather controversial change for a feature release, let alone a bugfix or security release. It would be nice to have the release managers' opinions on this issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
Nick Coghlan ncogh...@gmail.com added the comment: 1. Any syntax change requires a PEP (and, IMO, any such PEP for this issue should get rejected: I don't consider this an important enough feature to deserve dedicated syntax. Others disagree, which is one of the reasons why a PEP is needed. The other, more important, reason is to ensure the new syntax is spec'ed out clearly and incorporated into the language reference for the benefit of other implementations in the event that it *does* get approved) 2. A change that *doesn't* need a PEP is to just adjust the implicit exception chaining such that __context__ doesn't get set automatically if it has already been set explicitly (it turns out handling this situation was an open question in PEP 3134, not a specificied behaviour). That way, this task can be handled using a utility function: def no_context(new_exc): new_exc.__context__ = None return new_exc def doXY (): # ... try: page = urlopen( someRequest ) except urllib.error.URLError as e: raise no_context(MyError( 'while doing XY', e )) # ... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13651] Improve redirection in urllib
tom kel tomke...@gmail.com added the comment: I changed the patch and made it a little bit better. -- versions: +Python 3.1, Python 3.4 -Python 2.7 Added file: http://bugs.python.org/file24334/2012-1-26.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13651 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Martin v. Löwis mar...@v.loewis.de added the comment: If I your read patch correctly, collisions will produce additional allocations of one distinct PyObject (i.e. AVL node) per colliding key. That's correct. That's a pretty massive change in memory consumption for string dicts (and also in memory fragmentation and cache friendliness, probably). That's not correct. It's not a massive change, as colliding hash values never happen in practice, unless you are being attacked, in which case it will be one additional PyObject for the set of all colliding keys (i.e. one object per possible hundreds of string objects). Even including the nodes of the tree (one per colliding node) is IMO a moderate increase in memory usage, in order to solve the vulnerability. It also doesn't impact memory fragmentation badly, as these objects are allocated using the Python small objects allocator. The performance effect in most situations is likely to be negative too, despite the better worst-case complexity. Compared to the status quo? Hardly. In all practical applications, collision never happens, so none of the extra code is ever exexcuted - except for AVL_Check invocations, which are a plain pointer comparison. IMO that would be a rather controversial change for a feature release, let alone a bugfix or security release. Apparently so, but it's not clear to me why that is. That change meets all criteria of a security fix release nicely, as opposed to the proposed changes to the hash function, which break existing code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
Ethan Furman et...@stoneleaf.us added the comment: 1. Any syntax change requires a PEP (and, IMO, any such PEP for this issue should get rejected: I don't consider this an important enough feature to deserve dedicated syntax. Others disagree, which is one of the reasons why a PEP is needed. The other, more important, reason is to ensure the new syntax is spec'ed out clearly and incorporated into the language reference for the benefit of other implementations in the event that it *does* get approved) I'm not sure why this would be a syntax change. We can already do try: 1/0 except ZeroDivisionError: raise ValueError() from MathError() to explicitly set the __cause__ and ignore the previous context. The only difference would allowing 'None' to mean 'no cause, discard previous context'. 2. A change that *doesn't* need a PEP is to just adjust the implicit exception chaining such that __context__ doesn't get set automatically if it has already been set explicitly (it turns out handling this situation was an open question in PEP 3134, not a specificied behaviour). That way, this task can be handled using a utility function: def no_context(new_exc): new_exc.__context__ = None return new_exc def doXY (): # ... try: page = urlopen( someRequest ) except urllib.error.URLError as e: raise no_context(MyError( 'while doing XY', e )) This seems like a lot more work than just allowing None to mean none. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
Ethan Furman et...@stoneleaf.us added the comment: Nick Coghlan wrote: 1. Any syntax change requires a PEP PEP is on python-dev. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
Steven D'Aprano steve+pyt...@pearwood.info added the comment: Nick Coghlan wrote: Nick Coghlan ncogh...@gmail.com added the comment: 1. Any syntax change requires a PEP (and, IMO, any such PEP for this issue should get rejected: I don't consider this an important enough feature to deserve dedicated syntax. Others disagree, which is one of the reasons why a PEP is needed. The other, more important, reason is to ensure the new syntax is spec'ed out clearly and incorporated into the language reference for the benefit of other implementations in the event that it *does* get approved) This already has a PEP. This is an *explicitly* unresolved issue from the original PEP that introduced exception chaining in the first place. http://www.python.org/dev/peps/pep-3134/ I quote: Open Issue: Suppressing Context As written, this PEP makes it impossible to suppress '__context__', since setting exc.__context__ to None in an 'except' or 'finally' clause will only result in it being set again when exc is raised. With Ethan's patch, no new syntax is required. Since you can already say: raise exception from another_exception the syntax remains unchanged. There is an API change: currently another_exception must inherit from BaseException, with the patch it may also be None, but that doesn't change the syntax. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13847] Catch time(), ftime(), localtime() and clock() errors
STINNER Victor victor.stin...@haypocalc.com added the comment: There is still an error on Windows: == FAIL: test_localtime_failure (test.test_time.TimeTestCase) -- Traceback (most recent call last): File D:\Buildslave\3.x.moore-windows\build\lib\test\test_time.py, line 364, in test_localtime_failure self.assertRaises(OSError, time.gmtime, invalid_time_t) AssertionError: OSError not raised by gmtime http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/4074/steps/test/logs/stdio time.ctime() uses localtime() internally, whereas time.gmtime() doesn't. Another time should maybe be written (to test a different time_t value). Or remove completly the whole test because it is not reliable :-) -- resolution: fixed - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
Steven D'Aprano steve+pyt...@pearwood.info added the comment: [...] My comment has been overtaken by additional comments by Nick on the Python-Dev list. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Gregory P. Smith g...@krypto.org added the comment: But using non-__builtin__.str objects (such as UserString) would expose the user to an attack? Not necessarily: only if they use these strings as dictionary keys, and only if they do so in contexts where arbitrary user input is consumed. In these cases, users need to rewrite their code to replace the keys. Using dictionary wrappers (such as UserDict), this is possible using only local changes. Could the AVL tree approach be extended to apply to dictionaries containing keys of any single type that supports comparison? That approach would autodetect UserString or similar and support it properly. I expect that dictionaries with keys of more than one type to be very rare and highly unlikely when it comes to values generated directly via user input. (and on top of all of this I believe we're all settled on having per interpreter hash randomization _as well_ in 3.3; but this AVL tree approach is one nice option for a backport to fix the major vulnerability) -gps -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13884] IDLE 2.6.5 Recent Files undocks
Terry J. Reedy tjre...@udel.edu added the comment: IDLE has tear-off menus. From Help/IDLE Help: Click on the dotted line at the top of a menu to tear it off: a separate window containing the menu is created. This is a feature, not a bug. On 3.2.2, Win7, the Recent Files sub-menu cannot be torn off unless and until the File menu is torn off. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13884 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
