[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
Nick Coghlan added the comment: Issue 20942 now covers the spurious value in _frozen_importlib.__file__, leaving this free to cover the fact that importlib/__init__.py doesn't support freezing in 3.4.0. -- priority: deferred blocker - normal ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20884 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20098] email policy needs a mangle_from setting
Changes by Berker Peksag berker.pek...@gmail.com: -- stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20098 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4142] smtplib doesn't clear helo/ehlo flags on quit
Changes by Berker Peksag berker.pek...@gmail.com: -- stage: test needed - patch review versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4142 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20943] configparser - add 'getDict' function
New submission from Michael Müller: It would be nice to have a 'getDict' function in the configparser lib. Adding that function would be simply def getDict(self, *args): return dict([entry for entry in self.items(*args)]) inside the RawConfigParser class next to the other get* functions. -- components: Library (Lib) messages: 213721 nosy: Michael.Müller, lukasz.langa priority: normal severity: normal status: open title: configparser - add 'getDict' function type: enhancement versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20943 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20941] pytime.c:184 and pytime.c:218: runtime error, outside the range of representable values of type 'long'
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20941 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20827] IDLE : Display function argument list in ClassBrowser
Saimadhav Heblikar added the comment:
I have added a improved patch.
What this patch does:
1. resolves issue 1 of msg213193 - uses inspect. signature() instead of
inspect.getargspec.
2. resolves issue 2 of msg213193 - the module is imported only once per
ClassBrowser instance.
3. resolves issue 2 of msg21 - the classbrowser display is based on the
current EditorWindow text and not based on whats on disk. All changes to
reflect this have been made in ClassBrowser.py and pyclbr, therefore i did not
create a new issue.
4. resolves issue 1 of msg21 - though i feel there are better ways to do
this than this patch - which manually close and create a new ClassBrowser
instance
what this patch does NOT do:
1. the test_pyclbr fails after the proposed changes to pyclbr,(which is just
adding a new keyword argument to _readmodule,readmodule_ex. i have circled it
down to this.
the only other change to pyclbr is an extra if statement.)
i have tried to modify the tests to reflect the same, but to no avail. if you
can give me some hints on how to move forward, i'll be quick to implement the
tests.
here is the test error -
test_decorators (test.test_pyclbr.PyclbrTest) ... *** B
FAIL
test_easy (test.test_pyclbr.PyclbrTest) ... ok
test_issue_14798 (test.test_pyclbr.PyclbrTest) ... ok
test_others (test.test_pyclbr.PyclbrTest) ... *** BytesHeaderParser
FAIL
==
FAIL: test_decorators (test.test_pyclbr.PyclbrTest)
--
Traceback (most recent call last):
File /media/development/cpython/Lib/test/test_pyclbr.py, line 152, in
test_decorators
self.checkModule('test.pyclbr_input', ignore=['om'])
File /media/development/cpython/Lib/test/test_pyclbr.py, line 139, in
checkModule
self.assertHaskey(dict, name, ignore)
File /media/development/cpython/Lib/test/test_pyclbr.py, line 43, in
assertHaskey
self.assertIn(key, obj)
AssertionError: 'B' not found in {}
==
FAIL: test_others (test.test_pyclbr.PyclbrTest)
--
Traceback (most recent call last):
File /media/development/cpython/Lib/test/test_pyclbr.py, line 167, in
test_others
cm('email.parser')
File /media/development/cpython/Lib/test/test_pyclbr.py, line 139, in
checkModule
self.assertHaskey(dict, name, ignore)
File /media/development/cpython/Lib/test/test_pyclbr.py, line 43, in
assertHaskey
self.assertIn(key, obj)
AssertionError: 'BytesHeaderParser' not found in {}
--
Ran 4 tests in 15.437s
--
Added file: http://bugs.python.org/file34439/classbrowser-improvements-v2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20827
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20943] configparser - add 'getDict' function
R. David Murray added the comment: How is this different from myconfig['section']? -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20943 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17846] Building Python on Windows - Supplementary info
Kathleen Weaver added the comment: Why are you suggesting the use of Subversion? Why not stick with Mercurial? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17846 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17846] Building Python on Windows - Supplementary info
R. David Murray added the comment: Because some of the third party components for the windows built are still in a subversion repository. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17846 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20940] Test 239: buffer overflow in sock_recvmsg_guts
Charles-François Natali added the comment: It might be a different test triggering the buffer overflow, but the underlying cause is the same as #20937. -- nosy: +neologix resolution: - duplicate stage: - committed/rejected status: open - closed superseder: - test_socket: buffer overflow in sock_recvmsg_guts ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20940 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16123] IDLE - deprecate running without a subprocess
Terry J. Reedy added the comment: Every enhancement issue can be bumped to 3.5. -- versions: -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16123 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20944] Engineering Process Improvements
New submission from Jeffrey Walton: Python's code is crisp and sharp. From a software design perspective, I don't see a lot of room for improvement. However, looking at some of the issues flagged by Clang sanitizers and existing bug reports, I think the project has a couple of small opportunities for improvement in the engineering process. The small improvements have the potential for large payoffs, and could help take a mature code base to the next level. The improvements are not sexy, and they are often overlooked. The improvements are: (1) add instrumentation to the code; and (2) add scanning and analysis to the engineering process. To improve the code and engineering process to proactively hunt obscure and hard to find bugs, I would suggest three actionable items: * ASSERTions * Clang Santizers * Coverity Scans Placing measures to proactively hunt bugs will improve the code quality, and likely allow the project to drop `-fwrapv` and friends from compiler options (http://bugs.python.org/issue1621). ASSERTions == The code uses Posix's little assert on occasion. Posix assert is useless during development because it raise SIGABRT. Additionally, the code has minimal assertions, so assertions are not being utilized effectively. I think there is an opportunity to use a big ASSERT. The big ASSERT raises a SIGTRAP, and during development it will ensure the debugger snaps on an unexpected condition. The big ASSERT raises awareness where needed and allows the developers to continue handling on a negative code path. ASSERTs should be liberally sprinkled. That is, ASSERT parameters, return values and program state. Python is setup correctly with NDEBUG on Release builds, so the ASSERTs will be removed in production. With a full compliment of ASSERTs in place, the code will essential debug itself under most circumstances. In fact, I often pitch it as self-debugging code to management. Self debugging code has three benefits. First, self debugging code is effectively a force multiplier, and it allows fewer developers to maintain a larger code base. Second, it allows non-senior members to effectively contribute to the project. Google Summer of Code interns and junior developers could be effective team members since the ASSERTs will often guide them in tracing problems. Third, ASSERTs free up time for other endeavors, like adding features to Python or watching football. Clang Sanitizers === I think the code base would benefit from regular Clang sanitizer scans. From initial scanning and testing, I believe Clang and its sanitizers has shown its value. The sanitizers perform dynamic analysis. The issues flagged are almost always real issues, and require almost no filtering due to false positives. The analysis should include the undefined behavior sanitizer (-fsanitize=undefined) and the address sanitizer (-fsanitize=address). There are more sanitizers available, and they are listed at http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation. From past experience, I've used Asan (address sanitizer) and UBsan (undefined behavior sanitizer) to find tricky bugs in other projects and libraries. For example, Wei Dai's Crypto++ would fail one self test when compiled with Intel's ICC (but pass them all under Clang, Comeau, GCC and MSVC). The failed Crypto++ self test was due to ICC aggressively removing undefined behavior, and the Intel compiler/optimizer targeted [not readily apprent] undefined behavior in the underlying library code. After fixing the library code identifed by Clang UBsan, Crypto++ tested fine under all compilers. The real beauty here is: (1) Python already has a mature process, so the addition of the Clang analysis will take minimal effort; and (2) Python has a rich set of self-test, so the Clang sanitizers can *really* be effective. For areas that don't have complete self test coverage, its another task that can be delegated to non-senior members and contributors. That frees up time for senior members to do other things, like adding features to Python or watching football. Coverity Scans == I think the project could benefit from Coverity scanning and analysis. The analysis is quite good most of the time, and I believe it will complement Python's exiting engineering process. In addition, it will complement Clang analysis is Clang is adopted. Coverity is one of the high-end analysis engines available. Though Coverity is a pay-to-play service, Coverity offers a free scanning service for free projects. The URL for the free service is http://scan.coverity.com. It cost nothing to sign up for, and it costs nothing to run a scan. Minimal effort is required to prepare a binary for upload. Coverity performs static analysis, and it will flag false positives on occasion. However, its a trade-off in the effort to proactively hunt bugs. -- components: Build messages: 213728 nosy:
[issue1621] Do not assume signed integer overflow behavior
Jeffrey Walton added the comment: Also see http://bugs.python.org/issue20944 for suggestions to identify the offending code. -- nosy: +Jeffrey.Walton ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1621 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20945] why save the item to be replaced as olditem in PyTuple_SetItem? It's not useful at all.
New submission from coder.maliubiao:
code:
int
PyTuple_SetItem(register PyObject *op, register Py_ssize_t i, PyObject *newitem)
{
register PyObject *olditem;
register PyObject **p;
if (!PyTuple_Check(op) || op-ob_refcnt != 1) {
Py_XDECREF(newitem);
PyErr_BadInternalCall();
return -1;
}
if (i 0 || i = Py_SIZE(op)) {
Py_XDECREF(newitem);
PyErr_SetString(PyExc_IndexError,
tuple assignment index out of range);
return -1;
}
p = ((PyTupleObject *)op) - ob_item + i;
olditem = *p;
*p = newitem;
Py_XDECREF(olditem);
return 0;
}
olditem is not useful.
--
components: Devguide
messages: 213730
nosy: ezio.melotti, maliub...@gmail.com
priority: normal
severity: normal
status: open
title: why save the item to be replaced as olditem in PyTuple_SetItem? It's
not useful at all.
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20945
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20906] Issues in Unicode HOWTO
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20906 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20945] why save the item to be replaced as olditem in PyTuple_SetItem? It's not useful at all.
Changes by coder.maliubiao maliub...@gmail.com: -- type: - performance ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20945 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20944] Engineering Process Improvements
R. David Murray added the comment: We already have Coverty scan in place, and were in fact featured by them for our code quality. Currently Christian Heimes is the lead on that effort, and is monitoring the Coverty reports. We've been working on Clang stuff as developers have had interest, and accepted a patch enabling address sanitizer to be used. So, yes, we are interested in this stuff and working on it, and your contributions will be welcomed. The bug tracker is a place for dealing with specific issues, not general approaches. So please by all means open specific issues for specific suggestions :) -- nosy: +r.david.murray resolution: - later stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20944 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20944] Engineering Process Improvements
R. David Murray added the comment: Oh, and if you there there are general issues to be discussed about approach (and I think out use of asserts might be one such), then the appropriate forum is the python-dev mailing list. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20944 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20944] Engineering Process Improvements
R. David Murray added the comment: Oh, and if you think there there are general issues to be discussed about approach (and I think our use of asserts might be one such), then the appropriate forum is the python-dev mailing list. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20944 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20944] Engineering Process Improvements
Changes by R. David Murray rdmur...@bitdance.com: -- Removed message: http://bugs.python.org/msg213732 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20944 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20944] Engineering Process Improvements
Jeffrey Walton added the comment: On Sun, Mar 16, 2014 at 11:12 AM, R. David Murray rep...@bugs.python.org wrote: R. David Murray added the comment: We already have Coverty scan in place, and were in fact featured by them for our code quality. Currently Christian Heimes is the lead on that effort, and is monitoring the Coverty reports. Oh, my bad. I searched for the project and got 0 results. Please accept my apologies. EDIT: my dislexia got me. I searched for Pyhton, and not Python. Sorry about that. We've been working on Clang stuff as developers have had interest, and accepted a patch enabling address sanitizer to be used. That's great. Jeff -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20944 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20946] ctypes test fixes
New submission from Andreas Schwab:
The attached patch fixes some wrong alignment assumptions in the ctype tests.
It has been tested on
{ppc,ppc64,ppc64le,i586,x86_64,armv6hl,aarch64,m68k}-suse-linux.
--
components: Tests
files: ctypes-align.patch
keywords: patch
messages: 213735
nosy: schwab
priority: normal
severity: normal
status: open
title: ctypes test fixes
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file34440/ctypes-align.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20946
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20946] ctypes test fixes
Roundup Robot added the comment: New changeset 2150053d77ca by Benjamin Peterson in branch '3.3': fix ctypes test alignment assumptions (closes #20946) http://hg.python.org/cpython/rev/2150053d77ca New changeset e5a09b09bb51 by Benjamin Peterson in branch '2.7': fix ctypes test alignment assumptions (closes #20946) http://hg.python.org/cpython/rev/e5a09b09bb51 New changeset 3736bf94535c by Benjamin Peterson in branch 'default': merge 3.3 (#20946) http://hg.python.org/cpython/rev/3736bf94535c -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20946 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20942] _frozen_importlib should not have a __file__ attribute
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20942 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20884] importlib/__init__.py can not be loaded without __file__ - breaks cxFreeze
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20884 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18478] Class bodies: when does a name become local?
Nitika Agarwal added the comment: Hi, Please review my patch attached. -- keywords: +patch Added file: http://bugs.python.org/file34441/issue18478.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18478 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4744] asynchat documentation needs to be more precise
Nitika Agarwal added the comment: Hi, Please review my patch attached.Any comments and feedback are welcome. -- keywords: +patch Added file: http://bugs.python.org/file34442/issue4744_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4744 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20945] why save the item to be replaced as olditem in PyTuple_SetItem? It's not useful at all.
Antoine Pitrou added the comment: olditem is not useful It is. Py_XDECREF() may have massive side effects (such as calling a __del__ method and executing arbitrary code). Therefore, you have to ensure that the tuple item is set to the new value *before* the old value is DECREF'ed. Otherwise, any code invoked by Py_XDECREF will see invalid tuple contents, and the interpreter may crash. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20945 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18854] is_multipart and walk should document their treatment of 'message' parts.
Nitika Agarwal added the comment: Hi David, I didn't exactly get the issue.Will you please help me with what is to be updated. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18854 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20906] Issues in Unicode HOWTO
Antoine Pitrou added the comment: Do you want to provide a patch? In a narrative such as the current article, a code point value is usually written in hexadecimal. I find use of the word narrative intimidating in the context of a technical documentation. In general, I find it disappointing that the Unicode HOWTO only gives hexadecimal representations of non-ASCII characters and (almost) never represents them in their true form. This makes things more abstract than necessary. This is a vague claim. Probably what was intended was: Many Internet standards define protocols in which the data must contain no zero bytes, or zero bytes have special meaning. Is this actually true? Are there many such standards? I think it actually means that Internet protocols assume an ASCII-compatible encoding (which UTF-8 is, but not UTF-16 or UTF-32 - nor EBCDIC :-)). -- Non-Unicode code systems usually don't handle all of the characters to be found in Unicode. The term *encoding* is used pervasively when dealing with the transformation of unicode to/from bytes, so I find it confusing to introduce another term here (code systems). I prefer the original sentence. -- nosy: +akuchling ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20906 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20947] -Wstrict-overflow findings
New submission from Jeffrey Walton: $ hg id 3736bf94535c+ tip Forgive me if you were aware of these. /usr/bin/gcc -pthread -fPIC -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fno-common -Wstrict-overflow -Wformat=2 -Wformat-security -Wcast-align -Wtrampolines -fno-common -Wstrict-overflow -Wformat=2 -Wformat-security -Wcast-align -Wtrampolines -I./Include -I. -IInclude -I/usr/include/x86_64-linux-gnu -I/usr/local/include -Icpython/./Include -Icpython/. -c cpython/./Modules/_posixsubprocess.c -o build/temp.linux-x86_64-3.4cpython/./Modules/_posixsubprocess.o cpython/./Modules/_posixsubprocess.c: In function ‘child_exec’: cpython/./Modules/_posixsubprocess.c:491:33: warning: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Wstrict-overflow] cpython/./Modules/_posixsubprocess.c: In function ‘subprocess_fork_exec’: cpython/./Modules/_posixsubprocess.c:491:33: warning: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Wstrict-overflow] cpython/./Modules/_posixsubprocess.c:491:33: warning: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Wstrict-overflow] cpython/./Modules/_posixsubprocess.c:491:33: warning: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Wstrict-overflow] ... /usr/bin/gcc -pthread -fPIC -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fno-common -Wstrict-overflow -Wformat=2 -Wformat-security -Wcast-align -Wtrampolines -fno-common -Wstrict-overflow -Wformat=2 -Wformat-security -Wcast-align -Wtrampolines -I./Include -I. -IInclude -I/usr/include/x86_64-linux-gnu -I/usr/local/include -Icpython/./Include -Icpython/. -c cpython/./Modules/sha512module.c -o build/temp.linux-x86_64-3.4cpython/./Modules/sha512module.o cpython/./Modules/sha512module.c: In function ‘sha512_transform’: cpython/./Modules/sha512module.c:128:1: warning: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Wstrict-overflow] cpython/./Modules/sha512module.c:128:1: warning: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Wstrict-overflow] -- components: Build hgrepos: 224 messages: 213742 nosy: Jeffrey.Walton priority: normal severity: normal status: open title: -Wstrict-overflow findings versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20947 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20948] -Wformat=2 -Wformat-security findings
New submission from Jeffrey Walton: $ hg id 3736bf94535c+ tip -Wformat=2 -Wformat-security are useful for detecting possible security related bugs. Compiling with the two options produced a few hits in the source code. /usr/bin/gcc -pthread -c -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fno-common -Wstrict-overflow -Wformat=2 -Wformat-security -Wcast-align -Wtrampolines -fno-common -Wstrict-overflow -Wformat=2 -Wformat-security -Wcast-align -Wtrampolines -I. -IInclude -I./Include-DPy_BUILD_CORE -o Objects/unicodeobject.o cpython/./Objects/unicodeobject.c cpython/./Objects/unicodeobject.c: In function ‘unicode_fromformat_arg’: cpython/./Objects/unicodeobject.c:2527:25: warning: format not a string literal, argument types not checked [-Wformat-nonliteral] cpython/./Objects/unicodeobject.c:2531:25: warning: format not a string literal, argument types not checked [-Wformat-nonliteral] cpython/./Objects/unicodeobject.c:2535:25: warning: format not a string literal, argument types not checked [-Wformat-nonliteral] cpython/./Objects/unicodeobject.c:2538:25: warning: format not a string literal, argument types not checked [-Wformat-nonliteral] cpython/./Objects/unicodeobject.c:2542:13: warning: format not a string literal, argument types not checked [-Wformat-nonliteral] cpython/./Objects/unicodeobject.c:2549:25: warning: format not a string literal, argument types not checked [-Wformat-nonliteral] cpython/./Objects/unicodeobject.c:2553:25: warning: format not a string literal, argument types not checked [-Wformat-nonliteral] cpython/./Objects/unicodeobject.c:2557:25: warning: format not a string literal, argument types not checked [-Wformat-nonliteral] cpython/./Objects/unicodeobject.c:2560:25: warning: format not a string literal, argument types not checked [-Wformat-nonliteral] I think those are necessary for to `unicode_fromformat_arg`. /usr/bin/gcc -pthread -c -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fno-common -Wstrict-overflow -Wformat=2 -Wformat-security -Wcast-align -Wtrampolines -fno-common -Wstrict-overflow -Wformat=2 -Wformat-security -Wcast-align -Wtrampolines -I. -IInclude -I./Include-DPy_BUILD_CORE -o Modules/main.o cpython/./Modules/main.c cpython/./Modules/main.c: In function ‘usage’: cpython/./Modules/main.c:111:5: warning: format not a string literal, argument types not checked [-Wformat-nonliteral] cpython/./Modules/main.c:118:9: warning: format not a string literal, argument types not checked [-Wformat-nonliteral] cpython/./Modules/main.c:119:9: warning: format not a string literal, argument types not checked [-Wformat-nonliteral] I think the occurrences in main.c could benefit from %s to ensure the program does not accidentally leak. -- components: Build hgrepos: 225 messages: 213743 nosy: Jeffrey.Walton priority: normal severity: normal status: open title: -Wformat=2 -Wformat-security findings versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20948 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20948] -Wformat=2 -Wformat-security findings
Jeffrey Walton added the comment:
If interested, I think the warnings can be selectively turned off:
#if defined (__GNUC__) ((__GNUC__ == 4 __GNUC_MINOR__ = 6) || (__GNUC__
= 5))
# pragma GCC diagnostic push
# pragma GCC diagnostic ignored -Wformat-security
#endif
unicode_fromformat_arg(...)
{
...
}
#if defined (__GNUC__) ((__GNUC__ == 4 __GNUC_MINOR__ = 6) || (__GNUC__
= 5))
# pragma GCC diagnostic pop
#endif
Microsoft has a similar mechanism.
It should allow the project to compile with -Wformat-security full time while
maintinaing a quiet compile (silent is good).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20948
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20948] -Wformat=2 -Wformat-security findings
Jeffrey Walton added the comment: #if defined (__GNUC__) ((__GNUC__ == 4 __GNUC_MINOR__ = 6) || (__GNUC__ = 5)) # pragma GCC diagnostic push # pragma GCC diagnostic ignored -Wformat-security #endif My bad... -Wformat-nonliteral -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20948 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17442] code.InteractiveInterpreter doesn't display the exception cause
Changes by Claudiu.Popa pcmantic...@gmail.com: Added file: http://bugs.python.org/file34443/issue17442_1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17442 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17383] Possibly ambiguous phrasing in tutorial/modules#more-on-modules
Nitika Agarwal added the comment: Hi, I would like to propose a patch for this issue. -- nosy: +nitika ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18854] is_multipart and walk should document their treatment of 'message' parts.
R. David Murray added the comment: Well, probably the best thing to do to understand the issue is to look at the implementation of Message.walk and is_multipart, and to notice that is_multipart() can return a different answer than msg.get_content_maintype() == 'multipart' if the Message content type is message/rfc822. You may want to do some reading about how to construct Messages and experiment by creating such a message/rfc822 Message to really understand it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18854 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1738] filecmp.dircmp does exact match only
Nikolaus Rath added the comment: I don't think that we can just introduce path normalization in phase0. Even though I agree that this would be the proper way to do it when reimplementing from scratch, it breaks backward compatibility. There also is a small mistake in that the *match* attribute should also be used for subdirectories in the `phase4` method. Other than that, this patch looks good to me. I fixed the above issues, rebased on current hg tip, and added some missing markup in the documentation. After inspecting the code, it seems that there is no difference between directory entries being hidden by the *hide* parameter, and being ignored* by the *ignore* parameter, so I also updated the documentation make this less confusing. I could not reproduce the test failure reported by Mark, but this is most likely because I could not find out on what base revision to apply his patch. I think this is ready for commit. -- nosy: +nikratio Added file: http://bugs.python.org/file3/issue1738.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1738 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1738] Add match parameter to filecmp.dircmp to ignore name patterns
Changes by Nikolaus Rath nikol...@rath.org: -- title: filecmp.dircmp does exact match only - Add match parameter to filecmp.dircmp to ignore name patterns versions: +Python 3.5 -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1738 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1738] Add match parameter to filecmp.dircmp to ignore using patterns
Changes by Nikolaus Rath nikol...@rath.org: -- title: Add match parameter to filecmp.dircmp to ignore name patterns - Add match parameter to filecmp.dircmp to ignore using patterns ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1738 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20949] Missing platform security integrations
New submission from Jeffrey Walton:
$ hg id
3736bf94535c+ tip
A standard Python build does not take a proactive approach to integrating with
platform security measures. Attepting to add the measures results in a failed
build.
For example:
export CC=/usr/bin/gcc
export CXX=/usr/bin/g++
export CFLAGS=-fPIC -fstack-protector-all -D_FORTIFY_SOURCE=2
export CXXFLAGS=-fPIC -fstack-protector-all -D_FORTIFY_SOURCE=2
export LDFLAGS=-pie -Wl,-z,noexecstack -Wl,-z,noexecheap -Wl,-z,now
-Wl,-z,relro
will configure properly, but will fail to build.
The idea is to build executables with {-fPIE,-pie} and build shared objects
with {-fPIC,-shared}. Both executables and shared objects get the remaining
platform security integrations like stack protectors and NX stacks/heaps.
In the case an object file is used for both an executable and shared object, it
should be compiled with -fPIC (and linking will include -pie or -shared as
required). Its OK to use -fPIC in place of -fPIE. See
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885 for details.
*
Examining the failed compile:
/usr/bin/gcc -pthread -shared -pie -Wl,-z,noexecstack -Wl,-z,noexecheap
-Wl,-z,now -Wl,-z,relro -pie -Wl,-z,noexecstack -Wl,-z,noexecheap -Wl,-z,now
-Wl,-z,relro -pie -Wl,-z,noexecstack -Wl,-z,noexecheap -Wl,-z,now -Wl,-z,relro
-fPIC -fstack-protector-all -D_FORTIFY_SOURCE=2
build/temp.linux-x86_64-3.4/home/jwalton/Desktop/cpython-checkout/Modules/_struct.o
-L/usr/lib/x86_64-linux-gnu -L/usr/local/lib -o
build/lib.linux-x86_64-3.4/_struct.cpython-34m.so
So, autotools tried to add both -pie (for executables) and -shared (for shared
objects). Fail.
The same problem occurs with _struct.cpython-34m.so,
_ctypes_test.cpython-34m.so, array.cpython-34m.so, cmath.cpython-34m.so,
math.cpython-34m.so, time.cpython-34m.so, _datetime.cpython-34m.so,
_random.cpython-34m.so, _bisect.cpython-34m.so, ...
*
I know I can omit -pie from CFLAGS and CXXFLAGS:
export CC=/usr/bin/gcc
export CXX=/usr/bin/g++
export CFLAGS=-fPIC -fstack-protector-all -D_FORTIFY_SOURCE=2
export CXXFLAGS=-fPIC -fstack-protector-all -D_FORTIFY_SOURCE=2
export LDFLAGS=-Wl,-z,noexecstack -Wl,-z,noexecheap -Wl,-z,now -Wl,-z,relro
but then I have to manually add -pie to Makefile lines with $BUILDPYTHON (and
others, like _testembed and _freeze_importlib):
$(BUILDPYTHON): Modules/python.o $(LIBRARY) $(LDLIBRARY) $(PY3LIBRARY)
$(LINKCC) -pie $(PY_LDFLAGS) $(LINKFORSHARED) -o $@ Modules/python.o
$(BLDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST)
...
*
Examining an executable produced by the modified Makefil with Tobias Klein's
Checksec (http://www.trapkit.de/tools/checksec.html) shows the platform
security integrations were successfully applied:
$ checksec.sh --file ./python
RELRO STACK CANARY NXPIE RPATH
RUNPATH FILE
Full RELRO Canary found NX enabledPIE enabled No RPATH No
RUNPATH ./python
*
Running `make test` with the security integrations worked as expected, and did
not result in any adverse behavior (like an abrupt shutdown).
*
It would be great if Python tested for features like ASLR for executables, and
simply added {-fPIE,-pie} as available. The same is true for the other security
offerings (_FORTIFY_SOURCE should be added to Release builds only).
--
components: Build
hgrepos: 226
messages: 213749
nosy: Jeffrey.Walton
priority: normal
severity: normal
status: open
title: Missing platform security integrations
versions: Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20949
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15582] Enhance inspect.getdoc to follow inheritance chains
Changes by Claudiu.Popa pcmantic...@gmail.com: Added file: http://bugs.python.org/file34445/issue15582.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15582 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17383] Possibly ambiguous phrasing in tutorial/modules#more-on-modules
Nitika Agarwal added the comment: Hello everyone, I have tried creating a patch for the issue, Please review the attached patch. -- keywords: +patch Added file: http://bugs.python.org/file34446/issue17383.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20949] Missing platform security integrations
Jeffrey Walton added the comment: $ checksec.sh --file ./python RELRO STACK CANARY NXPIE RPATH RUNPATH FILE Full RELRO Canary found NX enabledPIE enabled No RPATH No RUNPATH ./python Here's what a standard Python build looks like (without the platform security integrations): $ checksec.sh --file ./python RELRO STACK CANARY NXPIE RPATH RUNPATH FILE No RELRONo canary found NX enabledNo PIE No RPATH No RUNPATH ./python I believe the NX stack is coming Debian's hardening for amd64's (https://wiki.debian.org/Hardening). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20949 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20887] stdlib compatibility with pypy, test_zipfile.py
mattip added the comment: The test_zipfile in Python 3 is very different from this one, so I would prefer that it be two seperate issues. After your review of the patch, are there remaining issues that need to be cleared up? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20887 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20950] asyncio.docs : asyncio.subprocess.Process.wait() method typo
New submission from Alexandre JABORSKA: The asyncio.subprocess.Process.wait() documentation mention self parameter (typo ?) and don't tell it's a coroutine. -- assignee: docs@python components: Documentation messages: 213753 nosy: ajaborsk, docs@python priority: normal severity: normal status: open title: asyncio.docs : asyncio.subprocess.Process.wait() method typo type: enhancement versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20950 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19840] The is no way to tell shutil.move to ignore metadata
Changes by Claudiu.Popa pcmantic...@gmail.com: Added file: http://bugs.python.org/file34447/issue19840.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19840 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20950] asyncio.docs : asyncio.subprocess.Process.wait() method typo
Roundup Robot added the comment: New changeset 1009cf8cb304 by Victor Stinner in branch 'default': Issue #20950: Fix typo asyncio doc, wait() has no self parameter http://hg.python.org/cpython/rev/1009cf8cb304 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20950 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20950] asyncio.docs : asyncio.subprocess.Process.wait() method typo
STINNER Victor added the comment: Thanks, it has been fixed (in 12 minutes ;-)). I also mentionned that communicate() and wait() are coroutines. -- nosy: +haypo resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20950 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20941] pytime.c:184 and pytime.c:218: runtime error, outside the range of representable values of type 'long'
STINNER Victor added the comment:
Hi,
pytime.c:184: runtime error: value -1e+200 is outside the range of
representable values of type 'long'
How did you get this warning?
Shouldn't a range test based on TIME_T_MAX with an epsilon occur first?
Two lines after, the integer overflow is checked:
*sec = (time_t)intpart;
err = intpart - (double)*sec;
if (err = -1.0 || err = 1.0) {
error_time_t_overflow();
return -1;
}
And it works, example:
import _testcapi
_testcapi.pytime_object_to_time_t(-1e+200, 0)
Traceback (most recent call last):
File stdin, line 1, in module
OverflowError: timestamp out of range for platform time_t
(where 0 means _PyTime_ROUND_DOWN)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20941
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18747] Re-seed OpenSSL's PRNG after fork
Jeffrey Walton added the comment: It probably is an OpenSSL bug but the declaration doesn't help us. It's not the first time Python has to work around OpenSSL, e.g. #18709. Sorry to dig up an old issue. But here's some reading on it if interested. Ben Laurire pushed a patch to mix in PID and time. The PID was already being used, so the patch adds the time. See Mixing time into the pool, http://www.mail-archive.com/openssl-dev@openssl.org/msg33012.html. And the commit: https://github.com/openssl/openssl/commit/3cd8547a2018ada88a4303067a2aa15eadc17f39. OpenSSL added a wiki page for reading on the subject: http://wiki.openssl.org/index.php/Random_fork-safety. -- nosy: +Jeffrey.Walton ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18747 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20945] why save the item to be replaced as olditem in PyTuple_SetItem? It's not useful at all.
Changes by Benjamin Peterson bp+pyb...@benjamin-peterson.org: -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20945 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11448] docs for HTTPConnection.set_tunnel are ambiguous
Roundup Robot added the comment: New changeset 68a257ca6be6 by Benjamin Peterson in branch '3.3': improve set_tunnel docs (closes #11448) http://hg.python.org/cpython/rev/68a257ca6be6 New changeset 5cab0ada97b2 by Benjamin Peterson in branch 'default': merge 3.3 (#11448) http://hg.python.org/cpython/rev/5cab0ada97b2 -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11448 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20951] SSLSocket.send() returns 0 for non-blocking socket
New submission from Nikolaus Rath: When using non-blocking operation, the SSLSocket.send method returns 0 if no data can be sent at this point. This is counterintuitive, because in the same situation (write to non-blocking socket that isn't ready for IO): * A regular (non-SSL) socket raises BlockingIOError * libc's send(2) does not return 0, but -EAGAIN or -EWOULDBLOCK. * OpenSSL's ssl_write does not return 0, but returns an SSL_ERROR_WANT_WRITE error * The ssl module's documentation describes the SSLWantWrite exception as A subclass of SSLError raised by a non-blocking SSL socket when trying to read or write data, but more data needs to be sent on the underlying TCP transport before the request can be fulfilled. * Consistent with that, trying to *read* from a non-blocking SSLSocket when no data is ready raises SSLWantRead, instead of returning zero. This behavior also makes it more complicated to write code that works with both SSLSockets and regular sockets. Since the current behavior undocumented at best (and contradicting the documentation at worst), can we change this in Python 3.5? -- components: Library (Lib) messages: 213759 nosy: christian.heimes, giampaolo.rodola, janssen, nikratio, pitrou priority: normal severity: normal status: open title: SSLSocket.send() returns 0 for non-blocking socket type: behavior versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20951 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20941] pytime.c:184 and pytime.c:218: runtime error, outside the range of representable values of type 'long'
Gareth Rees added the comment: How did you get this warning? This looks like runtime output from a program built using Clang/LLVM with -fsanitize=undefined. See here: http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation Signed integer overflow is undefined behaviour, so by the time *sec = (time_t)intpart has been evaluated, the undefined behaviour has already happened. It is too late to check for it afterwards. -- nosy: +Gareth.Rees ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20941 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20951] SSLSocket.send() returns 0 for non-blocking socket
Nikolaus Rath added the comment: This is actually seems to be not just an inconvience, but a real bug: since SSLSocket.sendall() uses SSLSocket.send() internally, the former method will busy-loop when called on a non-blocking socket. Note also that the .sendto and .write methods already behave consistently and raise SSLWantWrite. It seems it's really just the send() method that is the lone outlier. The attached patch changes ssl.send to raise SSLWantWrite instead of returning zero. The full testsuite still runs fine. I'm a bit sceptical though, because the code looks as if send() was deliberately written to catch the SSLWantWrite exception and return zero instead.. Can anyone familiar with the code comment on this? -- keywords: +patch Added file: http://bugs.python.org/file34448/issue20951.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20951 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16245] Update html.entities.html5 dictionary and parseentities.py
Éric Araujo added the comment: I just ran the script: $ Tools/scripts/parse_html5_entities.py The current dictionary is updated. This is done :‑) -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16245 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16245] Update html.entities.html5 dictionary and parseentities.py
Éric Araujo added the comment: BTW this message does not mean that the dictionary was just updated, but that is was already up to date. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16245 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20951] SSLSocket.send() returns 0 for non-blocking socket
R. David Murray added the comment: A little hg sleuthing (which I assume you did but I'll record for the record) reveals that this was introduced by Bill Jansen in changeset 8a281bfc058d. Following the bugs mentioned in the checkin message, it looks like it *might* have been related to issue 1251, but there really isn't enough information in the issues or the checkin to tell for sure. It certainly sounds like the problems mentioned in that issue may be relevant, though (the disconnection between the unecrypted data send and what actually gets placed on the wire and when). I see you already added Bill Jansen to nosy, so that's probably the best bet for getting an answer, if we are lucky and he both responds and remembers :) -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20951 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18624] Add alias for iso-8859-8-i which is the same as iso-8859-8
Kamilla added the comment: Adding aliases to the set of iso-8859-8. -- keywords: +patch Added file: http://bugs.python.org/file34449/adding_aliases.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18624 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20951] SSLSocket.send() returns 0 for non-blocking socket
Antoine Pitrou added the comment: It's probably too late to change this, unfortunately. There are non-blocking frameworks and libraries out there relying on the current behaviour. As for sendall(), it doesn't really make sense on a non-blocking socket anyway. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20951 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17383] Possibly ambiguous phrasing in tutorial/modules#more-on-modules
Éric Araujo added the comment: Thanks for the patch. +Enhancing the More on Modules documentation + This should not be in the patch. -Modules can import other modules. It is customary but not required -to place all import statements at the beginning of a module (or script, -for that matter). The imported module names are placed in the importing -module’s global symbol table. +Modules can import other modules. It is customary but not required +to place all import statements at the beginning of a module (or script, +for that matter). The imported module names are placed in the importing +module’s global symbol table. These lines are not changed, I suspect the characters used for the end of lines have been changed by your text editor. Please fix that (search for “EOL” or “hgeol” in the devguide). +For more on namespace, follow the link : +http://docs.python.org/2/tutorial/classes.html#python-scopes-and-namespaces I don’t think adding this link solves the ambiguous phrasing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20112] The documentation for http.server error_message_format is inadequate.
R. David Murray added the comment: My intent here was that the rewrite should specify where the data that gets placed into the template when it is used comes from. That would be 'responses' by default, but can be overridden in 'send_error'. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20112 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20952] OpenSSL and RDRAND
New submission from Jeffrey Walton: Some versions of OpenSSL use the RDRAND engine by default. The versions include openssl-1.0.1-beta1 through openssl-1.0.1f. RDRAND has taken some criticism because its essentially unaudited and it could be spiked like the Dual-EC generator (http://blog.cryptographyengineering.com/2013/09/the-many-flaws-of-dualecdrbg.html). If the RDRAND engine is in effect, then the application and the library (internally) will be using the generator. But some some folks don't want to use an unaudited generator. I'm not sure what the best action is to take. For reading on ways to disable the RDRAND engine, see http://seclists.org/fulldisclosure/2013/Dec/142. -- components: Extension Modules messages: 213769 nosy: Jeffrey.Walton priority: normal severity: normal status: open title: OpenSSL and RDRAND ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20952 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20112] The documentation for http.server error_message_format is inadequate.
R. David Murray added the comment: Hmm. Rereading your patch I see that that is what you are trying to do, but I find the order of presentation confusing. I would rather see the text focus on the fact that the string is used by send_error, and that the variables are filled by default from responses based on the code passed to send_error, and that you can also specify an alternate explain message that overrides the one from responses when calling send_error. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20112 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20898] Missing 507 response description
R. David Murray added the comment: Thanks. That patch looks good except that it is missing the corresponding documentation changes, but... I just noticed that this table is a partial duplicate of the table in http.server. I suspect this has historical origins, but I don't see any reason to maintain the duplication. I wonder if we should do some refactoring here. This is getting a beyond the original scope of this issue, but it seems to me that the common stuff used by http.server and http.client (which is mostly in http.client, except for the 'explain' messages that are in the http.server responses list) could be moved into a 'common' or 'util' module, and imported from both, thus reducing the direct coupling between http.server and http.client. (The 'responses' object in http.client would have to be computed from the one in this new module, since the http.client one doesn't contain the 'explain' messages). -- nosy: +orsenthil versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20898 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18624] Add alias for iso-8859-8-i which is the same as iso-8859-8
R. David Murray added the comment: From python's point of view they are both aliases of iso-8859_8, as discussed in this issue. Python does not have iso-8859_8-e and i codecs, which you changes to the alias table implies that it does (the target of the entry in the aliases table is the python codec name...and there is only iso8859_8.py, not iso8859_8_E.py or _I.py). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18624 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20896] test_ssl.test_get_server_certificate() should use PROTOCOL_SSLv23, not PROTOCOL_SSLv3
Changes by Curtis Doty cur...@greenkey.net: -- nosy: +GreenKey ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20896 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18624] Add alias for iso-8859-8-i which is the same as iso-8859-8
R. David Murray added the comment: The tests are in test_encodings.py. It is interesting that the tests pass with your patch applied; that indicates that there is a missing test, since we should be testing that all of the values in the aliases table are the names of existing codecs, and apparently we aren't. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18624 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20939] test_geturl of test_urllibnet fails with 'https://www.python.org/' != 'http://www.python.org/'
Changes by Curtis Doty cur...@greenkey.net: -- nosy: +GreenKey ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20939 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20952] OpenSSL and RDRAND
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +christian.heimes, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20952 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20951] SSLSocket.send() returns 0 for non-blocking socket
Nikolaus Rath added the comment: Antoine, do you know that there are frameworks out there using this, or is that a guess? asyncio, for example, seems to expect an SSLWantWrite exception as well. (it also works with a zero return, but it's not clear from the code if that's by design or by a chance). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20951 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20952] OpenSSL and RDRAND
Antoine Pitrou added the comment: Apart from our Windows binaries, this doesn't seem much of a Python issue. Python normally links with whatever the system OpenSSL is. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20952 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20951] SSLSocket.send() returns 0 for non-blocking socket
Antoine Pitrou added the comment: Antoine, do you know that there are frameworks out there using this, or is that a guess? It's just a guess. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20951 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20896] test_ssl.test_get_server_certificate() should use PROTOCOL_SSLv23, not PROTOCOL_SSLv3
STINNER Victor added the comment: Benjamin: Could you please mention your change in Misc/NEWS? Is it ok to change that in Python 3.1 3.2? Should the change be mentionned in the doc (:versionchanged:)? -- resolution: fixed - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20896 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20951] SSLSocket.send() returns 0 for non-blocking socket
Nikolaus Rath added the comment: Twisted does not seem to rely on it either (there's no mention of SSLWant* in the source at all, and without that, you can't possibly have support for non-blocking ssl sockets). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20951 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20951] SSLSocket.send() returns 0 for non-blocking socket
Nikolaus Rath added the comment: gevent is calling _sslobject.write() directly, so it would not be affected by any change. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20951 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20951] SSLSocket.send() returns 0 for non-blocking socket
Nikolaus Rath added the comment: Tornado uses SSLSocket.send(), and it looks as if a SSLWantWrite exception is not caught but would propagate, so this would probably break. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20951 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20898] Missing 507 response description
Filip Malczak added the comment:
If we're getting out of original scope, then I wonder... Maybe we should keep
only standard status codes here? If not, which should we support, and which
not? What about custom Spring 420 Method Failure?
One way to clean up mess here is to create some dictionaries called Http09,
Http10, Http11, but also Nginx, Spring, InternetDraft, etc - they would hold
codes specific to some standard or extension (and they should be incremental,
so Http11 would hold only those codes that came with HTTP 1.1, not any of HTTP
1.0 codes).
Also, we should provide function responses_mapping which should take
dictionaries with code mappings, so one may use it like
responses_mapping(Http09, Http10, Http11, Spring). Module attribute responses
should be initialized to responses_mapping(Http09, Http10, Http11), so it would
contain standard codes only.
responses_mapping (we should probably consider different name) should take any
number of dicts, merge them and return merging result. Additionally, I think it
should overwrite merged values, so if we call it with two dicts, which hold the
same key - value from last dict with this key should be used. Essentially, it
is just:
def responses_mapping(*dicts):
out = {}
for d in dicts:
out.update(d)
return out
Now, we would have clean responses dictionary (mentioned in first comment, one
that started this issue), and possibility to extend responses set with
different protocol and extension versions.
There may be one problem - many apps and libs (possibly standard python library
too) may use keys from out of HTTP standard, so this change could break
backwards compability.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20898
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20951] SSLSocket.send() returns 0 for non-blocking socket
Nikolaus Rath added the comment: More info on twisted: it uses PyOpenSSL rather than the stdlib ssl module, so it's not affected at all. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20951 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20906] Issues in Unicode HOWTO
Graham Wideman added the comment: Do you want to provide a patch? I would be happy to, but I'm not currently set up to create a patch. Also, I hoped that an author who has more history with this article would supervise, especially where I don't know what the original intent was. I find use of the word narrative intimidating in the context of a technical documentation. Agreed. How about In documentation such as the current article... In general, I find it disappointing that the Unicode HOWTO only gives hexadecimal representations of non-ASCII characters and (almost) never represents them in their true form. This makes things more abstract than necessary. I concur with reducing unnecessary abstraction. No sure what you mean by true form. Do you mean show the glyph which the code point represents? Or the sequence of bytes? Or display the code point value in decimal? This is a vague claim. Probably what was intended was: Many Internet standards define protocols in which the data must contain no zero bytes, or zero bytes have special meaning. Is this actually true? Are there many such standards? I think it actually means that Internet protocols assume an ASCII-compatible encoding (which UTF-8 is, but not UTF-16 or UTF-32 - nor EBCDIC :-)). Ah -- yes that makes sense. -- Non-Unicode code systems usually don't handle all of the characters to be found in Unicode. The term *encoding* is used pervasively when dealing with the transformation of unicode to/from bytes, so I find it confusing to introduce another term here (code systems). I prefer the original sentence. I see that my revision missed the target. There is a problem, but it is wider than this sentence. One of the most essential points this article should make clear is the distinction between older schemes with a single mapping: Characters -- numbers in particular binary format. (eg: ASCII) ... versus Unicode with two levels of mapping... Characters -- code point numbers -- particular binary format of the number data and sequences thereof. In the older schemes, encoding referred to the one mapping: chars -- numbers in particular binary format. In Unicode, encoding refers only to the mapping: code point numbers -- binary format. It does not refer to the chars -- code point mapping. (At least, I think that's the case. Regardless, the two mappings need to be rigorously distinguished.) On review, there are many points in the article that muddy this up. For example, Unicode started out using 16-bit characters instead of 8-bit characters. Saying so-an-so-bit characters about Unicode, in the current article, is either wrong, or very confusing. Unicode characters are associated with code points, NOT with any _particular_ bit level representation. If I'm right about the preceding, then it would be good for that to be spelled out more explicitly, and used consistently throughout the article. (I won't try to list all the examples of this problem here -- too messy.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20906 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20906] Issues in Unicode HOWTO
Graham Wideman added the comment: A further issue regarding one-to-one mappings. Article: Encodings don’t have to be simple one-to-one mappings like Latin-1. Consider IBM’s EBCDIC, which was used on IBM mainframes. I don't think this paragraph is about one-to-one mappings per se. (ie: one character to one code.) It seems to be about whether ranges of characters whose code values are contiguous in one coding system are also contiguous in another coding system. The EBCDIC encoding is still one-to-one, I believe. The subject of one-chararacter-to-one-code mapping is important (normalization etc), though perhaps beyond the current article. But I think the article should avoid suggesting that many-to-one or one-to-many scenarios are common. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20906 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20943] configparser - add 'getDict' function
Łukasz Langa added the comment:
Michael, what you wish is already a part of configparser. Let's use this as an
example:
p = configparser.ConfigParser()
p.read_string(
... [one]
... opt=val
... [two]
... num=1
... str=bzz
... bool=true
... )
When asking for a specific section, you get a SectionProxy object. It has a
dict-like API but is not a dict:
p['two']
Section: two
isinstance(p['two'], dict)
False
The reason for that is two-fold: firstly this enables us to make changes made
on a section object persistent within the main parser. Secondly, this enables
us to add configparsser-specific functionality (like dynamic interpolation,
type conversions, etc.):
p['two']['num']
'1'
p['two'].getint('num')
1
p['two']['str'] = 'bool is %(bool)s'
p['two']['str']
'bool is true'
p['two']['bool'] = 'false'
p['two']['str']
'bool is false'
Because the section proxy object follows the dict API very closely, it's
trivial to convert a section to a dict:
dict(p['two'])
{'str': 'bool is false', 'bool': 'false', 'num': '1'}
Note, however, that this sets in stone interpolations and doesn't provide
built-in type conversions.
--
assignee: - lukasz.langa
resolution: - works for me
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20943
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20906] Issues in Unicode HOWTO
Changes by A.M. Kuchling a...@amk.ca: -- nosy: -akuchling ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20906 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20898] Missing 507 response description
Changes by Daniel Andrade Groppe x16...@gmail.com: Removed file: http://bugs.python.org/file34433/issue20898.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20898 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20898] Missing 507 response description
Daniel Andrade Groppe added the comment: Here goes the patch once again, this time with the changes to the documentation. Two files were modified: 1. /Lib/http/client.py 2. /Doc/library/http.client.rst Hope this helps until a decision is made on how to remove duplicate codes in http.clinet and http.server -- Added file: http://bugs.python.org/file34450/issue20898_with_doc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20898 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20937] test_socket: buffer overflow in sock_recvmsg_guts
Jeffrey Walton added the comment: This might be relevant. It showed up while building Python 3.3.5 from sources. /usr/local/bin/clang -fsanitize=undefined -fPIC -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I./Include -I. -IInclude -I/usr/local/include -IPython-3.3.5/./Include -IPython-3.3.5/. -c Python-3.3.5/./Modules/socketmodule.c -o build/temp.linux-x86_64-3.3Python-3.3.5/./Modules/socketmodule.o Python-3.3.5/./Modules/socketmodule.c:1951:74: warning: comparison of unsigned expression 0 is always false [-Wtautological-compare] if (cmsgh == NULL || msg-msg_control == NULL || msg-msg_controllen 0) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20937 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20953] heap-buffer-overflow in obmalloc.c:987
New submission from Jeffrey Walton: This came from Python 3.3.5 downloaded from thePython download page (). The issue occurred while compiling with Clang 3.4 using the address sanitizer (-fsanitize=address) /usr/local/bin/clang -fsanitize=address -Xlinker -export-dynamic -o python Modules/python.o libpython3.3m.a -ldl -lutil /usr/local/ssl/lib/libssl.a /usr/local/ssl/lib/libcrypto.a -ldl -lm ./python -E -S -m sysconfig --generate-posix-vars = ==24064==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61904020 at pc 0x4ed4b2 bp 0x7fff80fff010 sp 0x7fff80fff008 READ of size 4 at 0x61904020 thread T0 #0 0x4ed4b1 in PyObject_Free Python-3.3.5/./Objects/obmalloc.c:987 #1 0x7a2141 in code_dealloc Python-3.3.5/./Objects/codeobject.c:359 #2 0x620c00 in PyImport_ImportFrozenModuleObject Python-3.3.5/./Python/import.c:1098 #3 0x620d5c in PyImport_ImportFrozenModule Python-3.3.5/./Python/import.c:1114 #4 0x63fd07 in import_init Python-3.3.5/./Python/pythonrun.c:206 #5 0x63f636 in _Py_InitializeEx_Private Python-3.3.5/./Python/pythonrun.c:369 #6 0x681d77 in Py_Main Python-3.3.5/./Modules/main.c:648 #7 0x4e6894 in main Python-3.3.5/././Modules/python.c:62 #8 0x2abf9a525eac in __libc_start_main /home/aurel32/eglibc/eglibc-2.13/csu/libc-start.c:244 #9 0x4e664c in _start (Python-3.3.5/./python+0x4e664c) AddressSanitizer can not describe address in more detail (wild memory access suspected). SUMMARY: AddressSanitizer: heap-buffer-overflow Python-3.3.5/./Objects/obmalloc.c:987 PyObject_Free Shadow bytes around the buggy address: 0x0c327fff87b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c327fff87c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c327fff87d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c327fff87e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c327fff87f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =0x0c327fff8800: fa fa fa fa[fa]fa fa fa fa fa fa fa fa fa fa fa 0x0c327fff8810: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c327fff8820: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c327fff8830: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c327fff8840: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c327fff8850: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone:fb Freed heap region: fd Stack left redzone:f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return:f5 Stack use after scope: f8 Global redzone:f9 Global init order: f6 Poisoned by user: f7 ASan internal: fe ==24064==ABORTING make: *** [pybuilddir.txt] Error 1 -- components: Build messages: 213788 nosy: Jeffrey.Walton priority: normal severity: normal status: open title: heap-buffer-overflow in obmalloc.c:987 versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20953 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14332] Better explain junk concept in difflib doc
Alba Magallanes added the comment: I would like to help with this issue. I'm attaching a patch for it. -- keywords: +patch nosy: +albamagallanes Added file: http://bugs.python.org/file34451/issue14332.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14332 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20265] Bring Windows docs up to date
Nick Coghlan added the comment: Sorry I haven't had a chance to review this myself, but it would also be good if we could mention the free Python Tools for Visual Studio addon that Microsoft publish (https://pytools.codeplex.com/). That may be better handled as a separate patch/issue though. (My apologies if that has already been mentioned in the updated docs) -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20265 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20785] Missing symbols in Python27.lib (Windows 64bit)
Alexey Pavlov added the comment: For peoples who interesting in supporting building Python with mingw-w64 compiler I can get some links. More than a year ago we start providing our own builds of Python 2.7+3.3 builded with mingw-w64 compiler. I'm developer of MSYS2 project - modern fork of Cygwin with MSYS functionality + pacman package manager (ported from Arch Linux). You can easily build your own Python with mingw-w64 using our patches that include patches from Roumen Petrov (rpetrov) and our own. Python-2.7.6 patches: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python2 Python-3.3.3 patches: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python3 Also you can get prebuilded python and other mingw-w64 packages using MSYS2 with pacman. Regards, Alexey. -- nosy: +Alexey.Pavlov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20785 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
