[issue23673] IntEnum is unpicklable by previous Python versions
New submission from Ethan Furman: IntEnum is advertised as being a drop-in replacement for integer contants; however this fails in the case of unpickling on previous Python versions. This occurs because when a pickle is created the module, class, and value are stored -- but those don't exist prior to Python 3.4. One solution is to modify IntEnum to pickle just like a plain int would, but this has the serious disadvantage of losing the benefits of IntEnum on Python versions that support it. Another solution is to use Serhiy's idea of pickling by name; this would store the module and name to look up in that madule, and this works on all Python versions that have that constant: on Python 3.3 socket.AF_INET returns an integerer (2, I think), and on Python 3.4+ it returns the AF_INET AddressFamily member. -- assignee: ethan.furman keywords: 3.4regression messages: 238148 nosy: barry, eli.bendersky, ethan.furman, serhiy.storchaka priority: normal severity: normal stage: test needed status: open title: IntEnum is unpicklable by previous Python versions type: behavior versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23673 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23187] Segmentation fault, possibly asyncio related
STINNER Victor added the comment: Did you see some errors or warnings when running your application with asyncio in debug mode? No, but I'll try. I doubt the problem is in asyncio itself because it's mostly written in Python. This looks like a garbage collection issue. Sorry, you're wrong: the proactor event loop heavily uses the _overlapped module which is implemented in C. A crash in the garbage collector is more likely a bug in asyncio/your application, than a bug in Python itself. Please enable asyncio debug mode, ResourceWarning, enable DEBUG log level, and check if you get some errors. For example, GetQueuedCompletionStatus() returned an unexpected event usually means that you will quickly get a memory corruption... If possible, write all asyncio logs at DEBUG log level and attach them to the issue. Using the logging module, it's possible to add a custom handler for asyncio. Example: --- import asyncio import logging logging.basicConfig() logger = asyncio.log.logger output = open(asyncio.log, a) handler = logging.StreamHandler(output) handler.setLevel(logging.DEBUG) logger.setLevel(logging.DEBUG) logger.addHandler(handler) asyncio.log.logger.debug(plop) output.close() --- python34_d.dll!PyList_New(__int64 size=0) Line 159 + 0xc bytes So the crash occurred again during a call to PyList_New(0) which triggerred a garbage collection. The backtrace looks more reliable: _PyObject_GC_Malloc(56). msvcr100d.dll!_wassert(const wchar_t * expr=0x63220618, const wchar_t * filename=0x632205e0, unsigned int lineno=364) Line 153 python34_d.dll!update_refs(_gc_head * containers=0x6338cfc0) Line 364 + 0x2b bytes This assertion contains a long comment which explains when the assertion can fail. /* Python's cyclic gc should never see an incoming refcount * of 0: if something decref'ed to 0, it should have been * deallocated immediately at that time. * Possible cause (if the assert triggers): a tp_dealloc * routine left a gc-aware object tracked during its teardown * phase, and did something-- or allowed something to happen -- * that called back into Python. gc can trigger then, and may * see the still-tracked dying object. Before this assert * was added, such mistakes went on to allow gc to try to * delete the object again. In a debug build, that caused * a mysterious segfault, when _Py_ForgetReference tried * to remove the object from the doubly-linked list of all * objects a second time. In a release build, an actual * double deallocation occurred, which leads to corruption * of the allocator's internal bookkeeping pointers. That's * so serious that maybe this should be a release-build * check instead of an assert? */ assert(_PyGCHead_REFS(gc) != 0); To come back to asyncio and the proactor event loop: the implementations of the proactor event loop is still young and probably unstable. Would it be possible to test again with fewer clients (500 clients or less to not hit the select() limit on Windows) with selector event loop? A crash in the garbage collector can be caused by a memory corruption. I fixed a lot of memory corruption caused by internal objects uesd in the proactor event loop. Can you check if asyncio.windows_events._BaseWaitHandleFuture is used? This class is used by IocpProactor.wait_for_handle() which is called by _WindowsSubprocessTransport. But you wrote you the server (where the crash occurs) doesn't run subprocesses. I never tried the proactor event loop with threads. Are you using asyncio code outside the main thread? asyncio is not thread-safe at all :-p Are you using a single event loop or one event loop per thread? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23187 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23187] Segmentation fault, possibly asyncio related
STINNER Victor added the comment: Bugfixes of asyncio 3.4.3, a lot of them are related to the proactor event loop (and most of them leaded to crashes): https://code.google.com/p/tulip/source/browse/ChangeLog#66 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23187 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23668] Support os.[f]truncate on Windows
Steve Dower added the comment: I get a 405 error if I try and upload the patch on http://bugs.python.org/review/23668/ My other patches from last night worked fine, so maybe Rietveld doesn't like this issue for some reason? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23668 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23668] Support os.[f]truncate on Windows
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23668 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23500] Argument Clinic: multiple macro definition
Serhiy Storchaka added the comment:
Yes, this works. Here is combined patch and proceeded sample file.
--
Added file: http://bugs.python.org/file38494/clinic_append_2.patch
Added file: http://bugs.python.org/file38495/sample.c
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23500
___diff -r 642247a536d5 Modules/clinic/spwdmodule.c.h
--- a/Modules/clinic/spwdmodule.c.h Sat Mar 14 20:17:38 2015 -0700
+++ b/Modules/clinic/spwdmodule.c.h Sun Mar 15 09:18:13 2015 +0200
@@ -36,10 +36,6 @@ exit:
#endif /* defined(HAVE_GETSPNAM) */
-#ifndef SPWD_GETSPNAM_METHODDEF
-#define SPWD_GETSPNAM_METHODDEF
-#endif /* !defined(SPWD_GETSPNAM_METHODDEF) */
-
#if defined(HAVE_GETSPENT)
PyDoc_STRVAR(spwd_getspall__doc__,
@@ -64,7 +60,11 @@ spwd_getspall(PyModuleDef *module, PyObj
#endif /* defined(HAVE_GETSPENT) */
+#ifndef SPWD_GETSPNAM_METHODDEF
+#define SPWD_GETSPNAM_METHODDEF
+#endif /* !defined(SPWD_GETSPNAM_METHODDEF) */
+
#ifndef SPWD_GETSPALL_METHODDEF
#define SPWD_GETSPALL_METHODDEF
#endif /* !defined(SPWD_GETSPALL_METHODDEF) */
-/*[clinic end generated code: output=41fec4a15b0cd2a0 input=a9049054013a1b77]*/
+/*[clinic end generated code: output=ab16125c5e5f2b1b input=a9049054013a1b77]*/
diff -r 642247a536d5 Modules/clinic/zlibmodule.c.h
--- a/Modules/clinic/zlibmodule.c.h Sat Mar 14 20:17:38 2015 -0700
+++ b/Modules/clinic/zlibmodule.c.h Sun Mar 15 09:18:13 2015 +0200
@@ -314,10 +314,6 @@ zlib_Compress_copy(compobject *self, PyO
#endif /* defined(HAVE_ZLIB_COPY) */
-#ifndef ZLIB_COMPRESS_COPY_METHODDEF
-#define ZLIB_COMPRESS_COPY_METHODDEF
-#endif /* !defined(ZLIB_COMPRESS_COPY_METHODDEF) */
-
#if defined(HAVE_ZLIB_COPY)
PyDoc_STRVAR(zlib_Decompress_copy__doc__,
@@ -340,10 +336,6 @@ zlib_Decompress_copy(compobject *self, P
#endif /* defined(HAVE_ZLIB_COPY) */
-#ifndef ZLIB_DECOMPRESS_COPY_METHODDEF
-#define ZLIB_DECOMPRESS_COPY_METHODDEF
-#endif /* !defined(ZLIB_DECOMPRESS_COPY_METHODDEF) */
-
PyDoc_STRVAR(zlib_Decompress_flush__doc__,
flush($self, length=zlib.DEF_BUF_SIZE, /)\n
--\n
@@ -450,4 +442,8 @@ exit:
return return_value;
}
-/*[clinic end generated code: output=bc9473721ca7c962 input=a9049054013a1b77]*/
+
+#ifndef ZLIB_COMPRESS_COPY_METHODDEF
+#define ZLIB_COMPRESS_COPY_METHODDEF
+#endif /* !defined(ZLIB_COMPRESS_COPY_METHODDEF) */
+/*[clinic end generated code: output=901c18189767dc08 input=a9049054013a1b77]*/
diff -r 642247a536d5 Modules/posixmodule.c
--- a/Modules/posixmodule.c Sat Mar 14 20:17:38 2015 -0700
+++ b/Modules/posixmodule.c Sun Mar 15 09:18:13 2015 +0200
@@ -17212,10 +17212,6 @@ dump buffer
#define OS_SYSTEM_METHODDEF
#endif /* !defined(OS_SYSTEM_METHODDEF) */
-#ifndef OS_SYSTEM_METHODDEF
-#define OS_SYSTEM_METHODDEF
-#endif /* !defined(OS_SYSTEM_METHODDEF) */
-
#ifndef OS_UNAME_METHODDEF
#define OS_UNAME_METHODDEF
#endif /* !defined(OS_UNAME_METHODDEF) */
@@ -17388,10 +17384,6 @@ dump buffer
#define OS_WAITPID_METHODDEF
#endif /* !defined(OS_WAITPID_METHODDEF) */
-#ifndef OS_WAITPID_METHODDEF
-#define OS_WAITPID_METHODDEF
-#endif /* !defined(OS_WAITPID_METHODDEF) */
-
#ifndef OS_WAIT_METHODDEF
#define OS_WAIT_METHODDEF
#endif /* !defined(OS_WAIT_METHODDEF) */
@@ -17492,10 +17484,6 @@ dump buffer
#define OS_PUTENV_METHODDEF
#endif /* !defined(OS_PUTENV_METHODDEF) */
-#ifndef OS_PUTENV_METHODDEF
-#define OS_PUTENV_METHODDEF
-#endif /* !defined(OS_PUTENV_METHODDEF) */
-
#ifndef OS_UNSETENV_METHODDEF
#define OS_UNSETENV_METHODDEF
#endif /* !defined(OS_UNSETENV_METHODDEF) */
@@ -17603,7 +17591,7 @@ dump buffer
#ifndef OS_SET_HANDLE_INHERITABLE_METHODDEF
#define OS_SET_HANDLE_INHERITABLE_METHODDEF
#endif /* !defined(OS_SET_HANDLE_INHERITABLE_METHODDEF) */
-/*[clinic end generated code: output=52a6140b0b052ce6 input=524ce2e021e4eba6]*/
+/*[clinic end generated code: output=b788c2d6010113e8 input=524ce2e021e4eba6]*/
static PyMethodDef posix_methods[] = {
diff -r 642247a536d5 Tools/clinic/clinic.py
--- a/Tools/clinic/clinic.pySat Mar 14 20:17:38 2015 -0700
+++ b/Tools/clinic/clinic.pySun Mar 15 09:18:13 2015 +0200
@@ -820,7 +820,8 @@ class CLanguage(Language):
cpp_if = #if + conditional
cpp_endif = #endif /* + conditional + */
-if methoddef_define:
+if methoddef_define and f.name not in clinic.ifndef_symbols:
+clinic.ifndef_symbols.add(f.name)
methoddef_ifndef = normalize_snippet(
#ifndef {methoddef_name}
#define {methoddef_name}
@@ -1408,10 +1409,10 @@ class Destination:
self.name = name
self.type = type
self.clinic = clinic
-valid_types = ('buffer', 'file', 'suppress', 'two-pass')
+valid_types = ('buffer', 'file', 'suppress', 'two-pass', 'append')
if
[issue23546] Windows, 'Edit withIDLE', and multplie installed versions
Liam Marsh added the comment: Why run a batch file instead of directly running the .pyw script via pythonw.exe? A batch file is executed by cmd.exe, which is a console application. the strange thing is that it exists -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23546 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23187] Segmentation fault, possibly asyncio related
STINNER Victor added the comment: (Since you chose to comment this closed issue instead of opening a new one, I reopen this issue.) -- resolution: not a bug - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23187 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20680] Pickle socket enums by names
Ethan Furman added the comment: Serhiy, sorry for taking so long to get back to this -- we spent so much time making sure pickling worked I had no idea that unpickling didn't work in prior versions. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20680 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23546] Windows, 'Edit withIDLE', and multplie installed versions
eryksun added the comment: I'd prefer to be able to list them all under the Open With menu, since that also allows users to easily make any of them the default if that's what they'd like. Unfortunately, to do that we need to start shipping an EXE launcher, probably with a unique name (e.g. idle35-32.exe). Can't you just create a ProgID, e.g. IDLE_3.5, that defines the open verb, and add this to the OpenWithProgIds subkey for .py and .pyw? https://msdn.microsoft.com/en-us/library/windows/desktop/hh127445%28v=vs.85%29.aspx -- nosy: +eryksun ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23546 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23546] Windows, 'Edit withIDLE', and multplie installed versions
Steve Dower added the comment: Setting up a progid is my intent, but it will be linked very closely to the executable. Currently it will show up as pythonw.exe and not idle. I didn't try with the batch file, but I'm fairly sure that's failed in the past too. I like the idea of (approximately) using pip to install it though. The generated idle3.5.exe in that case is only going to conflict between the 32/64-bit versions at least. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23546 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22928 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23668] Support os.[f]truncate on Windows
Steve Dower added the comment: Hmm... doesn't even know that the issue has been changed. Reuploading with a different extension. -- Added file: http://bugs.python.org/file38500/23668_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23668 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23546] Windows, 'Edit withIDLE', and multplie installed versions
eryksun added the comment: the windows packages already include an idle.bat launcher next to the idle.py and idle.pyw files. However, this launcher is (strangely enough) not used in the edit with idle command. Why run a batch file instead of directly running the .pyw script via pythonw.exe? A batch file is executed by cmd.exe, which is a console application. I believe the batch was included as a convenient way to start IDLE from the command line with the correct version instead of the default system Python. Nowadays idle.pyw should have an explicit shebang and be installed into Scripts, including a Windows .exe wrapper to make it runnable via CreateProcess. This would already be the case if IDLE were bundled in the same way as setuptools and pip, right? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23546 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23668] Support os.[f]truncate on Windows
Steve Dower added the comment: It normally does... I'll regenerate the patch when I get a chance later today. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23668 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23668] Support os.[f]truncate on Windows
Steve Dower added the comment: Regenerated the patch file. Rietveld may not have liked that the parent changeset in the previous patch doesn't exist (I pulled this out of my patch queue). -- Added file: http://bugs.python.org/file38499/23668_2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23668 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23668] Support os.[f]truncate on Windows
Serhiy Storchaka added the comment: Rietveld doesn't accept patches in git format. -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23668 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23546] Windows, 'Edit withIDLE', and multplie installed versions
Liam Marsh added the comment: to do that we need to start shipping an EXE launcher, probably with a unique name (e.g. idle35-32.exe). nope, the windows packages already include an idle.bat launcher next to the idle.py and idle.pyw files. However, this launcher is (strangely enough) not used in the edit with idle command. Is it, by the way, possible to have that, instead? (you can click on the menu button, OR select an idle) -- Added file: http://bugs.python.org/file38496/dd.bmp ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23546 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23546] Windows, 'Edit withIDLE', and multplie installed versions
Liam Marsh added the comment: (uploaded file: dd.bmp) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23546 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a development platform
Nick Coghlan added the comment: Russell, just checking before I change the issue title: do you mean supporting iOS as a cross-compilation target? Development is ambiguous here, as you could mean development *of* CPython, rather than *in* Python, and I assume development *for* iOS largely takes place on x86_64 Mac OS X, Windows and Linux systems. Slavek, Robert - assuming my understanding of the change is correct, I think would be a very interesting CPython enhancement from a Fedora Workstation perspective. -- nosy: +bkabrda, ncoghlan, rkuska ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23670 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23672] IDLE for osx 10.8.5 won't run
Ned Deily added the comment: Try removing IDLE's recently-used file list: rm ~/.idlerc/recent-files.lst -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23672 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a cross-compilation target
Ned Deily added the comment: Ack, much to consider. Adding doko as I believe he has been most closely following developments with libffi releases. -- nosy: +doko ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23670 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a cross-compilation target
Ned Deily added the comment: As a cross-compilation target. From a first quick look at it, it appears the patch requires a current Mac OS X system to build for iOS; the necessary standard build tools and SDKs for iOS are only available on OS X. These are the same build tools used for OS X builds. We already support universal builds for multiple architectures on OS X directly in one pass; unfortunately, the iOS builds require two different SDKs, one for running on the OS X-based simulator and one for the native platform archs which, I assume, is why Russell has gone for the separate builds for each arch and lipo-ed them together. I don't have an opinion yet about the use of the Setup.local configurations rather than modifying setup.py. I appreciate trying to keep the changes for a patch like this as isolated as possible. But, long term, that might not be the best approach assuming there is eventually agreement to fully support iOS as a standard platform (via cross-compilation). The bulk of the patch is the new version of libffi; presumably that will eventually be released upstream in the standard version of libffi so that having a separate copy wouldn't be required? In any case, as a work-in-progress, the patch is certainly nicely done. -- nosy: +ned.deily, ronaldoussoren title: Modifications to support iOS as a development platform - Modifications to support iOS as a cross-compilation target ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23670 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a cross-compilation target
Russell Keith-Magee added the comment: Nick: you are correct - these are changes to support iOS as a cross-compilation target, so you can run your Python code on an iOS device. Apologies for the confusion in nomenclature. Ned: You're correct that the build needs to be run on an OS/X machine, and needs to be done in multiple passes because of the need for multiple SDKs. I've taken the approach of using Setup.local for two reasons. Firstly, iOS requires a fully embedded Python, because Apple doesn't approve of the use of dynamic loading in apps. Setup.local was the best way I found to force modules to be statically linked into the main library. Secondly, because of the nature of the end-deployment, I imagine it's inevitable that serious end-users will want to customise their Python build for specific applications. AppStore submission rules prohibit running code that wasn't shipped with the app (i.e., Apple won't let you do an end-run around their app approval processes), so the set of modules you're actually using will be a known quantity. Since a full iOS Python build is 34MB or so, much of that bulk will be for binary support of modules that you aren't using, providing an easily configurable way to prune out unused modules from the built product seemed like a useful facility. There's also the issue of providing support for the standard library modules (like SSL) that have dependencies that can't be easily provided or specified out-of-the-box. If there's a better/more palatable approach than using Setup.local, I'm happy to look into it. The libffi code is a direct copy from the current (as of a week or so ago) libffi trunk. There have been some bug fixes applied since 3.2.1 was released in november that are necessary to support ctypes on ARM64 (but, as I flagged in my original comment, introduces bugs for ARMv7). The libffi repo suggests the next version will be 4.0, but I have no idea when that will be finalised. I'm currently trying to get their release plans confirmed. As with OS/X libffi support, the source code needs to be generated, rather than just ./configure make'd. That said, the libffi_darwin code could be re-used, as the x86_64 components are the same for Darwin as the iOS simulator. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23670 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23187] Segmentation fault, possibly asyncio related
Michael Goldish added the comment:
OK, I caught the crash with a debug build of Python 3.4.3.
I have a core dump and even the process itself still alive in memory. I can
provide any information you need. I can also explain how to debug a core dump
with Visual Studio, if necessary.
This time the crash was here:
static void
update_refs(PyGC_Head *containers)
{
PyGC_Head *gc = containers-gc.gc_next;
for (; gc != containers; gc = gc-gc.gc_next) {
assert(_PyGCHead_REFS(gc) == GC_REACHABLE);
_PyGCHead_SET_REFS(gc, Py_REFCNT(FROM_GC(gc)));
/* Python's cyclic gc should never see an incoming refcount
* of 0: if something decref'ed to 0, it should have been
* deallocated immediately at that time.
* Possible cause (if the assert triggers): a tp_dealloc
* routine left a gc-aware object tracked during its teardown
* phase, and did something-- or allowed something to happen --
* that called back into Python. gc can trigger then, and may
* see the still-tracked dying object. Before this assert
* was added, such mistakes went on to allow gc to try to
* delete the object again. In a debug build, that caused
* a mysterious segfault, when _Py_ForgetReference tried
* to remove the object from the doubly-linked list of all
* objects a second time. In a release build, an actual
* double deallocation occurred, which leads to corruption
* of the allocator's internal bookkeeping pointers. That's
* so serious that maybe this should be a release-build
* check instead of an assert?
*/
-- assert(_PyGCHead_REFS(gc) != 0); --- crash
}
}
In the calling frame I can see that update_refs() is called with a PyGC_Head
object whose gc_refs is 0, and according to the paragraph above that shouldn't
happen. A screenshot is attached.
Stack trace:
msvcr100d.dll!_NMSG_WRITE(int rterrnum=10) Line 217
msvcr100d.dll!abort() Line 71
msvcr100d.dll!_wassert(const wchar_t * expr=0x63220618, const wchar_t *
filename=0x632205e0, unsigned int lineno=364) Line 153
python34_d.dll!update_refs(_gc_head * containers=0x6338cfc0) Line 364
+ 0x2b bytes
python34_d.dll!collect(int generation=0, __int64 *
n_collected=0x00012beee530, __int64 * n_uncollectable=0x00012beee520,
int nofail=0) Line 969
python34_d.dll!collect_with_callback(int generation=0) Line 1140 + 0x16 bytes
python34_d.dll!collect_generations() Line 1163 + 0x9 bytes
python34_d.dll!_PyObject_GC_Malloc(unsigned __int64 basicsize=56) Line 1739
python34_d.dll!_PyObject_GC_New(_typeobject * tp=0x633ce280) Line 1748
+ 0xe bytes
python34_d.dll!PyList_New(__int64 size=0) Line 159 + 0xc bytes
python34_d.dll!PyEval_EvalFrameEx(_frame * f=0x00010f387658, int
throwflag=3) Line 2347 + 0x8 bytes
python34_d.dll!fast_function(_object * func=0x0003, _object * * *
pp_stack=0x000129e69948, int n=737077536, int na=1661137695, int nk=0)
Line 4335
python34_d.dll!call_function(_object * * * pp_stack=0x00012beee919, int
oparg=131) Line 4263
python34_d.dll!PyEval_EvalFrameEx(_frame * f=0x00011c077528, int
throwflag=3) Line 2840
python34_d.dll!fast_function(_object * func=0x0003, _object * * *
pp_stack=0x89a53190, int n=737078048, int na=1661137695, int nk=0)
Line 4335
python34_d.dll!call_function(_object * * * pp_stack=0x00012beeeb19, int
oparg=131) Line 4263
python34_d.dll!PyEval_EvalFrameEx(_frame * f=0x00010369f2a8, int
throwflag=0) Line 2840
python34_d.dll!PyEval_EvalCodeEx(_object * _co=0x00010002, _object *
globals=0x00010002, _object * locals=0x1fa5e218, _object * *
args=0x00730088, int argcount=2, _object * * kws=0x00730080,
int kwcount=0, _object * * defs=0x, int defcount=0, _object *
kwdefs=0x, _object * closure=0x) Line 3588 +
0xf bytes
python34_d.dll!function_call(_object * func=0x03c10058, _object *
arg=0x1fa5e218, _object * kw=0x0001296360c8) Line 638 + 0x8a bytes
python34_d.dll!PyObject_Call(_object * func=0x03c10058, _object *
arg=0x1fa5e218, _object * kw=0x0001296360c8) Line 2040 + 0x13 bytes
python34_d.dll!ext_do_call(_object * func=0xc42c25a0, _object * * *
pp_stack=0x00012b49, int flags=62980184, int na=1, int nk=0) Line 4561
+ 0xe bytes
python34_d.dll!PyEval_EvalFrameEx(_frame * f=0xfa4eab18, int
throwflag=1) Line 2880
python34_d.dll!fast_function(_object * func=0x0001, _object * * *
pp_stack=0x3b42f398, int n=737079376, int na=1661137695, int nk=0)
Line 4335
python34_d.dll!call_function(_object * * * pp_stack=0x00012beef049, int
oparg=131) Line 4263
python34_d.dll!PyEval_EvalFrameEx(_frame * f=0x00010f38ec28, int
throwflag=0) Line 2840
[issue23670] Modifications to support iOS as a development platform
New submission from Russell Keith-Magee: Proposal: iOS should be a supported platform for Python development. The attached patch is a first pass at a patch to achieve this. It is a single patch against Python 3.4.2 sources, and requires no pre- or post-configure modifications. Supporting iOS requires multiple builds - one for each of the hardware platforms that iOS supports (x86_64 simulator, ARMv7 and ARM64). These separate builds must then be merged into a single fat framework. The patch contains an iOS directory with a meta Makefile that manages this build-and-merge process. See the README in the iOS directory for details on usage. The patch also introduces a new 'ios' platform type. A sample XCode project for an iOS app is also provided as part of the patch. iOS/README contains a couple of other notes about the build and the approach taken. There are some known problems/limitations with this patch: * It's a patch against 3.4.2, not hg trunk * The code doesn't currently compile for ARMv7. In order to support ARM64, it has been necessary to use an unreleased trunk version of libffi; however, this version is currently broken for ARMv7. Older versions of libffi (including the formal 3.2.1 release) *do* work. * The patch doesn't currently provide any way to run the test suite on the target platform. Testing is currently based on a simple smoke test of some basic features. So - the patch isn't ready for commit to trunk. I'm presenting it for the purposes of getting feedback on the broad approach while I continue to resolve the known issues. -- components: Build, Cross-Build files: 20150314.diff keywords: patch messages: 238125 nosy: freakboy3742 priority: normal severity: normal status: open title: Modifications to support iOS as a development platform type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file38493/20150314.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23670 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23500] Argument Clinic: multiple macro definition
Serhiy Storchaka added the comment: It doesn't fix the issue, because the #ifndef stanza is emitted before second definition. Try to run clinic.py with your patch on sample.c. But may be this idea can be used with my patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23500 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23671] string.Template doesn't work with the self keyword argument
New submission from Serhiy Storchaka:
string.Template doesn't allow to specify the self substitute parameter as
keyword argument.
import string
string.Template('the self is $self').substitute(self='bozo')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: substitute() got multiple values for argument 'self'
string.Template('the self is $self').safe_substitute(self='bozo')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: safe_substitute() got multiple values for argument 'self'
The same issue is with string.Formatter.format:
string.Formatter().format('the self is {self}', self='bozo')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: format() got multiple values for argument 'self'
Proposed patch fixes these issues.
--
components: Library (Lib)
files: string_formatting_self.patch
keywords: patch
messages: 238132
nosy: georg.brandl, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: string.Template doesn't work with the self keyword argument
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38497/string_formatting_self.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23671
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23672] IDLE for osx 10.8.5 won't run
New submission from Kamisky:
I could run the IDLE in the past time.But today,when I try and launch IDLE, the
icon appears on the dock for a second and then disappears and the application
doesn't run.Moreover,When I run IDLE3 in Terminal,it says:
bogon:~ Kamisky$ idle3
Traceback (most recent call last):
File /Library/Frameworks/Python.framework/Versions/3.4/bin/idle3, line 5,
in module
main()
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/idlelib/PyShell.py,
line 1560, in main
shell = flist.open_shell()
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/idlelib/PyShell.py,
line 315, in open_shell
self.pyshell = PyShell(self)
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/idlelib/PyShell.py,
line 866, in __init__
OutputWindow.__init__(self, flist, None, None)
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/idlelib/OutputWindow.py,
line 16, in __init__
EditorWindow.__init__(self, *args)
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/idlelib/EditorWindow.py,
line 301, in __init__
self.update_recent_files_list()
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/idlelib/EditorWindow.py,
line 927, in update_recent_files_list
underline=0)
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/__init__.py,
line 2719, in add_command
self.add('command', cnf or kw)
File
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/__init__.py,
line 2710, in add
self._options(cnf, kw))
_tkinter.TclError: character U+1f393 is above the range (U+-U+) allowed
by Tcl
Thanks.
--
components: IDLE
messages: 238136
nosy: kamisky
priority: normal
severity: normal
status: open
title: IDLE for osx 10.8.5 won't run
type: behavior
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23672
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a cross-compilation target
Ned Deily added the comment: A thought, primarily as a note to myself for further investigation: the current OS X framework build support and, to a lesser extent, universal build support have added a fair amount of special-case cruft to the build process, primarily in configure.ac and the main Makefile. Over the years, the build tools have evolved and gotten smarter (and more general) about SDK support and arch support using xcrun, as they were generalized to support iOS vs OS X builds. But, if it is necessary to do separate compile/link steps to support iOS framework builds because of the multiple SDKs, it *might* make sense to integrate those into the main Makefile and to isolate the framework build steps (for both OS X and iOS) to be more of an add-on step. The potential positive impact might be to simplify the current main Makefile and configure.ac by centralizing much of the framework build specific steps scattered throughout the Makefile *and* it could also simplify and speed up the iOS builds by not du plicating the platform-independent build steps. It might even be a useful abstraction for other non-Apple multiple-arch or cross-compilation builds. Another factor to consider is support for building third-party extension modules standalone as opposed to building as part of the interpreter itself. It would be nice to be able to just use the traditional Distutils-based process for third-party extension modules. For OS X universal builds, we get that essentially for free because of the tool chain support for multiple archs. To do it automatically across multiple SDKs would require adding smarts to Distutils to do multiple compile/links and lipo merges. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23670 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23672] IDLE can crash if file name contains non-BMP Unicode characters
Ned Deily added the comment: At least on some platforms (e.g. OS X), it is easy to create files with legitimate names containing code points above the BMP limit (= U+) currently imposed by Tcl/Tk. For IDLE 3, I suspect _filename_to_unicode() in EditorWindow could be modified to check for such cases to prevent problems if such file names end up in recent-files.lst. That might not be sufficient: there may be other problematic places. I also was able to crash a current IDLE 2.7 just opening a file with such a name. -- stage: - needs patch title: IDLE for osx 10.8.5 won't run - IDLE can crash if file name contains non-BMP Unicode characters versions: +Python 2.7, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23672 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23672] IDLE can crash if file name contains non-BMP Unicode characters
Changes by Ned Deily n...@acm.org: -- nosy: +roger.serwy, terry.reedy -ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23672 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a cross-compilation target
R. David Murray added the comment: Also remember that being a supported platform requires buildbots. If I'm reading this right that means two: one for the simulator build, and one that actually runs on the device (once the run-the-test issues is solved). I'm not sure what would need to be done to buildbot to support the scenario of building on one platform and running the tests on another after copying the binary, but I'm sure there must be some way to do it...buildbot is written in Python after all :) And I'm sure that capability will be useful for more than just iOS...with Android we can probably run buildbot on the device eventually, but being able to test a cross compile build there as well will be helpful (once there is one). -- hgrepos: +300 nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23670 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23655] Memory corruption using pickle over pipe to subprocess
John Nagle added the comment: More info: the problem is on the unpickle side. If I use _Unpickle and Pickle, so the unpickle side is in Python, but the pickle side is in C, no problem. If I use Unpickle and _Pickle, so the unpickle side is C, crashes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23655 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4896] Faster why variable manipulation in ceval.c
Mark Lawrence added the comment: I've finally remembered to attach the test output I got a week ago. If you want me to run Antoine's test suite with any specific parameters please feel free to ask. -- Added file: http://bugs.python.org/file38501/unpatched.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4896 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23674] super() documentation isn't very clear
New submission from Tapani Kiiskinen: https://docs.python.org/3/library/functions.html#super There's no mention in the document which __mro__ is used in the case of a super(Type, obj) call. There's this mention 'The __mro__ attribute of the *type* lists the method resolution search order used by both getattr() and super().' but my understanding is that this only applies in the case of a super(type) call plus it doesn't state that it only applies in that case. (I'm fairly certain I'm not wrong; if only the __mro__ of the type was used then cooperative multiple inheritance (which is referenced three paragraphs down) could not work because the __mro__ of the type never has sibling types.) Isn't this misleading due to a super(Type, obj) call (or just super() inside a class in 3k) being the more normal way to use the function? Even now I can't find a single resource to confirm which exact mro is used in the case of a super(Type, obj) call, I've only been able to deduce that it probably uses the type(obj).__mro__ then finds the Type and then tries the entries after Type. Finally 'If the second argument is omitted, the super object returned is unbound. If the second argument is an object, isinstance(obj, type) must be true. If the second argument is a type, issubclass(type2, type) must be true (this is useful for classmethods).' I'm interpreting this is essentially saying that if the second argument is given that the returned object will be bound, given an object the super call would return a bound instance method and given a type a bound class method? I feel like stating this explicitly would be more clear than implicitly. -- assignee: docs@python components: Documentation messages: 238157 nosy: Tapani Kiiskinen, docs@python priority: normal severity: normal status: open title: super() documentation isn't very clear versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23674 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23187] Segmentation fault, possibly asyncio related
Michael Goldish added the comment: Sorry, you're wrong: the proactor event loop heavily uses the _overlapped module which is implemented in C. A crash in the garbage collector is more likely a bug in asyncio/your application, than a bug in Python itself. I'm aware of that. I assumed the original crash reported in this thread was the same as mine but I can't be sure of that. And that crash was on Linux, where asyncio is pure Python AFAIK. Please enable asyncio debug mode, ResourceWarning, enable DEBUG log level, and check if you get some errors. For example, GetQueuedCompletionStatus() returned an unexpected event usually means that you will quickly get a memory corruption... I've already done that but admittedly not for very long because the server ran so slowly that it was unresponsive. I didn't see any error or warning messages, but I did see numerous Executing Handle _ProactorReadPipeTransport._loop_reading(_OverlappedF...events.py:451) messages. Would it be possible to test again with fewer clients (500 clients or less to not hit the select() limit on Windows) with selector event loop? I'll see if I can try that, but I guess reproducing the crash can take much longer with 500 clients. Can you check if asyncio.windows_events._BaseWaitHandleFuture is used? This class is used by IocpProactor.wait_for_handle() which is called by _WindowsSubprocessTransport. But you wrote you the server (where the crash occurs) doesn't run subprocesses. It's not used. I put print statements and an exit() in the constructor of _BaseWaitHandleFuture and it wasn't triggered. Are you using asyncio code outside the main thread? No. asyncio is not thread-safe at all :-p Are you using a single event loop or one event loop per thread? A single event loop, and I've made sure that all code running outside the main thread doesn't call any asyncio functions. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23187 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23674] super() documentation isn't very clear
R. David Murray added the comment: I agree with Tapani; what you just explained should be made explicit (the type is skipped isn't the same as searching starts from the item after the type in the object's MRO). Also, the docs imply by the phrasing that the getattr docs will explain the method resolution order, but those docs do not in fact address the topic. Perhaps there should be a link to 'method resolution order' in the glossary? -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23674 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23672] IDLE can crash if file name contains non-BMP Unicode characters
Terry J. Reedy added the comment: The full path of a file being edited also ends up in the title bar and the Window menu. I do not know whether the title bar is displayed by tk or the OS (Windows obviously displays the title of taskbar icons) but the Window list is definitely by tk. It seems to me that files need two names: the system name used to open (and re-open) a file (utf-8 bytes on *nix?) and a tk name (BMD unicode) for display in the various places. The current limitation to BMP names is a limitation of the tcl/tk gui framework. I would like to add a workaround but do not consider its absence a bug. I am proposing on python-list the addition of some builtin means to replace non-BMP chars with \U000x escapes for display purposes. This would be generally useful for tkinter programming. The thread is Add str.bmp() to only expand non-BMP chars, for tkinter use. If this does not happen in 3.5, I would consider a patch to add a private function to EditorWindow.py to do the same. It would be far less efficient, but fast enough for short path names. The EditorWindow.py line numbers are slight different from those in 3.4.3 (and 3.4.2, I believe), so I presume this is with 3.4.0 or 3.4.1. The result with 3.4.3 should be unchanged. -- type: behavior - enhancement versions: -Python 2.7, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23672 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23674] super() documentation isn't very clear
Raymond Hettinger added the comment: There's this mention 'The __mro__ attribute of the *type* lists the method resolution search order used by both getattr() and super(). I think instead of *type* it should say *object-or-type*. It is the second argument that supplied the MRO. The first arguments determines where we are currently in that MRO so that the search can begin upstream from the current class. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23674 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23672] IDLE can crash if file name contains non-BMP Unicode characters
Terry J. Reedy added the comment: Thinking more, there are two issue here. One is the fact that Idle stops when fed a filename with astral chars. This *is* a bug and should be fixed in all versions, even if that fix is to display a message box saying that Idle cannot work properly with such files. The second is the one I addressed in the first message, the inability to work properly with files. Fixing that would obviate the need to display a message, but might be more work, especially on 2.7. Kamisky, if you launch Idle and then try to open the file, do you see the name in the Open dialog? I presume that if you do, and select it, Idle would stop just as it did in your report. -- type: enhancement - behavior versions: +Python 2.7, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23672 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23674] super() documentation isn't very clear
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- assignee: docs@python - rhettinger nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23674 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23672] IDLE can crash if file name contains non-BMP Unicode characters
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- priority: normal - high ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23672 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23676] Add support of UnicodeTranslateError in standard error handlers
New submission from Serhiy Storchaka: Proposed patch adds support of UnicodeTranslateError in standard error handlers xmlcharrefreplace, namereplace and surrogatepass. Support in backslashreplace was added in issue22286, support in strict, ignore and replace was always, support in surrogateescape is unlikely possible. This can be used with issue18814. -- components: Interpreter Core files: translate_error_handlers.patch keywords: patch messages: 238163 nosy: doerwalter, lemburg, ncoghlan, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Add support of UnicodeTranslateError in standard error handlers type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file38502/translate_error_handlers.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23676 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23624] str.center inconsistent with format ^
Raymond Hettinger added the comment: [Serhiy] The behavior of Python 2.7 is the same as Python 3.x. str.center() is very old method and changing it will change formatted reports generated by third-party software in all world. At least this will break many tests. And this will add yet one incompatibility between Python 2 and Python 3. I concur with Serhiy. Fixing this nuisance inconsistency would likely cause greater harm than it would relieve. This ship has sailed. -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23624 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23675] glossary entry for 'method resolution order' links to something with python 2.3 in the title
New submission from R. David Murray: The link is correct; that document describes the new-style class method resolution order, which is what Python3 uses. However, the title is a bit problematic, and either the title should be changed or the link from the Python3 docs should have a gloss explaining why the document is in fact the correct link. -- messages: 238161 nosy: r.david.murray priority: normal severity: normal status: open title: glossary entry for 'method resolution order' links to something with python 2.3 in the title ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23675 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18814] Add codecs.convert_surrogateescape to clean surrogate escaped strings
Changes by Serhiy Storchaka storch...@gmail.com: -- dependencies: +Add support of UnicodeTranslateError in standard error handlers ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18814 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20962] Rather modest chunk size in gzip.GzipFile
Martin Panter added the comment: See also the patch for Issue 23529, which changes over to using BufferedReader for GzipFile, BZ2File and LZMAFile. The current patch there also passes a buffer_size parameter through to BufferedReader, although it currently defaults to io.DEFAULT_BUFFER_SIZE. -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20962 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a cross-compilation target
Russell Keith-Magee added the comment: Understood that buildbots are required. The subject has come up a couple of times on mobile-sig - however, I haven't got a good answer for exactly what this means in practice. Does build hardware need to be delivered to a specific build farm location, or can it just run in my home office? Does it need to be running 24/7, or just guarantee that at least X builds per week, or Y% of all builds are tested? In terms of physical specifications - at a minimum, at least two iDevices will be required (an ARMv7 device, like a 5th Gen iPod, and an ARM64 device, like an iPhone 5S), tethered to a Mac that runs the simulator. In terms of execution - there's definitely ways to remote-control the deployment and execution of apps, so I imagine buildbot integration is in the realm of the possible. Android will have similar requirements, but Android also has an emulator which would allow testing without the existence of a physical device, which would provide an alternative approach. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23670 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21112] 3.4 regression: unittest.expectedFailure no longer works on TestCase subclasses
Robert Collins added the comment: Test looks good to me. Do you want to apply it? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21112 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17911] traceback: add a new thin class storing a traceback without storing local variables
Robert Collins added the comment: Looking at the regression now. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17911 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23631] 3.5 (a2) traceback regression snarls Idle
Nick Coghlan added the comment: Patch looks good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23631 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8087] Unupdated source file in traceback
Robert Collins added the comment: Oh, it may be clear to everyone already but its perhaps worth noting: there are two ways the cache can skew. (older source): We may have a newer file compiled and in use and the older source in the cache. e.g. someone calls linecache.getlines(foo.py), then imports foo, and in between the contents of foo.py changed. (newer source) Or we may have an older file compiled and in use, and newer source in the cache. e.g. someone imports foo, the contents of foo.py change, and then someone calls linecache.getlines(foo.py). One way to address the older source case would be to make importing (also compile()) flush the imported file out of the cache. That doesn't need any special logic or handling - just a new parameter to clearcache() to specify a file (or files?) to evict. The newer source case is what needs some logic, and for that, as I said earlier, I think we need something opaque. Perhaps since we have importlib now, if we limit ourselves to considering actual python modules (linecache can technically cache anything with lines in it) we can rely on the import machinery get_source() to handle this: if the source has changed get_source should return None. That way we don't need to change the data structure of modules at all - only packages for which there is no 302 loader will be able to suffer cache skew. As far as informing callers that this situation has occurred, I think we'll need to think a bit about that, as linecache already signals 'source not available' by returning None, which doesn't leave much room to include an error message. We could start raising exceptions up the stack - which implies modifying PEP-302 (e.g. via a new PEP) and working up the stack. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8087 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8087] Unupdated source file in traceback
Robert Collins added the comment: Oh, meant to add - we could just call logging.warning or something. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8087 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23585] patchcheck doesn't depend on all
Changes by Robert Collins robe...@robertcollins.net: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23585 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23631] 3.5 (a2) traceback regression snarls Idle
Robert Collins added the comment: I suspect that this is due to a list being passed in that wasn't created by traceback, in the older tuple-only format. That was meant to work, but possibly is being short circuited somewhere. Shall fix asap. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23631 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23631] 3.5 (a2) traceback regression snarls Idle
Robert Collins added the comment: Ah, idle is being somewhat naughty. It's taking the original traceback and then mangling the contents in-place, which is preserving the type information, and throwing off StackSummary.from_list. We can and should make the new code deal with this in case other folk are doing it. In future it would be good to subsume cleanup_traceback's guts into the traceback module, but we don't need to do that now. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23631 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23631] 3.5 (a2) traceback regression snarls Idle
Robert Collins added the comment: And here is a patch, since this is a regression I'll apply it tomorrow (or sooner if it gets reviews :)) -- keywords: +patch Added file: http://bugs.python.org/file38503/issue-23631-1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23631 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23631] 3.5 (a2) traceback regression snarls Idle
Roundup Robot added the comment: New changeset ea3cc128ce35 by Robert Collins in branch 'default': Issue #23631: Fix traceback.format_list when a traceback has been mutated. https://hg.python.org/cpython/rev/ea3cc128ce35 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23631 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23310] MagicMock constructor configuration fails for magic methods
Changes by Robert Collins robe...@robertcollins.net: -- stage: - needs patch type: - crash ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23310 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23585] patchcheck doesn't depend on all
Nick Coghlan added the comment: Sounds fine to me. This could be particularly useful for docs-only patches, where you may not have done a local make test first. -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23585 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23310] MagicMock constructor configuration fails for magic methods
Changes by Robert Collins robe...@robertcollins.net: -- type: crash - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23310 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21112] 3.4 regression: unittest.expectedFailure no longer works on TestCase subclasses
Changes by Berker Peksag berker.pek...@gmail.com: -- assignee: - berker.peksag ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21112 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23585] patchcheck doesn't depend on all
Roundup Robot added the comment: New changeset de093a1ec51b by Robert Collins in branch 'default': Issue #23585: make patchcheck will ensure the interpreter is built. https://hg.python.org/cpython/rev/de093a1ec51b -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23585 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22937] unittest errors can't show locals
Robert Collins added the comment: Fixed (patch referenced 22936) -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22937 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
