[issue24400] Awaitable ABC incompatible with functools.singledispatch
Nick Coghlan added the comment: A couple of high level observations: 1. As Yury notes, more clearly separating coroutines and generators is the intent of the PEP. The computer could clearly cope with them being the same class, but humans tended to get confused. We were still blurring that line too much in the initial implementation, this patch aims to fix that by *really* introducing a separate class for native coroutines. 2. Missing integrations in other modules that are likely to result in misbehaviour in user code (such as the inspect module not accounting for the new ABCs) are good candidates for filing as behaviour bugs - finding that kind of gap in PEP implementations is one of the benefits of the beta period. 3. Integrating nicely with both asyncio and Tornado is a good pragmatic design goal to avoid making too many asyncio specific assumptions -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects
Jan Harkes added the comment: @Carl.Kleffner: that is an interesting message but it discusses using binutils(/mingw?) generated import libraries with the MS linker. This bugreport was about two 64-bit objects that were accidentally included in an otherwise 32-bit library and it has been resolved. I am not entirely sure why people are anticipating possible problems for which I have seen no actual bug reports or build failures. Searching this bugtracker for mingw related reports shows 187 reports over the past 13.5 years and at first glance I don't see any about compatibility issues between versions. There are only 3 for mingw+libpython, one of which is this report. The various windows forks of mingw, maybe in an attempt to reach Visual C compatibility, may have as stable a format but the only failure I have personally seen was this 64-bit objects in a 32-bit library problem, which does look to me like a tool chain bug but luckily there was a relatively simple --as-flags=--32 workaround. I just reread my comment and I it reads ruder than I meant it to be, I'm truly sorry for that. I appreciated reading the link you included to see some of those demons lurking in the depths. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24385 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24422] base64 not encode correctly
Ezio Melotti added the comment: No, this is expected. See http://en.wikipedia.org/wiki/Base64#Padding -- nosy: +ezio.melotti resolution: - not a bug stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24422 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22359] Remove incorrect uses of recursive make
koobs added the comment: martin: yes, if the incorrect usage of recursive make is in the 2.7 and 3.4 branches and the fix is relevant to the issues I reported. Of course all subsequent changes (fixing cross-builds) should be applied there too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22359 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24421] Race condition compiling Modules/_math.c
New submission from Martin Panter: Once or twice I have had the math or cmath modules fail to build. There seems to be a race condition, because the _math.c file seems to be compiled twice, once for each module. Attached is a GCC wrapper that should help reproduce this fairly consistently. First, build Python normally: $ ./configure $ make -j2 Then force Modules/_math.c to be recompiled using my wrapper script to amplify the race condition: $ touch Modules/_math.c $ rm build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o $ make -j2 CC=./slow-cc.py running build running build_ext building 'cmath' extension compiling for cmath ./slow-cc.py [. . .]/Modules/cmathmodule.o building 'math' extension ./slow-cc.py [. . .]/Modules/mathmodule.o ./slow-cc.py -fPIC -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I./Include -I. -IInclude -I/usr/local/include -I/media/disk/home/proj/python/cpython/Include -I/media/disk/home/proj/python/cpython -c /media/disk/home/proj/python/cpython/Modules/_math.c -o build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o INITIAL COMPILE ./slow-cc.py -fPIC -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I./Include -I. -IInclude -I/usr/local/include -I/media/disk/home/proj/python/cpython/Include -I/media/disk/home/proj/python/cpython -c /media/disk/home/proj/python/cpython/Modules/_math.c -o build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o RECOMPILE RECOMPIILE TRUNCATING INITIAL COMPILE FINISHED ./slow-cc.py -shared build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/mathmodule.o build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o -L/usr/local/lib -lm -o build/lib.linux-x86_64-3.6/math.cpython-36m-x86_64-linux-gnu.so build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o: file not recognized: File truncated collect2: error: ld returned 1 exit status RECOMPILE FINISHED ./slow-cc.py -shared build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/cmathmodule.o build/temp.linux-x86_64-3.6/media/disk/home/proj/python/cpython/Modules/_math.o -L/usr/local/lib -lm -o build/lib.linux-x86_64-3.6/cmath.cpython-36m-x86_64-linux-gnu.so Failed to build these modules: math -- components: Build files: slow-cc.py messages: 245121 nosy: vadmium priority: normal severity: normal status: open title: Race condition compiling Modules/_math.c type: behavior Added file: http://bugs.python.org/file39672/slow-cc.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24421 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24422] base64 not encode correctly
New submission from Hector Cloud: I use Python 3.4.0 now. But its base64 encoding is not as expected. import base64 ascii = base64.b64encode(uYAU-interview-revised20120921.encode(), b'-_') print(ascii) The result is b'WUFVLWludGVydmlldy1yZXZpc2VkMjAxMjA5MjE='. There is a character '=' at the end which is not expected. In my opinion, the result should contain characters [A-Za-z0-9] and '-_'. The '=' should not be in the encoding result. Is it a bug? -- components: Library (Lib) messages: 245123 nosy: Hector Cloud priority: normal severity: normal status: open title: base64 not encode correctly type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24422 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects
Carl Kleffner added the comment: I experienced this behaviour by accident several times. Most likely this is due to inconsistenticies in different binutils and mingw-runtime versions/patches. See i.e. http://article.gmane.org/gmane.comp.gnu.binutils/46799 A robust solution is to exclusively use import libraries created by the toolchain used for building python extensions. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24385 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22359] Remove incorrect uses of recursive make
Martin Panter added the comment: My math and cmath issue seems to be completely separate. I opened Issue 24421 for that, so sorry for the noise here :) I think the patch here should be applied (or adapted if necessary) to the 3.4 and 2.7 branches. If it breaks cross compilation, then the cross compilation technique needs improving instead; perhaps see Issue 22625 for that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22359 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24423] Fix wrong indentation in Doc/whatsnew/3.5.rst
New submission from Stefan Tatschner: A list item which describes the changes of #22631 is badly indented. The attached (trivial) patch fixes that problem. -- assignee: docs@python components: Documentation files: fix-indentation.patch keywords: patch messages: 245127 nosy: docs@python, rumpelsepp priority: normal severity: normal status: open title: Fix wrong indentation in Doc/whatsnew/3.5.rst versions: Python 3.5 Added file: http://bugs.python.org/file39673/fix-indentation.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24423 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24086] Configparser interpolation is unexpected
Jens Diemer added the comment:
IMHO i ran into the same bug, try to ./setup.py upload with my new password
in ~/.pypirc:
configparser.InterpolationSyntaxError: '%' must be followed by '%' or '(',
found: %foobar
This is a limitation of the configparser... But what's about to validate this
on the set PyPi password view ?
So that's impossible to set a PyPi password which can't be parsed by
configparser ?
--
nosy: +jens
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24086
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue672115] Assignment to __bases__ of direct object subclasses
Changes by Boris bor...@appliedinfogroup.com: -- nosy: +borisompol ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue672115 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Ben Darnell added the comment: With the two changes I described things appear to be working, although I've only done light testing so far. For inspect.isgenerator(), my use case is here: https://github.com/tornadoweb/tornado/blob/2971e857104f8d02fa9107a0e13f50170eb4f30d/tornado/gen.py#L222 I currently do isinstance(x, types.GeneratorType), which will fail if x is actually a GeneratorWrapper. I can change this to use collections.abc.Generator when it exists, but then I'd have to have some conditional logic to switch between collections.abc and types depending on what version I'm running on. It would be nice if that were encapsulated in inspect.isgenerator(). More generally, the inconsistency between isgenerator() and iscoroutine() is kind of odd. I would expect that either all inspect functions or none of them would use a suitable ABC if one exists. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24424] xml.dom.minidom: performance issue with Node.insertBefore()
New submission from Robert Haschke: Node.insertBefore() has a serious performance issue: Using self.childNodes.index(refChild) it searches for the correct index in childNodes where the newChild should be inserted. However, index() is linear in time w.r.t. the size of childNodes. Hence, if there are many children, runtime dramatically increases. Adding a simple caching mechanism (caching the previously used reference) I was able to reduce runtime in my particular case from 16s to 1.6s, i.e. a factor of 10! -- components: XML files: minidom.insertBefore.patch keywords: patch messages: 245128 nosy: Robert Haschke priority: normal severity: normal status: open title: xml.dom.minidom: performance issue with Node.insertBefore() type: performance versions: Python 2.7 Added file: http://bugs.python.org/file39674/minidom.insertBefore.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24424 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Return a namedtuple from date.isocalendar()
Tal Einat added the comment: How about IsoCalendarDate? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24416 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21907] Update Windows build batch scripts
Roundup Robot added the comment: New changeset 4890a55c62ab by Zachary Ware in branch '2.7': Clean up/refactor the batch scripts used for building on Windows. https://hg.python.org/cpython/rev/4890a55c62ab New changeset a6ceb631c747 by Zachary Ware in branch '3.4': Clean up/refactor the batch scripts used for building on Windows. https://hg.python.org/cpython/rev/a6ceb631c747 New changeset e6a95bda2943 by Zachary Ware in branch '3.5': Merge forward extras beyond #21907 backport. https://hg.python.org/cpython/rev/e6a95bda2943 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21907 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22359] Remove incorrect uses of recursive make
Martin Panter added the comment: koobs: It sounds like applying the fix for this bug to the Python 2 branch might satisfy you, right? It only seems to have been applied to 3.5+ so far. Matt: It sounds like you are trying to pre-compile $(PGEN) for the host, and then rely on it not being rebuilt. Maybe there is a better way, like changing the $(PGEN) command line to use a $(HOST_CC) or something. (I’m not familiar with the build system; certainly not when cross compiling.) But you could also try and identify the dependency that is causing $(PGEN) to be rebuilt, for example with Gnu Make: $ make --debug=b Parser/pgen Updating goal targets Prerequisite `Include/Python.h' is newer than target `Parser/acceler.o'. Must remake target `Parser/acceler.o'. [. . .] Prerequisite `Parser/acceler.o' is newer than target `Parser/pgen'. [. . .] Must remake target `Parser/pgen'. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22359 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24379] slice.literal notation
Tal Einat added the comment: So, is this in any ways different than NumPy's s_? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24379 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Stefan Behnel added the comment: I currently do isinstance(x, types.GeneratorType), which will fail if x is actually a GeneratorWrapper. I can change this to use collections.abc.Generator when it exists, but then I'd have to have some conditional logic to switch between collections.abc and types depending on what version I'm running on. I originally planned to make the next Cython release patch the Generator and Coroutine ABCs into collections.abc, but I now think it would be worth uploading an abc_backports package to PyPI instead that does that and on which asyncio, tornado and other packages could simply depend with a try-import. It would be nice if that were encapsulated in inspect.isgenerator(). +1, code that needs exactly a generator, e.g. for gi_running and friends, can still test for isinstance(obj, types.GeneratorType) in a completely backwards compatible way, which is more explicit anyway. More generally, the inconsistency between isgenerator() and iscoroutine() is kind of odd. I would expect that either all inspect functions or none of them would use a suitable ABC if one exists. Yes, it's odd. Either way would work (types is for types only vs. types includes protocols), but having both disagree seems wrong. I think the mere fact that there is a higher level function than isinstance() suggests that it should really be more high level and not just doing exactly the same for all times. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24379] slice.literal notation
Joe Jevnik added the comment: It is a singleton, does not accept the `maketuple` flag, and is written in C. I did not know about the s_ attribute of numpy before writing this; however, I still think that moving this object to slice improves code clarity (s_ is not a super clear name). I also think that this behaviour belongs on the slice object. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24379 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24426] re.split performance degraded significantly by capturing group
Serhiy Storchaka added the comment: Splitting with pattern '\n(?=(\n))' produces the same result as with pattern '(\n)' and is as fast as with pattern '\n'. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24426 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24428] Import sys,getopt is having issue while taking inputs
Eric V. Smith added the comment: This is not a problem with python, but rather with how bash interprets your program arguments. Try putting the arguments in single quotes, like: python validate_json_adj.py -i '$#@%' -- nosy: +eric.smith resolution: - not a bug stage: - resolved status: open - closed type: behavior - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24428 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24427] subclass of multiprocessing Connection segfault upon attribute acces
New submission from Charles-François Natali:
The following segfaults in _PyObject_GenericGetAttrWithDict:
from socket import socketpair
from _multiprocessing import Connection
class Crash(Connection):
pass
_, w = socketpair()
Crash(w.fileno()).bar
#0 _PyObject_GenericGetAttrWithDict (dict=0xa6b001c, name=0xb7281020,
obj=0x8c12478) at Objects/object.c:1427
#1 PyObject_GenericGetAttr (obj=0x8c12478, name=0xb7281020) at
Objects/object.c:1461
(gdb) p *(obj + obj-ob_type-tp_dictoffset)
$8 = {ob_refcnt = 0, ob_type = 0x0}
It's probably not specific to this example, but I'm not familiar enough with
object construction/descriptors to know what's going on here.
Note that the following atch fixes the crash, but I don't know why:
--- a/Modules/_multiprocessing/connection.h Wed Apr 15 19:30:38 2015 +0100
+++ b/Modules/_multiprocessing/connection.h Wed Jun 10 20:25:15 2015 +0100
@@ -58,7 +58,7 @@
return NULL;
}
-self = PyObject_New(ConnectionObject, type);
+self = type-tp_alloc(type, 0);
if (self == NULL)
return NULL;
@@ -86,7 +86,7 @@
CLOSE(self-handle);
Py_END_ALLOW_THREADS
}
-PyObject_Del(self);
+Py_TYPE(self)-tp_free((PyObject*)self);
}
/*
--
messages: 245140
nosy: neologix, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: subclass of multiprocessing Connection segfault upon attribute acces
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24427
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24426] re.split performance degraded significantly by capturing group
New submission from Patrick Maupin: The addition of a capturing group in a re.split() pattern, e.g. using '(\n)' instead of '\n', causes a factor of 10 performance degradation. I use re.split a() lot, but never noticed the issue before. It was extremely noticeable on 1000 patterns in a 5BG file, though, requiring 40 seconds instead of 4. I have attached a script demonstrating the issue. I have tested on 2.7 and 3.4, but have no reason to believe it doesn't exist on other vesions as well. Thanks, Pat -- components: Regular Expressions files: splitter2.py messages: 245137 nosy: Patrick Maupin, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: re.split performance degraded significantly by capturing group type: performance versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file39676/splitter2.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24426 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24426] re.split performance degraded significantly by capturing group
Serhiy Storchaka added the comment: Regular expression is optimized for the case when it starts with constant string or charset. It is no degradation when using '(\n)', but rather an optimization of '\n'. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24426 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24428] Import sys,getopt is having issue while taking inputs
New submission from venkata suresh gummadillli: [@outsidetried ~]$ python validate_json_adj.py [@outsidetried ~]$ python validate_json_adj.py -h validate_json.py -i input_file [@outsidetried ~]$ python validate_json_adj.py -i hello.txt Input JSON file provided for verification: hello.txt [@outsidetried ~]$ python validate_json_adj.py -i firstfile Input JSON file provided for verification: firstfile [@outsidetried ~]$ python validate_json_adj.py -i hello.txt -bash: syntax error near unexpected token `newline' [sureshgv@outsidetried ~]$ python validate_json_adj.py -i ?? Input JSON file provided for verification: ci [@outsidetried ~]$ python validate_json_adj.py -i ??? Input JSON file provided for verification: bf1 [@outsidetried ~]$ python validate_json_adj.py -i $#@% Input JSON file provided for verification: 0@% [@outsidetried ~]$ cat validate_json_adj.py #!/usr/bin/python import sys,getopt def main(argv): inputfile = '' try: opts, args = getopt.getopt(argv,hi:,[input_file=]) except getopt.GetoptError: print 'validate_json.py -i input_file' sys.exit(2) for opt, arg in opts: if opt == '-h': print 'validate_json.py -i input_file' sys.exit() elif opt in (-i, --input_file): inputfile = arg print 'Input JSON file provided for verification:', inputfile if __name__ == __main__: main(sys.argv[1:]) -- components: Library (Lib) messages: 245142 nosy: venkata suresh gummadillli priority: normal severity: normal status: open title: Import sys,getopt is having issue while taking inputs type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24428 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24426] re.split performance degraded significantly by capturing group
Patrick Maupin added the comment: 1) I have obviously oversimplified my test case, to the point where a developer thinks I'm silly enough to reach for the regex module just to split on a linefeed. 2) '\n(?=(\n))' -- yes, of course, any casual user of the re module would immediately choose that as the most obvious thing to do. 3) My real regex is r'( [a-zA-Z0-9_]+ \[[0-9]+\][0-9:]+\].*\n)' because I am taking nasty broken output from a Cadence tool, fixing it up, and dumping it back out to a file. Yes, I'm sure this could be optimized, as well, but when I can just remove the parentheses and get a 10X speedup, and then figure out the string I meant to capture by looking at string lengths, shouldn't there at least be a warning that the re module has performance issues with capturing groups with split(), and casual users like me should figure out what the matching strings are some other way? I assumed that, since I saw almost exactly the same performance degradation with \n as I did with this, that that was a valid testcase. If that was a bad assumption and this is insufficient to debug it, I can submit a bigger testcase. But if this issue is going to be wontfixed for some reason, there should certainly be a documentation note added, because it is not intuitive that splitting 5GB of data into 1000 strings of around 5MB each should be 10X faster than doing the same thing, but also capturing the 1K ten-byte strings inbetween the big ones. Thanks, Pat -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24426 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7267] format method: c presentation type broken in 2.7
Changes by Jakub Wilk jw...@jwilk.net: -- nosy: +jwilk ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7267 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24426] re.split performance degraded significantly by capturing group
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24426 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24420] Documentation regressions from adding subprocess.run()
Thomas Kluyver added the comment: Thanks, this looks good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24420 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17310] Ctypes callbacks shows problem on Windows Python (64bit)
Vinay Sajip added the comment:
I note that the code for CFFI has a fix in ffi_prep_incoming_args_SYSV, as
follows:
#ifdef _WIN64
if (z 8)
{
/* On Win64, if a single argument takes more than 8 bytes,
then it is always passed by reference. */
*p_argv = *((void**) argp);
z = 8;
}
else
#endif
*p_argv = (void*) argp; /* The original code, works for 32-bit */
(Source:
https://bitbucket.org/cffi/cffi/src/abc8ff5b2885b3d9f22bbb314a011b8dd63c9e14/c/libffi_msvc/ffi.c?at=default)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17310
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24426] re.split performance degraded significantly by capturing group
Patrick Maupin added the comment: Just to be perfectly clear, this is no exaggeration: My original file was slightly over 5GB. I have approximately 1050 bad strings in it, averaging around 11 characters per string. If I split it without capturing those 1050 strings, it takes 3.7 seconds. If I split it and capture those 1050 strings, it takes 39 seconds. ISTM that 33 ms to create a capture group with a single 11 character string is excessive, so there is probably something else going on like excessive object copying, that just isn't noticeable on a smaller source string. In the small example I posted, if I replace the line: data = 100 * (20 * ' ' + '\n') with data = 1000 * (50 * ' ' + '\n') then I get approximately the same 3.7 second vs 39 second results on that (somewhat older) machine. I didn't start out with that in the example, because I thought the problem should still be obvious from the scaled down example. Obviously, your CPU numbers will be somewhat different. The question remains, though, why it takes around 60 million CPU cycles for each and every returned capture group. Or, to put it another way, why can I stop doing the capture group, and grab the same string with pure Python by looking at the string lengths of the intervening strings, well over 100 times faster than it takes for the re module to give me that group? Thanks, Pat -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24426 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24408] tkinter.font.Font.measure() broken in 3.5
Ned Deily added the comment:
Test fails on OS X (10.10) with Cocoa Tk 8.6(.4) and 8.5(.18):
==
FAIL: test_families (test_tkinter.test_font.FontTest)
--
Traceback (most recent call last):
File
/py/dev/27/root/fwd/Library/Frameworks/pytest_10.10.framework/Versions/2.7/lib/python2.7/lib-tk/test/test_tkinter/test_font.py,
line 79, in test_families
self.assertIn(self.font.actual('family'), families)
AssertionError: '.Helvetica Neue DeskInterface' not found in ('Academy Engraved
LET', 'Al Bayan', 'Al Nile', 'Al Tarikh', 'American Typewriter', 'Andale Mono',
'Arial', 'Arial Black', 'Arial Hebrew', 'Arial Hebrew Scholar', 'Arial Narrow',
'Arial Rounded MT Bold', 'Arial Unicode MS', 'Athelas', 'Avenir', 'Avenir
Next', 'Avenir Next Condensed', 'Ayuthaya', 'Baghdad', 'Bangla MN', 'Bangla
Sangam MN', 'Bank Gothic', 'Baoli SC', 'Baskerville', 'Beirut', 'Big Caslon',
'Blackmoor LET', 'BlairMdITC TT', 'Bodoni 72', 'Bodoni 72 Oldstyle', 'Bodoni 72
Smallcaps', 'Bodoni Ornaments', 'Bordeaux Roman Bold LET', 'Bradley Hand',
'Brush Script MT', 'Capitals', 'Chalkboard', 'Chalkboard SE', 'Chalkduster',
'Charter', 'Cochin', 'Comic Sans MS', 'Copperplate', 'Corsiva Hebrew',
'Courier', 'Courier New', 'Damascus', 'DecoType Naskh', 'Devanagari MT',
'Devanagari Sangam MN', 'Didot', 'DIN Alternate', 'DIN Condensed', 'Diwan
Kufi', 'Diwan Thuluth', 'Euphemia UCAS', 'Farah', 'Farisi', 'Futura', 'GB18030 B
itmap', 'Geeza Pro', 'Geneva', 'Georgia', 'Gill Sans', 'Gujarati MT',
'Gujarati Sangam MN', 'GungSeo', 'Gurmukhi MN', 'Gurmukhi MT', 'Gurmukhi Sangam
MN', 'Hannotate SC', 'Hannotate TC', 'HanziPen SC', 'HanziPen TC', 'HeadLineA',
'Heiti SC', 'Heiti TC', 'Helvetica', 'Helvetica Neue', 'Herculanum', 'Hiragino
Kaku Gothic Pro', [...]
--
nosy: +ned.deily
resolution: fixed -
stage: resolved - needs patch
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24408
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17310] Ctypes callbacks shows problem on Windows Python (64bit)
Vinay Sajip added the comment: Although Matt was able to work around his problem, this problem seems to still be present in 2.7 as well as all 3.x versions. I think I've found the cause of the problem: in 64-bit code, the calling conventions for passing structures by value are different. From this page: https://msdn.microsoft.com/en-us/library/zthk2dkh(v=vs.90).aspx I would point to Structs/unions of size 8, 16, 32, or 64 bits and __m64 will be passed as if they were integers of the same size. Structs/unions other than these sizes will be passed as a pointer to memory allocated by the caller. For these aggregate types passed as a pointer (including __m128), the caller-allocated temporary memory will be 16-byte aligned. The code in ffi_prep_incoming_args_SYSV (see https://hg.python.org/cpython/file/a1b76c1c3be8/Modules/_ctypes/libffi_msvc/ffi.c#l368) assumes (see lines 399, 402) that all value parameters are always passed inline on the stack - which is plainly not as per the documentation I linked to, for 64-bit code. -- nosy: +vinay.sajip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17310 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17310] Ctypes callbacks shows problem on Windows Python (64bit)
Vinay Sajip added the comment: I can confirm that the CFFI patch works as expected on Python 2.7.10. -- stage: - test needed versions: +Python 3.4, Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17310 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24423] Fix wrong indentation in Doc/whatsnew/3.5.rst
Roundup Robot added the comment: New changeset 4e7dcf64bba7 by Ned Deily in branch '3.5': Issue #24423: Fix formatting error in 3.5 whatsnew https://hg.python.org/cpython/rev/4e7dcf64bba7 New changeset 3156dd82df2d by Ned Deily in branch 'default': Issue #24423: merger from 3.5 https://hg.python.org/cpython/rev/3156dd82df2d -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24423 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24423] Fix wrong indentation in Doc/whatsnew/3.5.rst
Ned Deily added the comment: Thanks for the report! -- nosy: +ned.deily resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24423 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24408] tkinter.font.Font.measure() broken in 3.5
Martin Panter added the comment: Some quick googling suggests this “.Helvetica Neue DeskInterface” font is real, and because it begins with a full stop it may be normally hidden from the normal list of fonts. Perhaps the test could be modified to just check the two functions separately: * families() returns a non-trivial sequence of font names * actual(family) returns a non-trivial string -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24408 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16864] sqlite3.Cursor.lastrowid isn't populated when executing a SQL REPLACE statement
Alex Lord added the comment: Adding a patch for 3.6 since 3.5 is in beta. -- versions: +Python 3.6 -Python 3.5 Added file: http://bugs.python.org/file39677/replace_lastrowid_3_6.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16864 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24425] Installer Vender Issue
New submission from Hayden Young: For some reason, my Python installer won't run properly. When I click install, after DISabling PIP in the installer (And with pip on), it tells me the following: There is a problem with this windows installer package. A program required for this install to complete cannot be run. Contact your support personnel or package vendor. Can anyone help me here? I really need Python for school, but my laptop won't run this properly. If it's to do with my specs, they are this: Laptop: Dell Latitude E6230 (Non-SSD) Core: Intel i5 Processor PLEASE HELP! -- components: Installation messages: 245132 nosy: Hayden Young priority: normal severity: normal status: open title: Installer Vender Issue versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24425 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24425] Installer Vender Issue
Changes by R. David Murray rdmur...@bitdance.com: -- components: +Extension Modules, Windows -Installation nosy: +paul.moore, steve.dower, tim.golden, zach.ware ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24425 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24425] Installer Vender Issue
Steve Dower added the comment: Can you run the following command and then post the log.txt file it generates: msiexec /l*vx log.txt /i path to the Python MSI -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24425 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24175] Consistent test_utime() failures on FreeBSD
koobs added the comment: test_utime is now consistently failing on 3.4, 3.5 and default -- priority: normal - high title: Sporadic test_utime() failures on FreeBSD - Consistent test_utime() failures on FreeBSD versions: +Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24175 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24324] Remove -Wunreachable-code flag
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24324 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23391] Documentation of EnvironmentError (OSError) arguments disappeared
Martin Panter added the comment: New patch with the following changes. Let me know what you think. * Added extra markup for OSError attributes and constructor signature * Explained how “winerror” works with and without Windows * Added “filename2” argument * Update tests for filename2 defaulting to None For reference, the argument handling seems to be in oserror_parse_args(), at Objects/exceptions.c:724, and related functions. -- versions: +Python 3.6 Added file: http://bugs.python.org/file39678/os-error-args.v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23391 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24324] Remove -Wunreachable-code flag
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24324 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24400] Awaitable ABC incompatible with functools.singledispatch
Yury Selivanov added the comment: With the two changes I described things appear to be working, although I've only done light testing so far. Glad to hear that! I've attached a new patch fixing types.coroutine per your request. More generally, the inconsistency between isgenerator() and iscoroutine() is kind of odd. I would expect that either all inspect functions or none of them would use a suitable ABC if one exists. iscoroutine() is just a newer API than isgenerator(). I'll create a new issue for this soon. -- Added file: http://bugs.python.org/file39675/corotype.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24400 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24379] slice.literal notation
Joe Jevnik added the comment: slice.literal[0] 0 y = slice.literal[1:2] slice(1, 2, None) slice.literal[0:1, ..., 3] (slice(0, 1, None), Ellipsis, 3) The way this object works right now does not create instances of some inner class of slice, instead, indexing it returns the key without modification. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24379 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
