[issue22766] collections.Counter's in-place operators should return NotImplemented for unsupported types
Raymond Hettinger added the comment:
Sorry, I don't want to change the kind of exception being raised (an API change
from AttributeError to TypeError) without a really good reason.
In general, in-place methods are not required to return NotImplemented (for
example, (3).__iadd__(4.5) raises an AttributeError).
Also, I prefer the current AttributeError with its clear indication that an
items() method is needed for duck-typing. These kind of error messages are
very helpful when you're trying to figure-out how to duck-type on-purpose (for
example, {}.update(1) and {}.update([[]]) both provide the information about
what you would need to do to get update() to work).
The current duck-typeable behavior was an intended part of the design and is no
different from a number of other methods that update in-place.
FWIW, I do recognize that in the specific case of counter += 1 a TypeError is
clearer than an AttributeError. However, for duck-typeable methods, an
AttributeError can sometimes be useful to indicate what is actually being
required of the other argument (for example, Python 2 old-style classes raise
an AttributeError with an informative message when calling an instance without
a __call__ method or indexing an instance without a __getitem__ method).
At any rate, I want to avoid unnecessary API churn (and avoid contributing to
what Guido has called a death by a thousand cuts for the growing list of tiny
semantic differences between Python 2 and Python 3).
--
resolution: - not a bug
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22766
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22755] contextlib.closing documentation should use a new example
Raymond Hettinger added the comment: Can a different example be chosen? The traditional examples (urllib, socket, StringIO) grow context manager support as soon as the need becomes apparent. So, that leaves only user-defined classes, third-party classes, generators, and cases where we already have a competing context manager that does something other than close. A reasonable candidate is an sqlite connection. It is a legitimate use case for contextlib.closing() since connections need to be closed after use, and because they already are context managers that do something different than closing (the commit or rollback transactions). A generator example would work, but closing generators is a rare and esoteric need (not many people even realize than you *can* close a generator), so this would make a bad example. A user defined class can add its own __enter__ and __exit__ to close if needed, so it isn't common to use contextlib.closing() on your own classes. The primary use case is for third-party classes where you don't control the source code and a closing context manager isn't present; however, those make for bad examples because they aren't in the standard library (i.e. aren't familiar) and because the better maintained modules are also adding context manager support. Out of all of these, only the sqlite connection example seems to be durable (won't go away) and familiar (in the standard library and not an exotic feature). That said, I think it would be best to stick with the simplest and most familiar possible examples even if they are no longer needed. The purpose of the example is to show how closing() works. We can use the surrounding text to indicate that the example is no longer necessary and that the most common remain uses are to add closing() behavior to third-party code you don't control (if you do control the code, then adding CM support directly to the class would be preferable). -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22755 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22721] pprint output for sets and dicts is not stable
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- assignee: - rhettinger versions: -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22721 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21650] add json.tool option to avoid alphabetic sort of fields
Raymond Hettinger added the comment: To me, --unsorted implies arbitrary ordering such as the order generated by regular dictionaries. I think the option should be --order-preserving or some such. The option name needs to make it clear that the output is in the same order an the input. As side from the option name, I'm +1 on the patch. It is very annoying to look at scrambled JSON when the original presentation order made more logical sense. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21650 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22718] pprint not handline uncomparable dictionary keys, set members well
Raymond Hettinger added the comment: Complex numbers also aren't sortable. I'm not sure this is worth fixing in 2.7. I agree. That ship sailed a long time ago. -- nosy: +rhettinger resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22718 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21650] add json.tool option to avoid alphabetic sort of fields
Serhiy Storchaka added the comment: May be make sorting keys not default? -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21650 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21650] add json.tool option to avoid alphabetic sort of fields
Raymond Hettinger added the comment: Maybe make sorting keys not default? If you mean preserve order by default, then yes that would be a nice default. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21650 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22721] pprint output for sets and dicts is not stable
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- assignee: rhettinger - fdrake ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22721 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22777] Test pickling with all protocols
Serhiy Storchaka added the comment: Fixed two bugs found by Antoine. Thank you Antoine. Berker suggest to use the subTest() context manager inside loops. I thought about this, but this will increase blocks indentations on yet 4 spaces, and some code already is too indented. On other hand this truly helps when tests fail. Large part of the patch is related to the code maintained by Raymond (collections and itertools modules, builtin collections and iterators), so it would be good if Raymond will look on it. -- Added file: http://bugs.python.org/file37095/tests_pickling_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22777 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22775] SimpleCookie not picklable with HIGHEST_PROTOCOL
Serhiy Storchaka added the comment: Test pickling with all protocols (see issue22777), not only with HIGHEST_PROTOCOL. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22775 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6623] Lib/ftplib.py Netrc class should be removed.
Roundup Robot added the comment: New changeset ec196a99af8d by Berker Peksag in branch 'default': Issue #6623: Remove deprecated Netrc class in the ftplib module. https://hg.python.org/cpython/rev/ec196a99af8d -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6623 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6623] Lib/ftplib.py Netrc class should be removed.
Berker Peksag added the comment: Thanks for the patch, Matt. Have you signed a contributor's agreement? You can find it at https://www.python.org/psf/contrib/contrib-form/ -- assignee: - berker.peksag priority: release blocker - normal resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6623 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22665] shutil.__all__ incomplete
Berker Peksag added the comment: I agree with Martin. Plus, this method already used by other tests (see Lib/test/test_nntplib.py and Lib/test/test_warnings.py for example). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22665 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22665] shutil.__all__ incomplete
Roundup Robot added the comment: New changeset 232520144c6c by Berker Peksag in branch '3.4': Issue #22665: Add missing get_terminal_size and SameFileError to shutil.__all__. https://hg.python.org/cpython/rev/232520144c6c New changeset 193ac288bc7f by Berker Peksag in branch 'default': Issue #22665: Add missing get_terminal_size and SameFileError to shutil.__all__. https://hg.python.org/cpython/rev/193ac288bc7f -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22665 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22665] shutil.__all__ incomplete
Berker Peksag added the comment: Thanks for the report, Martin. -- resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22665 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20069] Add unit test for os.chown
Vajrasky Kok added the comment: Here is the patch based on R. David Murray's review. Thanks! Thanks also for the work of Cormac O'Brien. -- Added file: http://bugs.python.org/file37096/add_unit_test_os_chown_v6.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20069 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19610] setup.py does not allow a tuple for classifiers
Berker Peksag added the comment: Updated patch. I've tweaked tests and documentation a bit. Alternatively, I can leave Doc/distutils/setupscript.rst untouched and add a whatsnew entry to Doc/whatsnew/3.5.rst. -- Added file: http://bugs.python.org/file37097/issue19610_v2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19610 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22770] test_ttk_guionly and test_tk can cause Tk segfaults on OS X when run with regrtest -j option
Ned Deily added the comment: Ah, Issue18604! Thanks for the reminder (and for the patch), Serhly! Focusing on these more recent occurrences of segfaults, I hadn't been thinking about those earlier ones. Now, after digging into Tk and identifying the problem there, it's clear that those earlier segfaults reported in Issue18604 were a result of the same Tk bug, just caused slightly differently from the tkinter tests. The #18604 changes also caused a Tcl interpreter instance to be created and destroyed without actually causing Tk to do enough to cause the open application Apple event to be fired and received. _is_gui_available is the right place and adding the additional Tk activity there does it at the right time. And it appears that root.update() is sufficient, as you suggested. I want to do some additional testing but, assuming no problems are found, I'll plan to apply the simplified patch. -- assignee: - ned.deily stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22770 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12458] Tracebacks should contain the first line of continuation lines
Serhiy Storchaka added the comment: Here is yet one example. x = 1; y = 0; z = 0 ( 1/x + 1/y + 1/z ) The traceback looks correct: Traceback (most recent call last): File 1.py, line 4, in module 1/y + ZeroDivisionError: division by zero But for following code: x = 0; y = 1; z = 0 ( 1/x + 1/y + 1/z ) the traceback is the same and it is totally wrong. This is because generated bytecode is: 1 0 LOAD_CONST 0 (0) 3 STORE_NAME 0 (x) 6 LOAD_CONST 1 (1) 9 STORE_NAME 1 (y) 12 LOAD_CONST 0 (0) 15 STORE_NAME 2 (z) 4 18 LOAD_CONST 1 (1) 21 LOAD_NAME0 (x) 24 BINARY_TRUE_DIVIDE 25 LOAD_CONST 1 (1) 28 LOAD_NAME1 (y) 31 BINARY_TRUE_DIVIDE 32 BINARY_ADD 5 33 LOAD_CONST 1 (1) 36 LOAD_NAME2 (z) 39 BINARY_TRUE_DIVIDE 40 BINARY_ADD 41 POP_TOP 42 LOAD_CONST 2 (None) 45 RETURN_VALUE 1/x and 1/y have the same line number. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12458 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22766] collections.Counter's in-place operators should return NotImplemented for unsupported types
R. David Murray added the comment: I agree with Raymond about the value of the more specific error message. And the point about the in-place operators being qualitatively different from the non-inplace operators is a good one. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22766 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22521] ctypes compilation fails on FreeBSD: Undefined symbol ffi_call_win32
Dmitry Sivachenko added the comment: On modern FreeBSD version (10/stable) on i386 arch it fails with the following error: build/temp.freebsd-10.0-RELEASE-p10-i386-3.4/usr/ports/lang/python34/work/Python-3.4.2/Modules/_ctypes/libffi/src/x86/ffi.o: In function `.LBB4_4': /usr/ports/lang/python34/work/Python-3.4.2/Modules/_ctypes/libffi/src/x86/ffi.c:(.text+0x661): undefined reference to `ffi_closure_THISCALL' build/temp.freebsd-10.0-RELEASE-p10-i386-3.4/usr/ports/lang/python34/work/Python-3.4.2/Modules/_ctypes/libffi/src/x86/ffi.o: In function `.LBB4_3': /usr/ports/lang/python34/work/Python-3.4.2/Modules/_ctypes/libffi/src/x86/ffi.c:(.text+0x673): undefined reference to `ffi_closure_FASTCALL' build/temp.freebsd-10.0-RELEASE-p10-i386-3.4/usr/ports/lang/python34/work/Python-3.4.2/Modules/_ctypes/libffi/src/x86/ffi.o: In function `.LBB4_5': /usr/ports/lang/python34/work/Python-3.4.2/Modules/_ctypes/libffi/src/x86/ffi.c:(.text+0x685): undefined reference to `ffi_closure_STDCALL' /usr/bin/ld: build/lib.freebsd-10.0-RELEASE-p10-i386-3.4/_ctypes.so: hidden symbol `ffi_closure_FASTCALL' isn't defined There is no such a problem on amd64. --with-system-ffi it works fine (system libffi is the same version: 3.0.13) -- nosy: +Dmitry.Sivachenko ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22521 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22780] NotImplemented doc section needs update
Ethan Furman added the comment: Here's the actual change: + Special value which should be returned by the special methods + (:meth:`__eq__`, :meth:`__lt__`, :meth:`__add__`, etc.) to indicate + that the operation is not implemented with respect to the other type. I'll update the Enum docs as well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22780 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19031] Make help() enum aware
Ethan Furman added the comment: Closing this as a duplicate of issue19404. -- resolution: - duplicate status: open - closed superseder: - Simplify per-instance control of help() output ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19031 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14260] re.groupindex is available for modification and continues to work, having incorrect data inside it
Serhiy Storchaka added the comment:
Here are two patches which implement two alternative solutions. They are based
on regex code.
Dict copying patch matches current regex behavior and needs modifying other
code to avoid small slowdown. Artificial example:
$ ./python -m timeit -s 'import re; n = 100; m = re.match(.join((?Pg%d.)
% g for g in range(n)), x * n); t = ,.join(r\gg%d % g for g in
range(n))' -- 'm.expand(t)'
Without patch: 7.48 msec per loop
With re_groupindex_copy.patch but without modifying _expand: 9.61 msec per loop
With re_groupindex_copy.patch and with modifying _expand: 7.41 msec per loop
While stdlib code can be modified, this patch can cause small slowdown of some
third-party code.
Dict proxying patch has no performance effect, but it is slightly less
compatible. Some code can accept dict but not dict-like object.
--
keywords: +patch
Added file: http://bugs.python.org/file37098/re_groupindex_copy.patch
Added file: http://bugs.python.org/file37099/re_groupindex_proxy.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14260
___diff -r 193ac288bc7f Lib/csv.py
--- a/Lib/csv.pySat Nov 01 11:05:36 2014 +0200
+++ b/Lib/csv.pySat Nov 01 16:58:33 2014 +0200
@@ -231,20 +231,21 @@ class Sniffer:
quotes = {}
delims = {}
spaces = 0
+groupindex = regexp.groupindex
for m in matches:
-n = regexp.groupindex['quote'] - 1
+n = groupindex['quote'] - 1
key = m[n]
if key:
quotes[key] = quotes.get(key, 0) + 1
try:
-n = regexp.groupindex['delim'] - 1
+n = groupindex['delim'] - 1
key = m[n]
except KeyError:
continue
if key and (delimiters is None or key in delimiters):
delims[key] = delims.get(key, 0) + 1
try:
-n = regexp.groupindex['space'] - 1
+n = groupindex['space'] - 1
except KeyError:
continue
if m[n]:
diff -r 193ac288bc7f Lib/sre_parse.py
--- a/Lib/sre_parse.py Sat Nov 01 11:05:36 2014 +0200
+++ b/Lib/sre_parse.py Sat Nov 01 16:58:33 2014 +0200
@@ -783,6 +783,7 @@ def parse_template(source, pattern):
del literal[:]
groups.append((len(literals), index))
literals.append(None)
+groupindex = pattern.groupindex
while True:
this = sget()
if this is None:
@@ -806,7 +807,7 @@ def parse_template(source, pattern):
if not name.isidentifier():
raise error(bad character in group name)
try:
-index = pattern.groupindex[name]
+index = groupindex[name]
except KeyError:
msg = unknown group name: {0!r}.format(name)
raise IndexError(msg)
diff -r 193ac288bc7f Lib/test/test_re.py
--- a/Lib/test/test_re.py Sat Nov 01 11:05:36 2014 +0200
+++ b/Lib/test/test_re.py Sat Nov 01 16:58:33 2014 +0200
@@ -493,6 +493,13 @@ class ReTests(unittest.TestCase):
self.assertEqual(re.match((a), a).regs, ((0, 1), (0, 1)))
self.assertTrue(re.match((a), a).re)
+# Issue 14260.
+p = re.compile(r'abc(?Pndef)')
+self.assertEqual(sorted(p.groupindex), [n])
+self.assertEqual(p.groupindex[n], 1)
+p.groupindex[n] = 0
+self.assertEqual(p.groupindex[n], 1)
+
def test_special_escapes(self):
self.assertEqual(re.search(r\b(b.)\b,
abcd abc bcd bx).group(1), bx)
diff -r 193ac288bc7f Modules/_sre.c
--- a/Modules/_sre.cSat Nov 01 11:05:36 2014 +0200
+++ b/Modules/_sre.cSat Nov 01 16:58:33 2014 +0200
@@ -1371,12 +1371,24 @@ static PyMethodDef pattern_methods[] = {
{NULL, NULL}
};
+/* PatternObject's 'groupindex' method. */
+static PyObject *
+pattern_groupindex(PatternObject *self)
+{
+return PyDict_Copy(self-groupindex);
+}
+
+static PyGetSetDef pattern_getset[] = {
+{groupindex, (getter)pattern_groupindex, (setter)NULL,
+ A dictionary mapping group names to group numbers.},
+{NULL} /* Sentinel */
+};
+
#define PAT_OFF(x) offsetof(PatternObject, x)
static PyMemberDef pattern_members[] = {
{pattern,T_OBJECT,PAT_OFF(pattern), READONLY},
{flags, T_INT, PAT_OFF(flags), READONLY},
{groups, T_PYSSIZET, PAT_OFF(groups),READONLY},
-{groupindex, T_OBJECT,PAT_OFF(groupindex),READONLY},
{NULL} /* Sentinel */
};
@@ -1409,6 +1421,7 @@ static PyTypeObject Pattern_Type = {
0, /* tp_iternext */
pattern_methods,/* tp_methods */
pattern_members,/* tp_members */
+
[issue22753] urllib2 localnet Changed test to lookup IP-address of localhost
Wouter van Heyst added the comment: What the patch does is replace the hard-coded address 127.0.0.1 for the loopback interface with a one-time lookup. I'd argue the hunk @@ -315,7 +316,7 @@ should be dropped. The two arguments that motivate this change are: 1) The address of the loopback interface is not always 127.0.0.1, binding to it may fail. 2) The tests seem to assume localhost resolves to the same address where the server is running. Working on this patch started with the ConnectionRefusedError that Håkan mentioned. Applying the patch made the ConnectionRefusedError go away, but I think we may have solved a different problem and suppressed the real problem as a side effect. @r.david.murray: would the patch be acceptable on dropping said hunk, and changing the description to Do not assume localhost resolves to 127.0.0.1? That still leaves, I think, a hidden bug somewhere in the proxy code that will surface in some corner case. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22753 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22775] SimpleCookie not picklable with HIGHEST_PROTOCOL
Tim Graham added the comment: Updated patch to test pickling of all protocols. -- Added file: http://bugs.python.org/file37100/cookie-pickling-all-protocols.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22775 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22781] ctypes: Differing results between Python and C.
New submission from Geoff Clements: I have used ctypes to create a binding to libdvdread but I am getting some bad values back from libdvdread when using python. I have used ctypeslib to generate the python bindings, i.e. h2xml and xml2py and, as far as I can tell, the bind is a faithful representation of the h files. In order to demonstrate this I have created a small C program and a small Python3 program both doing the same thing. When run they should produce the same output but they do not. In order to run these you need a DVD inserted in a DVD drive, I've hard-coded the device path to the DVD drive as /dev/sr0 in both programs so this may need to be changed. -- components: ctypes files: dvdtest.tar.gz messages: 230453 nosy: Geoff.Clements priority: normal severity: normal status: open title: ctypes: Differing results between Python and C. versions: Python 3.4 Added file: http://bugs.python.org/file37101/dvdtest.tar.gz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22781 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22695] open() declared deprecated in python 3 docs
Berker Peksag added the comment: Attached patch should fix the deprecated-removed directive. I've tested it with the following examples: .. deprecated-removed:: 3.4 4.0 The ``'U'`` mode. .. deprecated-removed:: 3.4 4.0 The ``'U'`` mode. .. deprecated-removed:: 3.4 4.0 -- keywords: +patch Added file: http://bugs.python.org/file37102/issue22695.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22695 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22782] Python 3.4.2 Windows installer - cannot install 32 bit then 64 bit version
New submission from Paul Moore: When you install Python 3.4.2 32 bit and 64 bit on the same PC, in that order, the second one you install shows a red error message on the install screen, saying This update will replace your existing Python 3.4 installation, and proceeds to uninstall the 32-bit version before installing. This is even though the two are being installed into different directories. This does not happen if the 64 bit install is done first (which is a huge relief, as otherwise it's not possible to install the 2 versions side by side). -- assignee: steve.dower components: Windows messages: 230455 nosy: pmoore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Python 3.4.2 Windows installer - cannot install 32 bit then 64 bit version type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22782 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22753] urllib2 localnet Changed test to lookup IP-address of localhost
R. David Murray added the comment: The problem is that there are several places in the test suite (and the stdlib itself!) that assume that 127.0.0.1 is a valid loopback address. This is the de-facto Internet standard, and while I know not all systems make 127.0.0.1 a valid loopback and/or do not map localhost to it, I'm not sure this is something it is practical for the stdlib or the test suite to compensate for. (I had this problem with linux-vserver on my buildbots, see issue 3972). It is true that the test suite in in a couple places assumes that 'localhost' maps to 127.0.0.1, which is an assumption that breaks more often than that of 127.0.0.;1 being a a valid loopback, since it depends on the correct configuration of the local host. We've got a catch 22: if we assume localhost maps to a valid loopback address, the tests will fail on systems that are not configured correctly, while if we assume that 127.0.0.1 is a valid loopback address but may not be 'localhost', the tests will fail on systems for which 127.0.0.1 is not a valid loopback. Since the stdlib itself assumes that 127.0.0.1 is valid, the former wins. (As far as I know we don't have any open issues against the stdlib for this assumption. If it is problematic on your system, then you should open a separate issue about that so we can consider it.) If this test fails on your system because 127.0.0.1 is not a loopback address, I would expect many other tests to fail as well (ex: test_ssl). If they do not, then I suspect your real problem is that localhost doesn't map to 127.0.0.1 even though 127.0.0.1 is a valid loopback address. So, it looks to me like the better fix here would be to change 'URL' to be 'http://127.0.0.1'. Can you confirm if that works for you, please? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22753 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14460] In re's positive lookbehind assertion repetition works
Changes by Serhiy Storchaka storch...@gmail.com: -- resolution: - not a bug stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14460 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19046] SystemError: ..\Objects\weakrefobject.c:903: bad argument to internal function
Changes by Serhiy Storchaka storch...@gmail.com: -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19046 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22781] ctypes: Differing results between Python and C.
Antoine Pitrou added the comment: This doesn't directly address your issue, but ctypeslib doesn't seem to have received any changes since 2009 (*), and has never had an official release. For a non-trivial binding, you might be better served using something providing type safety, such as Cython. (*) (which makes it possible that ctypeslib produces bindings not compatible with Python 3, by the way) -- nosy: +meador.inge, pitrou versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22781 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22695] open() declared deprecated in python 3 docs
Changes by Serhiy Storchaka storch...@gmail.com: -- resolution: fixed - stage: - patch review status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22695 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19046] SystemError: ..\Objects\weakrefobject.c:903: bad argument to internal function
Changes by Antoine Pitrou pit...@free.fr: -- resolution: - out of date status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19046 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22776] SyslogHandler's record formatting during emit(..) not covered by try-except block
Roundup Robot added the comment: New changeset 54549f9b2ecc by Vinay Sajip in branch 'default': Closes #22776: Merged fix from 3.4. https://hg.python.org/cpython/rev/54549f9b2ecc -- nosy: +python-dev resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22776 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22776] SyslogHandler's record formatting during emit(..) not covered by try-except block
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk: -- versions: -Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22776 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22776] SyslogHandler's record formatting during emit(..) not covered by try-except block
Vinay Sajip added the comment: N.B. 2.7 and 3.4 also updated, but I accidentally left the issue no. out of the commit message. Relevant changesets are ea7b64406396 and f6a906541476. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22776 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12939] Add new io.FileIO using the native Windows API
Changes by Roumen Petrov bugtr...@roumenpetrov.info: -- nosy: +rpetrov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12939 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22781] ctypes: Differing results between Python and C.
Geoff Clements added the comment: Thanks for the comment Antoine. I understand that ctypeslib is old but it produces relatively mundane python code which is python version agnostic. Well, that's how it looks to me. I have not used cython mainly because it would make the distribution of my code more complex but it may be worth trying if only to point the issue at ctypes or otherwise. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22781 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22773] Export Readline version and expect ANSI sequence for version 0x0600
Changes by David Edelsohn dje@gmail.com: -- title: Export Readline version and expect ANSI sequence for version 0x6000 - Export Readline version and expect ANSI sequence for version 0x0600 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22773 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22782] Python 3.4.2 Windows installer - cannot install 32 bit then 64 bit version
Steve Dower added the comment: The 3.4 installer is still maintained by Martin. -- assignee: steve.dower - nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22782 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15279] Spurious unittest warnings
Ezio Melotti added the comment: I'm going to close this. If someone can reproduce it again, feel free to reopen it. -- resolution: - out of date stage: needs patch - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15279 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16056] shadowed test names in std lib regression tests
Changes by Ezio Melotti ezio.melo...@gmail.com: -- stage: patch review - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16056 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22452] addTypeEqualityFunc is not used in assertListEqual
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22452 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22364] Improve some re error messages using regex for hints
Ezio Melotti added the comment: +1 on the idea. -- stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22364 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22731] test_capi test fails because of mismatched newlines
Changes by Steve Dower steve.do...@microsoft.com: -- resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22731 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22731] test_capi test fails because of mismatched newlines
Roundup Robot added the comment: New changeset edb270e5c9c3 by Steve Dower in branch 'default': #22731 test_capi test fails because of mismatched newlines https://hg.python.org/cpython/rev/edb270e5c9c3 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22731 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16007] Improved Error message for failing re expressions
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16007 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22734] marshal needs a lower stack depth for debug builds on Windows
Roundup Robot added the comment: New changeset c2a3865a59f4 by Steve Dower in branch 'default': #22734 marshal needs a lower stack depth for debug builds on Windows https://hg.python.org/cpython/rev/c2a3865a59f4 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22734 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22732] ctypes tests don't set correct restype for intptr_t functions
Roundup Robot added the comment: New changeset a944fe09fae8 by Steve Dower in branch 'default': #22732 ctypes tests don't set correct restype for intptr_t functions https://hg.python.org/cpython/rev/a944fe09fae8 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22732 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22734] marshal needs a lower stack depth for debug builds on Windows
Changes by Steve Dower steve.do...@microsoft.com: -- resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22734 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22732] ctypes tests don't set correct restype for intptr_t functions
Changes by Steve Dower steve.do...@microsoft.com: -- resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22732 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21931] Nonsense errors reported by msilib.FCICreate for bad argument
Changes by Ezio Melotti ezio.melo...@gmail.com: -- stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21931 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21400] Code coverage documentation is out-of-date.
Changes by Ezio Melotti ezio.melo...@gmail.com: -- stage: - patch review type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21815] imaplib truncates some untagged responses
Ezio Melotti added the comment: Thanks for the patches Lita, however it's better if you can upload a single patch with all the required changes. This will make it easier to apply/review it. -- stage: test needed - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21815 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22781] ctypes: Differing results between Python and C.
eryksun added the comment:
ctypes doesn't always handle bitfields correctly. In particular it doesn't
adapt the storage unit size when packed. A bitfield based on c_uint is always
stored in 4 bytes, even if _pack_ is set to 1. This is MSVC rules, so all is
well on Windows.
For example, from ifo_types.h:
typedef struct {
unsigned int zero_1: 1;
unsigned int multi_or_random_pgc_title : 1; /* 0: one sequential pgc
title */
unsigned int jlc_exists_in_cell_cmd: 1;
unsigned int jlc_exists_in_prepost_cmd : 1;
unsigned int jlc_exists_in_button_cmd : 1;
unsigned int jlc_exists_in_tt_dom : 1;
unsigned int chapter_search_or_play: 1; /* UOP 1 */
unsigned int title_or_time_play: 1; /* UOP 0 */
} ATTRIBUTE_PACKED playback_type_t;
ctypeslib translates this as follows:
class playback_type_t(Structure):
pass
playback_type_t._fields_ = [
('zero_1', c_uint, 1),
('multi_or_random_pgc_title', c_uint, 1),
('jlc_exists_in_cell_cmd', c_uint, 1),
('jlc_exists_in_prepost_cmd', c_uint, 1),
('jlc_exists_in_button_cmd', c_uint, 1),
('jlc_exists_in_tt_dom', c_uint, 1),
('chapter_search_or_play', c_uint, 1),
('title_or_time_play', c_uint, 1),
]
It doesn't set _pack_ = 1, but ctypes wouldn't use that to pack the c_uint
bitfield anyway. It's 4 bytes, either way. MSVC agrees, even with #pragma
pack(1). OTOH, with __attribute__((packed)), gcc packs the bitfield into a
single byte.
The incorrect packing (for gcc) of playback_type_t results in an incorrect
offset for title_set_nr in title_info_t:
class title_info_t(Structure):
pass
title_info_t._pack_ = 1
title_info_t._fields_ = [
('pb_ty', playback_type_t),
('nr_of_angles', uint8_t),
('nr_of_ptts', uint16_t),
('parental_id', uint16_t),
('title_set_nr', uint8_t),
('vts_ttn', uint8_t),
('title_set_sector', uint32_t),
]
As a workaround for the immediate problem, on platforms that use gcc you can
use c_uint8 in playback_type_t instead of c_uint. You'll want to verify other
bitfields as well. I don't know about other compilers on other platforms.
Working at the ABI level can be painful. Consider using CFFI's API level
interface instead:
https://cffi.readthedocs.org
--
nosy: +eryksun
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22781
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22781] ctypes: Differing results between Python and C.
Geoff Clements added the comment:
Thank you eryksun for the explanation. It's much appreciated. I'll take a
look at CFFI.
On 1 Nov 2014 22:38, eryksun rep...@bugs.python.org wrote:
eryksun added the comment:
ctypes doesn't always handle bitfields correctly. In particular it doesn't
adapt the storage unit size when packed. A bitfield based on c_uint is
always stored in 4 bytes, even if _pack_ is set to 1. This is MSVC rules,
so all is well on Windows.
For example, from ifo_types.h:
typedef struct {
unsigned int zero_1: 1;
unsigned int multi_or_random_pgc_title : 1; /* 0: one sequential pgc
title */
unsigned int jlc_exists_in_cell_cmd: 1;
unsigned int jlc_exists_in_prepost_cmd : 1;
unsigned int jlc_exists_in_button_cmd : 1;
unsigned int jlc_exists_in_tt_dom : 1;
unsigned int chapter_search_or_play: 1; /* UOP 1 */
unsigned int title_or_time_play: 1; /* UOP 0 */
} ATTRIBUTE_PACKED playback_type_t;
ctypeslib translates this as follows:
class playback_type_t(Structure):
pass
playback_type_t._fields_ = [
('zero_1', c_uint, 1),
('multi_or_random_pgc_title', c_uint, 1),
('jlc_exists_in_cell_cmd', c_uint, 1),
('jlc_exists_in_prepost_cmd', c_uint, 1),
('jlc_exists_in_button_cmd', c_uint, 1),
('jlc_exists_in_tt_dom', c_uint, 1),
('chapter_search_or_play', c_uint, 1),
('title_or_time_play', c_uint, 1),
]
It doesn't set _pack_ = 1, but ctypes wouldn't use that to pack the c_uint
bitfield anyway. It's 4 bytes, either way. MSVC agrees, even with #pragma
pack(1). OTOH, with __attribute__((packed)), gcc packs the bitfield into a
single byte.
The incorrect packing (for gcc) of playback_type_t results in an incorrect
offset for title_set_nr in title_info_t:
class title_info_t(Structure):
pass
title_info_t._pack_ = 1
title_info_t._fields_ = [
('pb_ty', playback_type_t),
('nr_of_angles', uint8_t),
('nr_of_ptts', uint16_t),
('parental_id', uint16_t),
('title_set_nr', uint8_t),
('vts_ttn', uint8_t),
('title_set_sector', uint32_t),
]
As a workaround for the immediate problem, on platforms that use gcc you
can use c_uint8 in playback_type_t instead of c_uint. You'll want to verify
other bitfields as well. I don't know about other compilers on other
platforms.
Working at the ABI level can be painful. Consider using CFFI's API level
interface instead:
https://cffi.readthedocs.org
--
nosy: +eryksun
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22781
___
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22781
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22697] Deadlock with writing to stderr from forked process
Nir Soffer added the comment: This is a duplicate of http://bugs.python.org/issue6721 -- nosy: +nirs ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22697 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17717] Set up nasm from external.bat
Roundup Robot added the comment: New changeset 28d18fdc52c4 by Zachary Ware in branch '2.7': Issue #17717: Pull NASM from svn.python.org for OpenSSL build. https://hg.python.org/cpython/rev/28d18fdc52c4 New changeset f7ed3e058fca by Zachary Ware in branch '3.4': Issue #17717: Pull NASM from svn.python.org for OpenSSL build. https://hg.python.org/cpython/rev/f7ed3e058fca New changeset ef15b51d59fb by Zachary Ware in branch 'default': Issue #17717: Pull NASM from svn.python.org for OpenSSL build. https://hg.python.org/cpython/rev/ef15b51d59fb -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17717 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22731] test_capi test fails because of mismatched newlines
Steve Dower added the comment:
As near as I can tell, Py_Initialize() is causing the stdout mode to change
from O_TEXT to O_BINARY in _testembed.
Looking at the output in this test, you can see the first printf('\n') (after
'Use defaults') is correctly translated, but the next '\n' comes after
Py_Initialize().
b'--- Use defaults ---\r\n... \r\n--- Set encoding only ---\n...'
I don't really see how this can be avoided without breaking something else to
do with text IO. Probably the documentation for Py_Initialize should get the
note, rather than the What's New section. Py_Initialize has really brief docs,
and I'm certain there are plenty of other little things like this that change
when you call it - is this the right place for compiler-specific caveats like
this? I don't really know where else it could go. Or is it something that we
really do want to fix? (We generally avoid changing global settings like this
where possible.)
--
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22731
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17717] Set up nasm from external.bat
Zachary Ware added the comment: The patches for 2.7 and 3.4 were more trivial than for default, and I was pretty confident in the patch for default, so I went ahead and committed. I did switch around which end of PATH our copy of NASM was added to, to make it easier for someone to override which NASM was used. Thanks for the suggestion John, and thanks for the support Antoine! -- assignee: - zach.ware resolution: - fixed status: open - closed versions: +Python 2.7, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17717 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17717] Set up nasm from external.bat
Changes by Zachary Ware zachary.w...@gmail.com: -- components: +Build nosy: +tim.golden stage: - resolved ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17717 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22770] test_ttk_guionly and test_tk can cause Tk segfaults on OS X when run with regrtest -j option
Roundup Robot added the comment: New changeset bd4dc351d670 by Ned Deily in branch '2.7': Issue #22770: Prevent some Tk segfaults on OS X when running gui tests. https://hg.python.org/cpython/rev/bd4dc351d670 New changeset 121517deb318 by Ned Deily in branch '3.4': Issue #22770: Prevent some Tk segfaults on OS X when running gui tests. https://hg.python.org/cpython/rev/121517deb318 New changeset e119343bc3ec by Ned Deily in branch 'default': Issue #22770: merge from 3.4 https://hg.python.org/cpython/rev/e119343bc3ec -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22770 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22770] test_ttk_guionly and test_tk can cause Tk segfaults on OS X when run with regrtest -j option
Ned Deily added the comment: Applied for release in 2.7.9, 3.4.3, and 3.5.0. -- resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22770 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18604] Consolidate gui available checks in test.support
Ned Deily added the comment: The previous segfaults on OS X have been isolated to a problem in Cocoa Tk and an issue has been opened about it on the Tk issue tracker. See Issue22770 for details. Changesets applied to _is_gui_available() in that issue should prevent the segfaults by ensuring that Tk completes necessary initialization before the Tcl interpreter instance is destroyed and a new one created. So _is_gui_available() is now enabled on OS X and we can close this issue. -- resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18604 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17896] Move Windows external libs from src\..\ to src\externals
Terry J. Reedy added the comment: The patch looks pretty straightforward. Running the revised external.bat and then pcbuild.sln seem to give the same result as before. So this looks ready to me. As to Steve's merge question: since externals is ignored and not part of the python.org repository, it should have no effect on merge or graft. -- stage: patch review - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17896 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18604] Consolidate gui available checks in test.support
Zachary Ware added the comment: Thanks for tracking it down, Ned! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18604 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17896] Move Windows external libs from src\..\ to src\externals
Roundup Robot added the comment: New changeset 62ce0f623154 by Zachary Ware in branch '2.7': Issue #17896: Move Windows external lib sources from .. to externals. https://hg.python.org/cpython/rev/62ce0f623154 New changeset b5e9bc4352e1 by Zachary Ware in branch '3.4': Issue #17896: Move Windows external lib sources from .. to externals. https://hg.python.org/cpython/rev/b5e9bc4352e1 New changeset 64a54f0c87d7 by Zachary Ware in branch 'default': Issue #17896: Move Windows external lib sources from .. to externals. https://hg.python.org/cpython/rev/64a54f0c87d7 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17896 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17896] Move Windows external libs from src\..\ to src\externals
Zachary Ware added the comment: Thanks for the test, Terry. Committed. -- assignee: - zach.ware resolution: - fixed stage: commit review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17896 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
