[issue15502] Meta path finders and path entry finders are different, but share an ABC
Eric Snow added the comment: Backwards compatibility requirements still apply to the importlib API - while the default import system won't call FileFinder.find_module() any more, third party import reimplementations are still free to do so. Except that a good portion of the importlib API is new in 3.3, including FileFinder. I've removed the changes to the 3 default meta path finders don't belong in the patch. -- Added file: http://bugs.python.org/file26642/issue15502_new_abc.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15502 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15502] Meta path finders and path entry finders are different, but share an ABC
Changes by Eric Snow ericsnowcurren...@gmail.com: Removed file: http://bugs.python.org/file26641/issue15502_new_abc.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15502 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14814] Implement PEP 3144 (the ipaddress module)
Eli Bendersky added the comment: Attaching an updated patch that completes the documentation of network objects (attributes, methods and operations). Additionally, inserted the provisional package note and a new in 3.3 notice. -- Added file: http://bugs.python.org/file26643/ipaddr_refdoc_network.2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15502] Meta path finders and path entry finders are different, but share an ABC
Nick Coghlan added the comment: Fair point. However, the find_module() variant of the API isn't dead yet, so we should still support it. find_module() likely won't die completely until 4.0. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15502 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13072] Getting a buffer from a Unicode array uses invalid format
STINNER Victor added the comment: Should we do something before Python 3.3 final? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13072 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13119] Newline for print() is \n on Windows, and not \r\n as expected
STINNER Victor added the comment: On Windows, stdin, stdout and stderr are creates using TextIOWrapper(..., newline=None). In this case, TextIOWrapper._writenl is os.linesep and so '\r\n'. Oh, I was wrong: stdin is created with newline=None, but stdout and stderr are created with newline=\n and so \n is not translated to \r\n. I checked in Python 2.7: print(abc) and sys.stdout.write(abc\n) writes babc\r\n into the output file (when the output is redirected), but sys.stdout.write(abc\r\n) writes babc\r\r\n. Python 3.3 should do the same: \r\n is preferred on Windows (ex: notepad doesn't support UNIX line ending, \n). Attached patch changes line ending for stdout and stderr on Windows: translate \n to \r\n. It would be nice to fix this before Python 3.3 final. -- keywords: +patch nosy: +georg.brandl priority: normal - release blocker Added file: http://bugs.python.org/file26644/windows_stdout_newline.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13119 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12073] regrtest: use faulthandler to dump the tracebacks on SIGUSR1
STINNER Victor added the comment: The change was already done in another issue. I'm closing this one. changeset: 71315:30f91fbfc8b3 user:Victor Stinner victor.stin...@haypocalc.com date:Wed Jul 13 23:47:21 2011 +0200 files: Lib/test/regrtest.py description: Issue #12550: regrtest displays the Python traceback on SIGALRM or SIGUSR1 -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12073 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15213] _PyOS_URandom documentation
STINNER Victor added the comment: So can we close this issue, or should we start to document private functions? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15213 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13992] Segfault in PyTrash_destroy_chain
Manu Cupcic added the comment:
I am also hitting this issue.
I have been able to reproduce it in python 2.5 and 2.7, on debian 6 (64 bits)
Exactly like the reporter, I am making extensive use of threads. I am also
using SQLalchemy.
All my threads but one are waiting (probably for the GIL) :
(gdb) info threads
15 Thread 0x7fffe3ff7700 (LWP 419) 0x77bd03c0 in sem_wait () from
/lib/libpthread.so.0
14 Thread 0x7fffe47f8700 (LWP 418) 0x77bd03c0 in sem_wait () from
/lib/libpthread.so.0
13 Thread 0x7fffe4ff9700 (LWP 417) 0x77bd03c0 in sem_wait () from
/lib/libpthread.so.0
12 Thread 0x7fffe57fa700 (LWP 416) 0x77bd03c0 in sem_wait () from
/lib/libpthread.so.0
11 Thread 0x7fffe5ffb700 (LWP 415) 0x77bd03c0 in sem_wait () from
/lib/libpthread.so.0
* 10 Thread 0x7fffe67fc700 (LWP 414) 0x0046479f in _Py_ForgetReference
(op=0x4dc7bc0)
at Objects/object.c:
9 Thread 0x7fffe6ffd700 (LWP 413) 0x77bd03c0 in sem_wait () from
/lib/libpthread.so.0
8 Thread 0x7fffe77fe700 (LWP 412) 0x77bd03c0 in sem_wait () from
/lib/libpthread.so.0
7 Thread 0x7fffe7fff700 (LWP 411) 0x77bd03c0 in sem_wait () from
/lib/libpthread.so.0
6 Thread 0x7fffec81c700 (LWP 410) 0x772a11a3 in select () from
/lib/libc.so.6
5 Thread 0x7fffed01d700 (LWP 409) 0x77bd03c0 in sem_wait () from
/lib/libpthread.so.0
4 Thread 0x7fffed81e700 (LWP 408) 0x77bd03c0 in sem_wait () from
/lib/libpthread.so.0
3 Thread 0x7fffee01f700 (LWP 407) 0x77bd03c0 in sem_wait () from
/lib/libpthread.so.0
2 Thread 0x7fffee820700 (LWP 406) 0x7729c9d3 in poll () from
/lib/libc.so.6
1 Thread 0x77fec700 (LWP 393) 0x772a11a3 in select () from
/lib/libc.so.6
And the segfault happens in _Py_ForgetReference :
(gdb) bt
#0 0x0046479f in _Py_ForgetReference (op=0x4dc7bc0) at
Objects/object.c:
#1 0x00464810 in _Py_Dealloc (op=0x4dc7bc0) at Objects/object.c:2242
#2 0x00559a68 in frame_dealloc (f=0x4997ab0) at
Objects/frameobject.c:458
#3 0x0046481d in _Py_Dealloc (op=0x4997ab0) at Objects/object.c:2243
...
probably because something else zeroed out the op object :
(gdb) select-frame 0
(gdb) print *op
$6 = {_ob_next = 0x0, _ob_prev = 0x0, ob_refcnt = 0, ob_type = 0x2364020}
Is there something else I can do to help resolve this bug ? I can help
debugging this, but I am not sure how to proceed. I have a --with-pydebug
interpreter stopped at the segfault in gdb.
--
nosy: +cupcicm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13992
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15520] Document datetime.timestamp() in 3.3 What's New
New submission from Dirkjan Ochtman: It seems nice if datetime.timestamp() would be mentioned in the What's New. Does that seem acceptable? I'm happy to whip up a patch. -- assignee: docs@python components: Documentation messages: 167096 nosy: djc, docs@python priority: normal severity: normal status: open title: Document datetime.timestamp() in 3.3 What's New versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15520 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15488] Closed files keep their buffer alive
Serhiy Storchaka added the comment: Agree with Meador. -- nosy: +storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15488 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8847] crash appending list and namedtuple
Roundup Robot added the comment: New changeset 5a8c5631463f by Martin v. Löwis in branch '2.7': Issue #8847: Disable COMDAT folding in Windows PGO builds. http://hg.python.org/cpython/rev/5a8c5631463f -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15521] Dev Guide should say how to run tests in 2.7
New submission from Chris Jerdonek: The Dev Guide should say the preferred way (or even a way) to run tests using the Python 2.7 build: http://docs.python.org/devguide/runtests.html This will help submitters who want to check that their patch works with 2.7. In Python 2.7, this did not work (for obvious reasons): $ ./python.exe -m test .../python.exe: No module named test.__main__; 'test' is a package and cannot be directly executed But this did: $ ./python.exe -m test.regrtest Is the latter the preferred way? -- assignee: docs@python components: Devguide, Documentation keywords: easy messages: 167099 nosy: cjerdonek, docs@python, ezio.melotti priority: normal severity: normal stage: needs patch status: open title: Dev Guide should say how to run tests in 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15521 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8847] crash appending list and namedtuple
Roundup Robot added the comment: New changeset 2638ce032151 by Martin v. Löwis in branch '3.2': Issue #8847: Disable COMDAT folding in Windows PGO builds. http://hg.python.org/cpython/rev/2638ce032151 New changeset 029cde4e58c5 by Martin v. Löwis in branch 'default': Issue #8847: Disable COMDAT folding in Windows PGO builds. http://hg.python.org/cpython/rev/029cde4e58c5 New changeset d3afe5d8a4da by Martin v. Löwis in branch 'default': Issue #8847: Merge with 3.2 http://hg.python.org/cpython/rev/d3afe5d8a4da -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8847] crash appending list and namedtuple
Martin v. Löwis added the comment: Thanks for the research and the fix! -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15510] textwrap.wrap('') returns empty list
Chris Jerdonek added the comment: I verified that this patch can be applied to 2.7 and that those tests pass as well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15521] Dev Guide should say how to run tests in 2.7
Ezio Melotti added the comment: FWIW this is already mentioned in the quick start [0]. Do you want to propose a patch for runtest.rst? [0]: http://docs.python.org/devguide/#quick-start -- type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15521 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15521] Dev Guide should say how to run tests in 2.7
Chris Jerdonek added the comment: FWIW this is already mentioned in the quick start [0]. I didn't catch that, thanks. Do you want to propose a patch for runtest.rst? Sure. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15521 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15037] curses.unget_wch and test_curses fail when linked with ncurses 5.7 and earlier
STINNER Victor added the comment: To debug this issue, it would help to have the following information: - locale encoding: encoding variable - tested character: ch - character read by ncurses: read Can someone reproducing the issue try to add: print(encoding=%s, ch=%r, read=%r % (encoding, ch, read)) before the error? It may be an issue in the Python implementation of unget_wch() or get_wch(). -- I believe the problem is due to a sign-extension bug in the ncurses library unget_wch function (see link below). Can we workaround this issue in Python? For example, use value 0xff? -- The test should be modified to use the encoding of stdscr, not the locale encoding: encoding = stdscr.encoding. (In this test, both encodings should be the same.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15037 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8847] crash appending list and namedtuple
STINNER Victor added the comment: You didn't add any test for non regression?? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15522] impove 27 percent performance on stringpbject.c( by prefetch and loop optimization)
New submission from abael:
Python-2.7.3/Objects/stringobject.c( SHA256SUM
ad7795c75e2a25247e4dea4cc5327c225c4da03b7c7d57226c817ba6d12a316c)
static PyObject *string_join(PyStringObject *self, PyObject *orig);
OLD IMPLEMENT LOGIC(Pseudo code):
char *sep = PyString_AS_STRING(self);
const Py_ssize_t seplen = PyString_GET_SIZE(self);
seq = PySequence_Fast(orig, );
seqlen = PySequence_Size(seq);
if (seqlen == 0)
return PyString_FromString();
else if (seqlen == 1)return the exactly first one item;
else{
for (i = 0; i seqlen; i++) {
const size_t old_sz = sz;
item = PySequence_Fast_GET_ITEM(seq, i);
if (!PyString_Check(item)){
if ( Py_USING_UNICODE and PyUnicode_Check(item))
return PyUnicode_Join((PyObject *)self, seq);
else PyErr_Format(...);
}
sz += PyString_GET_SIZE(item);
if (i != 0)
sz += seplen;
}
}
/* Allocate result space. */
res = PyString_FromStringAndSize((char*)NULL, sz);
/* Catenate everything. */
p = PyString_AS_STRING(res);
for (i = 0; i seqlen; ++i) {
size_t n;
item = PySequence_Fast_GET_ITEM(seq, i);
n = PyString_GET_SIZE(item);
Py_MEMCPY(p, PyString_AS_STRING(item), n);
p += n;
if (i seqlen - 1) {
Py_MEMCPY(p, sep, seplen);
p += seplen;
}
}
Abael's IMPLEMENT LOGIC:
char *sep = PyString_AS_STRING(self);
const Py_ssize_t seplen = PyString_GET_SIZE(self);
seq = PySequence_Fast(orig, );
seqlen = PySequence_Size(seq);
if (seqlen == 0)
return PyString_FromString();
if (seqlen == 1)
return the exactly first one item;
if (seqlen 0)return NULL
/ PREFETCH start, get the first item size, since here we can
assume seqleng = 2 /
register size_t sz=0;
register size_t old_sz=0;
PyObject *res = NULL;
item = PySequence_Fast_GET_ITEM(seq, 0);
if (!PyString_Check(item)){
if ( Py_USING_UNICODE and PyUnicode_Check(item))
return PyUnicode_Join((PyObject *)self, seq);
else PyErr_Format(...);
}
sz += PyString_GET_SIZE(item);
if (sz old_sz || sz PY_SSIZE_T_MAX)
PyErr_SetString(PyExc_OverflowError,join() result is too long for a Python
string);
/ PREFETCH end, get the first item size, since here we can assume
seqleng = 2 /
register Py_ssize_t i;
for (i=1; i seqlen; i++) { / then here we can loop start from 1
/
const size_t old_sz = sz;
item = PySequence_Fast_GET_ITEM(seq, i);
if (!PyString_Check(item)){
if ( Py_USING_UNICODE and PyUnicode_Check(item))
return PyUnicode_Join((PyObject *)self, seq);
else PyErr_Format(...);
}
sz += PyString_GET_SIZE(item);
sz += seplen; / now we don't need to test (i != 0) every loop
/
}
/* Allocate result space. */
res = PyString_FromStringAndSize((char*)NULL, sz);
/* Catenate everything. */
/ PREFETCH start, memcpy the first item first, since here we can
assume seqleng = 2 /
register char *p = PyString_AS_STRING(res);
item = PySequence_Fast_GET_ITEM(seq, 0);
sz = PyString_GET_SIZE(item);
Py_MEMCPY(p, PyString_AS_STRING(item),sz);
p += sz;
/ PREFETCH end, memcpy the first item first, since here we can
assume seqleng = 2 /
for (i=1; iseqlen; ++i){ / here we also loop start from 1 /
item = PySequence_Fast_GET_ITEM(seq, i);
sz = PyString_GET_SIZE(item);
Py_MEMCPY(p, sep, seplen); / avoid test (i seqlen - 1) each
loop in old implement /
p += seplen;
Py_MEMCPY(p, PyString_AS_STRING(item),sz);
p += sz;
}
return res;
--
components: Library (Lib)
messages: 167107
nosy: abael
priority: normal
severity: normal
status: open
title: impove 27 percent performance on stringpbject.c( by prefetch and loop
optimization)
type: performance
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15522
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15522] impove 27 percent performance on stringpbject.c( by prefetch and loop optimization)
Changes by abael hyj...@gmail.com: -- components: +Interpreter Core -Library (Lib) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15522 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15521] Dev Guide should say how to run tests in 2.7
Chris Jerdonek added the comment: Attaching a patch for review. -- keywords: +patch stage: needs patch - patch review Added file: http://bugs.python.org/file26645/issue-15521-1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15521 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15523] Block on close TCP socket in SocketServer.py
New submission from Jarvis: In the Python 2.4, it closes the socket only by calling request.close() method. There is a risk by using this method to close socket. If the socket handle count does not reach zero because another process still has a handle to the socket then the connection is not closed and the socket is not deallocated. So in Python 2.7 it updates it by calling request.shutdown() first, which can close the underlying connection and send a FIN/EOF to the peer regardless of how many processes have handles to the socket. After that, it calls request.close() to deallocate the socket. You can see this updates below that is from the file of C:\Python27\Lib\SocketServer.py. def shutdown_request(self, request): Called to shutdown and close an individual request. try: #explicitly shutdown. socket.close() merely releases #the socket and waits for GC to perform the actual close. request.shutdown(socket.SHUT_WR) except socket.error: pass #some platforms may raise ENOTCONN here self.close_request(request) However,it will block at self.close_request(request) after request.shutdown(socket.SHUT_WR) if there are remaining data on reading side of socket. Here, it calls request.shutdown() with SHUT_WR flag, which means it only shuts down the writing side of the socket. The reading side of the socket isn't shut down at same time. So when calling close_request to deallocate the socket, it will always be waiting to read response until response data is available. It seems like an issue in SokcetServer.py library. In terms of that, I replaced the SHUT_WR flag with SHUT_RDWR (shut down both reading and writing sides of the socket) for request.shutdown method. Then this issue was resolved, the SSL connection was closed immediately. -- messages: 167110 nosy: jarvisliang priority: normal severity: normal status: open title: Block on close TCP socket in SocketServer.py type: enhancement versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15523 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13072] Getting a buffer from a Unicode array uses invalid format
Stefan Krah added the comment:
Is it possible without too much effort to keep the old behavior
('u' - Py_UNICODE)? Then I'd say that should go into 3.3.
The problem with the current behavior is that it's neither backwards
compatible nor PEP-3118 compliant.
If it is too much work to restore the status quo, we could leave this
change with the excuse that 'u' is probably not used very often.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13072
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13072] Getting a buffer from a Unicode array uses invalid format
STINNER Victor added the comment:
Here is a patch reverting changes of the PEP 393, as suggested by Martin von
Loewis. With the patch, array uses Py_UNICODE* type for the 'u' format. So
array.array('u', '\u0010')[0] should return '\uDBFF' on Windows.
--
keywords: +patch
Added file: http://bugs.python.org/file26646/array_revert_pep393.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13072
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8847] crash appending list and namedtuple
Martin v. Löwis added the comment: You didn't add any test for non regression?? Please rephrase your question: what tests did I not add? I did add the tests that Stefan proposed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15231] update PyPI upload doc to say --no-raw passed to rst2html.py
Chris Jerdonek added the comment: Please backport and leave open for distutils2. Éric, is there a place where updates to the distutils2 docs can be viewed and made prior to reinclusion in the main Python repo? For example, the documentation here: http://packages.python.org/Distutils2/devresources.html#documentation suggests that the documentation is in a docs/source directory of this repo: http://hg.python.org/distutils2 but I don't seem to see the documentation there. Or do all changes need to wait for reinclusion? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15231 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13992] Segfault in PyTrash_destroy_chain
Charles-François Natali added the comment: Is there something else I can do to help resolve this bug ? I can help debugging this, but I am not sure how to proceed. I have a --with-pydebug interpreter stopped at the segfault in gdb. Could you post the output of : p op and thread apply all bt -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13992] Segfault in PyTrash_destroy_chain
Manu Cupcic added the comment: (gdb) p op $12 = (PyObject *) 0x4dc7bc0 thread all apply bt is going to be very long no ? Could you tell me what you want to know that is not in info threads maybe ? I can definitely post it here, but it's going to be a lot of output. I can be available on IRC if you want to debug it live. Thanks ! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15524] Dict items() ordering varies across interpreter invocations
New submission from Dmitry Dvoinikov:
The following line prints different things each time you run it:
python3 -c print(', '.join({ '1': '2', '3': '4' }.keys()))
The output is either 1, 3 or 3, 1. Is such indeterministic behavior
intentional ?
Using Python 3.3.0b1 (default, Aug 1 2012, 06:09:44)
--
components: Interpreter Core
messages: 167116
nosy: ddvoinikov
priority: normal
severity: normal
status: open
title: Dict items() ordering varies across interpreter invocations
type: behavior
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15524
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15488] Closed files keep their buffer alive
Antoine Pitrou added the comment: This has to wait for 3.4, since it's an enhancement, not a bug. -- versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15488 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15213] _PyOS_URandom documentation
Antoine Pitrou added the comment: The comment needs to be fixed before the issue is closed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15213 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13072] Getting a buffer from a Unicode array uses invalid format
Stefan Krah added the comment: The diff between b9558df8cc58 and default with array_revert_pep393.patch applied is small, but I noticed that in some places you switched back to Py_UNICODE typecode and in others not. For instance, in struct arraydescr typecode is still char. I'm not sure why typecode was originally Py_UNICODE though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13072 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8847] crash appending list and namedtuple
STINNER Victor added the comment: Please rephrase your question: what tests did I not add? I did add the tests that Stefan proposed. Ah yes, you added new tests to Python 3.2 and 3.3, but no to Python 2.7. Why not adding these new tests to Python 2.7? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15524] Dict items() ordering varies across interpreter invocations
Antoine Pitrou added the comment: Yes, because hash randomization is now enabled by default: http://docs.python.org/dev/reference/datamodel.html#object.__hash__ If you want deterministic behaviour, just set e.g. PYTHONHASHSEED=0. (or any other fixed value) -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15524 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13072] Getting a buffer from a Unicode array uses invalid format
STINNER Victor added the comment:
The diff between b9558df8cc58 and default with array_revert_pep393.patch
applied is small, but I noticed that in some places you switched back to
Py_UNICODE typecode and in others not.
I just copied code from Python 3.2, I forgot to update typecode type
(Py_UNICODE = char). I attach a new patch which changes also the
documentation of the u format.
--
Added file: http://bugs.python.org/file26647/array_revert_pep393-2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13072
___diff -r d3afe5d8a4da Doc/library/array.rst
--- a/Doc/library/array.rst Wed Aug 01 11:09:55 2012 +0200
+++ b/Doc/library/array.rst Wed Aug 01 14:43:35 2012 +0200
@@ -21,7 +21,7 @@ defined:
+---++---+---+---+
| ``'B'`` | unsigned char | int | 1 |
|
+---++---+---+---+
-| ``'u'`` | Py_UCS4| Unicode character | 4 |
|
+| ``'u'`` | Py_UNICODE | Unicode character | 2 |
\(1) |
+---++---+---+---+
| ``'h'`` | signed short | int | 2 |
|
+---++---+---+---+
@@ -35,9 +35,9 @@ defined:
+---++---+---+---+
| ``'L'`` | unsigned long | int | 4 |
|
+---++---+---+---+
-| ``'q'`` | signed long long | int | 8 |
\(1) |
+| ``'q'`` | signed long long | int | 8 |
\(2) |
+---++---+---+---+
-| ``'Q'`` | unsigned long long | int | 8 |
\(1) |
+| ``'Q'`` | unsigned long long | int | 8 |
\(2) |
+---++---+---+---+
| ``'f'`` | float | float | 4 |
|
+---++---+---+---+
@@ -47,6 +47,11 @@ defined:
Notes:
(1)
+ The ``'u'`` type code corresponds to Python's unicode character
+ (:c:type:`Py_UNICODE` which is :c:type:`wchar_t`). Depending on the
+ platform, it can be 16 bits or 32 bits.
+
+(2)
The ``'q'`` and ``'Q'`` type codes are available only if
the platform C compiler used to build Python supports C :c:type:`long long`,
or, on Windows, :c:type:`__int64`.
diff -r d3afe5d8a4da Modules/arraymodule.c
--- a/Modules/arraymodule.c Wed Aug 01 11:09:55 2012 +0200
+++ b/Modules/arraymodule.c Wed Aug 01 14:43:35 2012 +0200
@@ -174,25 +174,24 @@ BB_setitem(arrayobject *ap, Py_ssize_t i
static PyObject *
u_getitem(arrayobject *ap, Py_ssize_t i)
{
-return PyUnicode_FromOrdinal(((Py_UCS4 *) ap-ob_item)[i]);
+return PyUnicode_FromUnicode(((Py_UNICODE *) ap-ob_item)[i], 1);
}
static int
u_setitem(arrayobject *ap, Py_ssize_t i, PyObject *v)
{
-PyObject *p;
+Py_UNICODE *p;
+Py_ssize_t len;
-if (!PyArg_Parse(v, U;array item must be unicode character, p))
+if (!PyArg_Parse(v, u#;array item must be unicode character, p, len))
return -1;
-if (PyUnicode_READY(p))
-return -1;
-if (PyUnicode_GET_LENGTH(p) != 1) {
+if (len != 1) {
PyErr_SetString(PyExc_TypeError,
array item must be unicode character);
return -1;
}
if (i = 0)
-((Py_UCS4 *)ap-ob_item)[i] = PyUnicode_READ_CHAR(p, 0);
+((Py_UNICODE *)ap-ob_item)[i] = p[0];
return 0;
}
@@ -444,13 +443,6 @@ d_setitem(arrayobject *ap, Py_ssize_t i,
return 0;
}
-#if SIZEOF_INT == 4
-# define STRUCT_LONG_FORMAT I
-#elif SIZEOF_LONG == 4
-# define STRUCT_LONG_FORMAT L
-#else
-# error Unable to get struct format for Py_UCS4
-#endif
/* Description of types.
*
@@ -460,7 +452,7 @@ d_setitem(arrayobject *ap, Py_ssize_t i,
static struct arraydescr descriptors[] = {
{'b', 1, b_getitem, b_setitem, b, 1, 1},
{'B', 1, BB_getitem, BB_setitem, B, 1, 0},
-{'u', sizeof(Py_UCS4), u_getitem, u_setitem, STRUCT_LONG_FORMAT, 0, 0},
+{'u', sizeof(Py_UNICODE), u_getitem, u_setitem, u, 0, 0},
{'h', sizeof(short), h_getitem, h_setitem, h, 1, 1},
{'H', sizeof(short), HH_getitem, HH_setitem, H, 1, 0},
{'i', sizeof(int), i_getitem, i_setitem, i, 1, 1},
@@ -1519,26 +1511,25 @@ This method is deprecated. Use tobytes i
static PyObject *
array_fromunicode(arrayobject
[issue15524] Dict items() ordering varies across interpreter invocations
Changes by Antoine Pitrou pit...@free.fr: -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15524 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15522] impove 27 percent performance on stringpbject.c( by prefetch and loop optimization)
Antoine Pitrou added the comment: Hi, several points: - Python 2.7 is in bugfix mode; you need to work from the default Mercurial branch as explained in http://docs.python.org/devguide/ . In practice, this means your patch will target the future Python 3.4, and therefore either PyUnicode_Join or _PyBytes_Join. - please provide an actual patch (a Mercurial diff, probably) - please provide benchmarks (using e.g. timeit) which demonstrate the performance improvement you are proposing -- nosy: +pitrou versions: +Python 3.4 -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15522 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15425] Another strange Tracebacks with importlib
Nick Coghlan added the comment: Indeed, there are still a couple of Windows failures, but they aren't related to this. -- status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15425 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15525] test_multiprocessing failure on Windows XP
New submission from Nick Coghlan: test_multiprocessing failed on one of the XP buildbots with a permission error: http://buildbot.python.org/all/builders/x86%20XP-4%203.x/builds/7223/steps/test/logs/stdio The immediate rerun also failed, but the one at the end of the test run succeeded. -- components: Library (Lib) keywords: buildbot messages: 167125 nosy: georg.brandl, ncoghlan, sbt priority: release blocker severity: normal stage: needs patch status: open title: test_multiprocessing failure on Windows XP type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15525 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13072] Getting a buffer from a Unicode array uses invalid format
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13072 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8847] crash appending list and namedtuple
Martin v. Löwis added the comment: Ah yes, you added new tests to Python 3.2 and 3.3, but no to Python 2.7. Why not adding these new tests to Python 2.7? The tests don't crash Python 2.7. So they are not useful as a test whether the bug has been worked-around. I actually don't know how to test this compiler bug in Python 2.7 (except for writing specific C code that tries to trigger the bug). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15526] regrtest crash on Windows 7 AMD64
New submission from Nick Coghlan: regrtest bailed out completely on one of the Windows 7 builders due to a problem with accessing the temporary working directory: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/410/steps/test/logs/stdio It's seems a touch suspicious that test_fork1 just so happened to be the test executed right before test_startfile blew up. Not marking as a blocker yet, since my initial assumption is that it's a race condition with a particular sequence of tests rather than a problem in Python itself. I'll change my mind if it happens again on the rebuild I just forced. -- components: Tests keywords: buildbot messages: 167126 nosy: georg.brandl, ncoghlan priority: normal severity: normal status: open title: regrtest crash on Windows 7 AMD64 type: crash versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15526 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15519] finish exposing WindowsRegistryImporter in importlib
Changes by Nick Coghlan ncogh...@gmail.com: -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15519 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15526] regrtest crash on Windows 7 AMD64
Antoine Pitrou added the comment: Well, test_startfile seems to be a common issue on that buildbot. -- nosy: +jeremy.kloth, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15526 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15522] impove 27 percent performance on stringpbject.c( by prefetch and loop optimization)
Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15522 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15519] finish exposing WindowsRegistryImporter in importlib
Antoine Pitrou added the comment: I'm not sure why some finders are named Finder and others Importer. It makes things confusing. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15519 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15510] textwrap.wrap('') returns empty list
Antoine Pitrou added the comment: Uh, how is this a bug? An empty text doesn't contain lines at all, so returning an empty list of lines sounds right. Furthermore, by fixing this, you may break existing software. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15520] Document datetime.timestamp() in 3.3 What's New
Antoine Pitrou added the comment: Yes, of course. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15520 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15496] harden directory removal for tests on Windows
Jeremy Kloth added the comment: I must also add that the proposed solution works well within the test suite as the access denied error can also occur when creating subsequent files, not just removing them. This solution eliminates the need to wrap all creation calls with access denied handling, a huge plus IMHO. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15496 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15526] regrtest crash on Windows 7 AMD64
Jeremy Kloth added the comment: Well, test_startfile seems to be a common issue on that buildbot. I wouldn't really call it common (twice in the last 30 runs). However I would wager that the PermissionError is being caused by an unknown (without having Process Monitor running when the error occurs) process temporarily grabbing a handle to a file/directory within the tests temporary directory. This just reinforces the need for the solution in issue15496 to be applied. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15526 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15502] Meta path finders and path entry finders are different, but share an ABC
Barry A. Warsaw added the comment: I've mostly run out of time to work on the docs, but I do want to say that I thought long and hard about all the terminology decisions. Please don't change them lightly, and definitely don't change them until you've tried to go through the documentation and make all the updates and read through them to see how well it flows and makes sense. It is *not* easy. On Aug 01, 2012, at 05:13 AM, Eric Snow wrote: (importer == finder + loader) sounds fine with me. That's how I tried to think about it. In some sense, it's just an implementation detail, but where it comes into the play for the documentation is the path importer, which is the thing on sys.meta_path that implements all the sys.path/sys.path_hooks/sys.path_importer_cachesigh semantics. While technically a finder, calling it the path finder just does not work, IMHO. It's too confusing and causes the documentation to be less comprehensible. So the one compromise I made was to call this thing the path importer because I think conceptually, if not strictly implementation-wise, that term ties everything together. A diagram would seal the deal I think. I'm find with changing path importer to path finder. If no one does a patch first, I'll put one up tomorrow. Please don't, for reasons stated above! I actually prefer path entry handler for the distinctiveness, but I'm fine with leaving it be. However, I get a sense that this is our one shot at this decision. I don't think handler is a very good term. These things *are* finders, even if the API they support is richer and slightly different than meta path finders. Also, I think path entry handler could almost be just as useful for the things on sys.path_hooks, although I do use path entry hook here. But in a sense the callables on sys.path_hooks also handle path entries, just in a different way. I think path entry finder neatly describes both its similarities and differences from other objects in the picture. I'm going to leave all the abc names and implementations to you guys. :) Thanks for all your excellent feedback and your own work on this nasty little corner of Python. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15502 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15496] harden directory removal for tests on Windows
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +brian.curtin stage: - patch review versions: +Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15496 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15519] finish exposing WindowsRegistryImporter in importlib
Brett Cannon added the comment: The importers can both find and load modules (e.g. BuiltinImporter defines both find_module() and load_module()), while the finders only find modules (e.g. only define find_module()). It's defined in the glossary, so maybe more links to that would help. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15519 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15519] finish exposing WindowsRegistryImporter in importlib
Antoine Pitrou added the comment: The importers can both find and load modules (e.g. BuiltinImporter defines both find_module() and load_module()), while the finders only find modules (e.g. only define find_module()). Ah, fair enough. I thought loader objects were always distinct from finders. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15519 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15527] Double parents in functions references
New submission from Serhiy Storchaka: :c:func:`PyMem_Malloc(n)` on Doc/c-api/memory.rst:109 rendered in HTML as tt class=xref c c-func docutils literalspan class=prePyMem_Malloc(1)()/span/tt (note double parents). There are many other examples on this and other pages. The issue is actual for all modern versions of Python. -- assignee: docs@python components: Documentation messages: 167137 nosy: docs@python, storchaka priority: normal severity: normal status: open title: Double parents in functions references versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15527 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15502] Meta path finders and path entry finders are different, but share an ABC
Brett Cannon added the comment: So just to weigh in on this, I think meta path finder and path entry finder (as Barry stated in the glossary already) clearly delineate what is from sys.meta_path and what is from some path entry hook by having a clarifying word to go with finder (either kind of finder is still trying to find a loader). Finder/loader/importer has history in terms of usage so we can't muck with these terms too much. This does mean, though, that PathFinder and FileFinder are misnamed. Unfortunately PathFinder existed in previous versions of Python, so it will need an alias to its old name from a new name (PathImporter as Barry wants or MetaPathEntryFinder?). But FileFinder is new, so that can be renamed to FilePathEntryFinder (or FileEntryFinder). And of course WindowsRegistryImporter should be changed to *Finder. I think if we harp on the meta path vs. path entry and use it consistently and extensively then the finder/loader/importer terminology does not need to change meaning and we don't have to misuse it for path importer to classify PathFinder while keeping the rest of Barry's terms intact which make it obvious when something is directly because of how import works vs. just a single meta path finder that happens to be what nearly everyone ends up using to handle their imports. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15502 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6308] termios fix for QNX breaks HP-UX
Dirkjan Ochtman added the comment: Can we have someone take a look at this? It seems fairly innocuous. -- nosy: +djc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6308 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15521] Dev Guide should say how to run tests in 2.7
Ezio Melotti added the comment: Thanks for the patch. I'm not sure it's necessary to add a new section though, unless you are planning to add more differences there. +base command instead of the one described above: :: You can just use ... above:: here. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15521 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15527] Double parens in functions references
Changes by Antoine Pitrou pit...@free.fr: -- title: Double parents in functions references - Double parens in functions references ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15527 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15468] Edit docs to hide hashlib.md5()
Daniel Holth added the comment: re-tweak treatment of md5 in hashlib docs (the SHA-2 family is currently recommended by http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html) -- Added file: http://bugs.python.org/file26648/hashlib.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15468 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15528] Better support for finalization with weakrefs
New submission from Richard Oudkerk: A patch with docs and tests for the idea I suggested on python-ideas: http://comments.gmane.org/gmane.comp.python.ideas/15863 To repeat what I wrote there, the current issues with weakref callbacks include: 1. They are rather low level, and working out how to use them correctly requires a bit of head scratching. One must find somewhere to store the weakref till after the referent is dead, and without accidentally keeping the referent alive. Then one must ensure that the callback frees the weakref (without leaving any remnant ref-cycles). When it is an option, using a __del__ method is far less hassle. 2. Callbacks invoked during interpreter shutdown are troublesome. For instance they can throw exceptions because module globals have been replaced by None. 3. Sometimes you want the callback to be called at program exit even if the referent is still alive. 4. Exceptions thrown in callbacks do not produce a traceback. This can make debugging rather awkward. (Maybe this is because printing tracebacks is problematic during interpreter shutdown?) (Note that problems 2-4 also apply to using __del__ methods.) Trivial usage of the class looks like class Kenny: pass ... kenny = Kenny() finalize(kenny, print, you killed kenny!) finalize.finalize object at 0xffed4f2c del kenny you killed kenny! -- files: finalize.patch keywords: patch messages: 167142 nosy: sbt priority: normal severity: normal stage: patch review status: open title: Better support for finalization with weakrefs type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file26649/finalize.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15528 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15529] PyIter_Check evaluates to 0 for Python list object
New submission from Tom Tromey: I was debugging this bug reported against gdb: http://sourceware.org/bugzilla/show_bug.cgi?id=14386 It turns out that what went wrong in this code was that PyIter_Check evaluates to 0 when its argument is a Python list. This happens because the PyIter_Check macro looks at the tp_iternext field; but this field is 0 in PyList_Type. I am not sure of the correct fix; but PyIter_Check is not faithfully reflecting what PyObject_GetIter does. Maybe it isn't intended to; but anyway it seems that checking tp_iter would maybe be a better approximation. Even if PyIter_Check remains as-is, I think it would be nice if the documentation were more specific about what it actually does. FWIW I'm modifying gdb not to use this function. -- components: None messages: 167143 nosy: tromey priority: normal severity: normal status: open title: PyIter_Check evaluates to 0 for Python list object versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15529 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15529] PyIter_Check evaluates to 0 for Python list object
Benjamin Peterson added the comment: That's because lists are iterators not iterable. -- nosy: +benjamin.peterson resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15529 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15525] test_multiprocessing failure on Windows XP
Roundup Robot added the comment: New changeset b99a82bc2cde by Richard Oudkerk in branch 'default': Issue #15525: Increase timeout when TerminateProcess() fails http://hg.python.org/cpython/rev/b99a82bc2cde -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15525 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15525] test_multiprocessing failure on Windows XP
Richard Oudkerk added the comment: I would guess that the process has already terminated (or is being torn down) but the timeout is not long enough to let the parent join child. Let's see if increasing the timeout fixes the failures. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15525 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15502] Meta path finders and path entry finders are different, but share an ABC
Eric Snow added the comment: @Barry: I'm fine with what you've said. My big concern is that we be really consistent here because of the complexity of the import system. Things are at a point that I think we're pretty close in the regard, so I'm mostly fine if we stay put. My only real regret would likely be path importer vs. PathFinder, but I can live with it. :) @Brett: I'll update my patch for WindowsRegistryImporter and FileFinder. @anyone: do the doc-based deprecations in the patch look okay? The inheritance model? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15502 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15519] finish exposing WindowsRegistryImporter in importlib
Eric Snow added the comment: Also, WindowsRegistryImporter is misnamed. It should be WindowsRegistryFinder (see issue15502). Depending on the patch there, I'll update the one here. -- dependencies: +Meta path finders and path entry finders are different, but share an ABC ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15519 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15519] finish exposing WindowsRegistryImporter in importlib
Eric Snow added the comment: I guess the real question here is if anyone has problems with adding WindowsRegistryFinder to importlib.machinery (and to the importlib docs). If it should stay private than I'd like to throw a _ on the name of the class. The change to importlib.abc would likely stay either way. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15519 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15519] finish exposing WindowsRegistryImporter in importlib
Brett Cannon added the comment: It should be exposed (i.e. if SourcelessFileLoader is documented and exposed then so should WindowsRegistryFinder). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15519 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15502] Meta path finders and path entry finders are different, but share an ABC
Brett Cannon added the comment: The patch will have Finder break all subclasses that don't define find_loader which is backwards-incompatible. And if you really want to deprecate Finder you should have a warning in an __init__ method (as one would hope people are calling super() as necessary). Otherwise the patch looks fine (from a cursory glance). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15502 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15463] test_faulthandler can fail if install path is too long
Roundup Robot added the comment: New changeset 6e03f9b72c61 by Victor Stinner in branch 'default': Issue #15463: Write a test for faulthandler truncating the name of functions http://hg.python.org/cpython/rev/6e03f9b72c61 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15463 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15463] test_faulthandler can fail if install path is too long
STINNER Victor added the comment: I added a test checking that faulthandler truncates strings to MAX_STRING_LENGTH characters using a very long function name. I consider this issue as done. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15463 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14811] decoding_fgets() truncates long lines and fails with a SyntaxError(Non-UTF-8 code starting with...)
STINNER Victor added the comment: Are we going to fix this before 3.3? Any objections to Victor's patch? detect_truncate.patch is now raising an error if a line is longer than BUFSIZ, whereas Python supports lines longer than BUFSIZ bytes (it's just that the encoding cookie is ignored if the line 1 or 2 is longer than BUFSIZ bytes). So my patch is not correct. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14811 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15479] Allow MAX_STRING_LENGTH limits to be changed at runtime
STINNER Victor added the comment: Sounds totally overkill to me. I changed the maximum length of a string to 500 characters instead of 100. It should be enough for most cases. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15479 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15213] _PyOS_URandom documentation
STINNER Victor added the comment: The comment needs to be fixed before the issue is closed. Ah yes, here is a patch updating the comment of _PyOS_URandom() and the doc of the os module. -- keywords: +patch Added file: http://bugs.python.org/file26650/urandom_doc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15213 ___diff -r 2dd1b056d663 Doc/library/os.rst --- a/Doc/library/os.rstWed Aug 01 14:53:22 2012 +0200 +++ b/Doc/library/os.rstWed Aug 01 15:34:07 2012 +0200 @@ -3331,5 +3331,5 @@ Miscellaneous Functions This function returns random bytes from an OS-specific randomness source. The returned data should be unpredictable enough for cryptographic applications, though its exact quality depends on the OS implementation. On a Unix-like - system this will query /dev/urandom, and on Windows it will use CryptGenRandom. - If a randomness source is not found, :exc:`NotImplementedError` will be raised. + system this will query ``/dev/urandom``, and on Windows it will use + :c:func:`CryptGenRandom`. diff -r 2dd1b056d663 Python/random.c --- a/Python/random.c Wed Aug 01 14:53:22 2012 +0200 +++ b/Python/random.c Wed Aug 01 15:34:07 2012 +0200 @@ -219,8 +219,9 @@ lcg_urandom(unsigned int x0, unsigned ch } } -/* Fill buffer with size pseudo-random bytes, not suitable for cryptographic - use, from the operating random number generator (RNG). +/* Fill buffer with size pseudo-random bytes from the operating random number + generator (RNG). It is suitable for for most cryptographic purposes except + long living private keys for asymmetric encryption. Return 0 on success, raise an exception and return -1 on error. */ int ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15441] test_posixpath fails on Japanese edition of Windows
Roundup Robot added the comment: New changeset 3edc71ed19e7 by Victor Stinner in branch 'default': Issue #15441: Skip test_nonascii_abspath() of test_genericpath on Windows http://hg.python.org/cpython/rev/3edc71ed19e7 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15441] test_posixpath fails on Japanese edition of Windows
STINNER Victor added the comment: This issue (the test) should be fixed, see the issue #15478 for the real fix. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15463] test_faulthandler can fail if install path is too long
Chris Jerdonek added the comment: I didn't want to write such test, but I can review a patch adding such test. Victor, did you see and review my patch? There is currently no test to check that a long file path (longer than 100 characters) will render, which was the original issue that was fixed. The patch provides such a test. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15463 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15463] test_faulthandler can fail if install path is too long
STINNER Victor added the comment: Victor, did you see and review my patch? There is currently no test to check that a long file path (longer than 100 characters) will render, which was the original issue that was fixed. The patch provides such a test. Yes, I saw your patch, but I don't want to create very long filename. Not all platforms support paths longer than 500 characters. It is exactly the same code to display function name and file names. I prefer to use a very long function name, it's simple and portable. My patch is different than yours: it checks that the string is truncated, not that string shorter than the limit are not truncated. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15463 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15530] Enhance Py_MIN and Py_MAX
New submission from STINNER Victor: Attached patch enhances Py_MIN and Py_MAX to check that types of both arguments are compatible at compile time. Checks are only done if the compiler is GCC. The patch uses also Py_MIN and Py_MAX in more places. (The commit may be done in two parts.) -- components: Interpreter Core files: py_min_max.patch keywords: patch messages: 167161 nosy: haypo priority: normal severity: normal status: open title: Enhance Py_MIN and Py_MAX versions: Python 3.3 Added file: http://bugs.python.org/file26651/py_min_max.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15530 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15463] test_faulthandler can fail if install path is too long
Chris Jerdonek added the comment: Yes, I saw your patch, but I don't want to create very long filename. Not all platforms support paths longer than 500 characters. I think you may have a slight misunderstanding. My patch was not meant to test paths over 500 characters. It tests a path *under* 500 characters (but slightly over 100 characters). And it has the same style and portability characteristics as the existing .*threading.py tests. My patch is different than yours: it checks that the string is truncated, not that string shorter than the limit are not truncated. Yes, your patch is different in two ways. :) It tests function names instead of paths, and length 500 instead of 100 length 500. I think there is value in adding a file path test because code changes over time, so it may not always be using the same code path as function names. I agree that it is okay to leave out a file path test for longer than 500 characters for the portability reasons you stated. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15463 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15531] os.path symlink docs missing
New submission from Dave Abrahams: the docs for os.path don't mention the following facts which I think are important (in fact I assumed the facts would be the reverse): os.path.realpath(l) works when l is a broken symbolic link, returning the path to the (missing) target os.path.readlink(l) causes an error when l is a broken symbolic link. -- assignee: docs@python components: Documentation messages: 167163 nosy: dabrahams, docs@python priority: normal severity: normal status: open title: os.path symlink docs missing type: enhancement versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15531 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15529] PyIter_Check evaluates to 0 for Python list object
Brett Cannon added the comment: I think Benjamin meant to say lists are iterables not iterators. =) -- nosy: +brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15529 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13072] Getting a buffer from a Unicode array uses invalid format
Stefan Krah added the comment: array_revert_pep393-2.patch looks good (checked against 7042a83f37e and all following commits that should be kept). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13072 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15500] Python should support naming threads
Christian Heimes added the comment: +1 win32 supports thread names, too. http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx -- nosy: +christian.heimes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15500 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15468] Edit docs to hide hashlib.md5()
Changes by Christian Heimes li...@cheimes.de: -- nosy: +christian.heimes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15468 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15510] textwrap.wrap('') returns empty list
Chris Jerdonek added the comment: Here are additional test cases impacted by this issue: wrap( ) [] wrap(\n\n\n) [] wrap(\n\n\n, replace_whitespace=False) [] wrap( \n\n, replace_whitespace=False) [] -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15530] Enhance Py_MIN and Py_MAX
Martin v. Löwis added the comment: I think that's too late for 3.3. It's not a bug fix. If we use this kind of feature, we either need to declare a minimum supported GCC version (any GCC older than 10 years can be dropped IMO), or check for the specific version of GCC in which all the necessary features were present. Did you detect any errors in the Python code using this change? Wouldn't the compiler refuse to perform the comparison if the types were not compatible? -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15530 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9635] Add Py_BREAKPOINT and sys._breakpoint hooks
Dave Malcolm added the comment: Note to self: a messy way of forcing gdb to do the equivalent of a breakpoint directly from Python is: os.kill(os.getpid(), signal.SIGTRAP) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9635 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15532] for line in file is *still* broken in Python 2.7
New submission from Andy Lutomirski: This program: import subprocess, sys p = subprocess.Popen(['bash', '-c', 'while true; do echo x; sleep 1; done'], bufsize=0, stdout=subprocess.PIPE) for line in p.stdout: sys.stdout.buffer.write(line) sys.stdout.flush() sits around and does nothing on Python 2.7.3. It works (i.e. prints 'x' once per second) on Python 3. This was http://bugs.python.org/issue3907 and is supposedly fixed, but it's not. -- components: IO messages: 167170 nosy: Andy.Lutomirski priority: normal severity: normal status: open title: for line in file is *still* broken in Python 2.7 type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15532 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15502] Meta path finders and path entry finders are different, but share an ABC
Nick Coghlan added the comment: As a final attempt at giving the path import machinery the emphasis it deserves without misusing the importer term, how about: 1. path import subsystem for that whole section of the import machinery; and 2. path import finder specifically for the meta path finder that importlib calls PathFinder and the new docs currently call path importer path_importer_cache would still be a bit of a misnomer, but that ship sailed a long time ago. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15502 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15530] Enhance Py_MIN and Py_MAX
STINNER Victor added the comment: I think that's too late for 3.3. It's not a bug fix. Oops, I chose 3.3 instead of 3.4. Fixed. If we use this kind of feature, we either need to declare a minimum supported GCC version typeof() and __builtin_types_compatible_p() were introduced to gcc in version 3.0 and 3.1.1. Do we plan to support GCC older than 3.1? :-) (any GCC older than 10 years can be dropped IMO) GCC 3.1 was released 10 years ago. It's cheap to add a test on the GCC version to fallback on the simple xy?x:y macro, but I don't know exactly which GCC versions are supported and I don't want to install a very old GCC version just to check this. Did you detect any errors in the Python code using this change? Nope. But it avoids at least to evaluate an expression twice (if an argument is not a variable or a number, but a complex expression... like most new PyUnicode_*() macros). Even if I prefer to avoid expressions in macro arguments... Wouldn't the compiler refuse to perform the comparison if the types were not compatible? I don't know exactly how __builtin_types_compatible_p() compare types. At least, I can say that int and unsigned int are considered as incompatible. -- The Linux kernel uses (void) (_min1 == _min2); to check that types are compatible. I suppose that this expression is written for GCC. GCC only emits a warning, I chose Py_BUILD_ASSERT_EXPR() to emit an error instead. -- versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15530 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13072] Getting a buffer from a Unicode array uses invalid format
STINNER Victor added the comment:
@Georg: are you ok with this change? It reverts the behaviour of Python 3.2 and
avoids to have to maintain an API that nobody wants to use ('u' format using
Py_UCS4, 32 bits unsigned).
--
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13072
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15502] Meta path finders and path entry finders are different, but share an ABC
Barry A. Warsaw added the comment: On Aug 01, 2012, at 10:03 PM, Nick Coghlan wrote: 1. path import subsystem for that whole section of the import machinery; and 2. path import finder specifically for the meta path finder that importlib calls PathFinder and the new docs currently call path importer -0. To me, this doesn't make things vastly more clear for the additional awkwardness in readability. path_importer_cache would still be a bit of a misnomer, but that ship sailed a long time ago. Yeah, we all agree that one's unfortunate! ;) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15502 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1521950] shlex.split() does not tokenize like the shell
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk: -- versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1521950 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14713] PEP 414 installation hook fails with an AssertionError
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk: -- versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14713 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15525] test_multiprocessing failure on Windows XP
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15525 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15525] test_multiprocessing failure on Windows XP
STINNER Victor added the comment: Let's see if increasing the timeout fixes the failures. At least, the 3 following builds succeed (let's see the next builds). -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15525 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
