[issue21028] ElementTree objects should support all the same methods as Element objects
Stefan Behnel added the comment: Add all the element methods to the elementtree object. Ok, but why? An ElementTree object *is not* an Element. It's a representation of a document that *has* a root Element. It makes sense for a document to allow searches over its content, and the ElementTree class currently supports that, using the find*() or iter() methods. They are deep or global content accessor shortcuts, in addition to the path through the normal getroot() method. But I can't see how making ElementTree objects look and behave like their own root Element improves anything. Instead, it would just make the distinction between the two completely unclear, and would also lead to quirks like the question why iterating over a document yields the second level of children. Or the question what the attrib property of a document could mean. Instead of blurring it, would you have an idea what we could improve in the documentation to make this distinction clearer? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21028 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21124] _struct module compilation error under Cygwin 1.7.17 on Python 3.4
dellair jie added the comment: Neil, It doesn't look like a duplicate of Issue6672. The one in Issue6672 was for Mingw, all the patches simply added __MINGW32__ to __CYGWIN__ build structure. While my issue is, the build failed with _struct.c on Cygwin. So the module is recognized, just didn't pass the compilation. Br, Dellair -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21124 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21028] ElementTree objects should support all the same methods as Element objects
Raymond Hettinger added the comment:
ElementTree class currently supports that,
using the find*() or iter() methods.
That would be great except that ElementTree doesn't actually have an __iter__
method.
Ok, but why?
The short answer is that every time I conduct Python training, people routinely
trip over this issue. The whole point of the ElementTree package was to have a
more pythonic interface than DOM or SAX. I'm sure there are people that argue
that the requests module isn't great because it conflates requesting with
authentication and password management, but the beauty of requests is that its
API matches how people try to use it. The outer ElementTree object is awkward
in this regard.
I don't see any benefit from having this code fail:
from xml.etree.ElementTree import parse
catalog = parse('books.xml')
for book in catalog:
print book.get('id')
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21028
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21028] ElementTree objects should support all the same methods as Element objects
Stefan Behnel added the comment:
I don't see any benefit from having this code fail:
from xml.etree.ElementTree import parse
catalog = parse('books.xml')
for book in catalog:
print book.get('id')
Why would you expect it to work? And how?
Why would it only iterate over the *children* of the root Element that it
wraps, and not yield the root Element itself, and maybe any preceding or
following processing instructions or comments, the doctype declaration, etc.?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21028
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21122] CPython fails to build modules with LLVM LTO on Mac OS X
Jonas Wagner added the comment: Thanks Ned, this is interesting! I don't know about Mac OS, but on Ubuntu, LTO and PGO apparently make Python around 10% faster (see #17781). However, that data point refers to GCC's LTO, not LLVM's. Personally I'm interested in LTO because I want to obtain whole-program LLVM bitcode files (for use in a research project about instrumentation). However, if there is something I can help (e.g., running benchmarks with different compilation settings), let me know. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21122 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21130] equivalent functools.partial instances should compare equal
New submission from Thomas Heller: I think that 'equivalent' functools.partial objects should compare equal, so the following snippet SHOULD print True: import functools f = lambda x: x a = functools.partial(f, 42) b = functools.partial(f, 42) a == b False -- components: Library (Lib) messages: 215363 nosy: theller priority: normal severity: normal status: open title: equivalent functools.partial instances should compare equal type: behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21130 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21122] CPython fails to build modules with LLVM LTO on Mac OS X
Ronald Oussoren added the comment: I've used -O4 for extensions in the past (which until recently implied LTO) and that worked fine. I'm pretty sure that I haven't used LTO for python itself, apart from a some tests with an early version llvm-gcc where using LTO for building python used to crash the compiler :-) BTW. There's no clear pattern in the missing symbols. The missing symbols for global functions could be due to aggressive inlining (and then deciding that the standalone function isn't needed anymore), but that is fairly unlikely and wouldn't explain the missing data symbols. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21122 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel = 3.10
New submission from Bohuslav Slavek Kabrda: test_faulthandler.test_register_chain fails on some 64bit architectures (arm8, ppc64) with kernel = 3.10: == FAIL: test_register_chain (__main__.FaultHandlerTests) -- Traceback (most recent call last): File /builddir/build/BUILD/Python-3.3.2/Lib/test/test_faulthandler.py, line 588, in test_register_chain self.check_register(chain=True) File /builddir/build/BUILD/Python-3.3.2/Lib/test/test_faulthandler.py, line 572, in check_register self.assertEqual(exitcode, 0) AssertionError: -11 != 0 I created a minimal reproducer (reproduces the issue on 3.3, 3.4 and dev) of this segfault (attached). When run with GC assertions turned on, Python fails with: python: /builddir/build/BUILD/Python-3.3.2/Modules/gcmodule.c:332: update_refs: Assertion `gc-gc.gc_refs == (-3)\' failed. We experienced this issue when building Python 3.3 on Fedora's arm8 builder [1], it seems that opensuse have experienced the same failure on ppc64 [2] and ubuntu has a similar issue in their 64bit arm builds [3]. It seems that this may be caused by a change in kernel, since it's only reproducible on kernel = 3.10. A nice explanation of what goes on and how the problem can be narrowed down is at the opensuse bug report [4], this is basically where I got stuck with this problem, too. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1045193 [2] https://bugzilla.novell.com/show_bug.cgi?id=831629 [3] https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1264354 [4] https://bugzilla.novell.com/show_bug.cgi?id=831629#c15 -- components: Tests files: test_register_chain_segfault_reproducer.py messages: 215365 nosy: bkabrda priority: normal severity: normal status: open title: test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel = 3.10 versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34699/test_register_chain_segfault_reproducer.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21131 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21122] CPython fails to build modules with LLVM LTO on Mac OS X
Ronald Oussoren added the comment: Have you tried the -export_dynamic option for ld(1): -export_dynamic Preserves all global symbols in main executables during LTO. Without this option, Link Time Optimization is allowed to inline and remove global functions. This option is used when a main executable may load a plug-in which requires certain symbols from the main executable. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21122 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21122] CPython fails to build modules with LLVM LTO on Mac OS X
Ronald Oussoren added the comment: This works for me (with a separate build directory): CC=clang CXX=clang++ CFLAGS=-g -flto LDFLAGS=-flto -Wl,-export_dynamic ../configure This is on OSX 10.9.2, with Xcode 5.1, and clang --version says: $ clang --version Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.1.0 Thread model: posix Tests are still running, but so far there are no unexpected failures. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21122 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel = 3.10
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21131 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel = 3.10
STINNER Victor added the comment:
test_faulthandler.test_register_chain fails on some 64bit architectures (arm8,
ppc64) with kernel = 3.10
I am a little bit surprised that the bug depends on the kernel version.
Does test_register_chain_segfault_reproducer.py also crash with chain=False?
Can you check if HAVE_SIGACTION is defined in pyconfig.h? Or in Python: import
sysconfig; print(sysconfig.get_config_var('HAVE_SIGACTION')).
Wit chain=True, faulthandler_register() registers its signal handler with
SA_NODEFER flag:
---
/* if the signal is received while the kernel is executing a system
call, try to restart the system call instead of interrupting it and
return EINTR. */
action.sa_flags = SA_RESTART;
if (chain) {
/* do not prevent the signal from being received from within its
own signal handler */
action.sa_flags = SA_NODEFER;
}
---
With chain=True, the faulthandler_user() function calls the previous signal
handler with:
---
#ifdef HAVE_SIGACTION
if (user-chain) {
(void)sigaction(signum, user-previous, NULL);
errno = save_errno;
/* call the previous signal handler */
raise(signum);
save_errno = errno;
(void)faulthandler_register(signum, user-chain, NULL);
errno = save_errno;
}
#else
if (user-chain) {
errno = save_errno;
/* call the previous signal handler */
user-previous(signum);
}
#endif
---
You can try to add #undef HAVE_SIGACTION in faulthandler.c (after #include
Python.h) to see if the bug can be reproduced without sigaction. The code
using signal() is very different, especially when chaining signal handlers.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21131
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21130] equivalent functools.partial instances should compare equal
Raymond Hettinger added the comment: Even equivalent functions don't compare as equal: (lambda x: x*x) == (lambda x: x*x) False -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21130 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel = 3.10
STINNER Victor added the comment: Would it be possible to list the kernel version (full version including the minor version) on which the test works or crash? You are talking about 3.10 without the minor version. It may be a regression in the kernel. Example of change in Linux kernel 3.10.17: --- commit 19a420033da02200c424adfa3a7b9eed6e3a6dc2 Author: Christian Ruppert christian.rupp...@abilis.com Date: Wed Oct 2 11:13:38 2013 +0200 ARC: Fix signal frame management for SA_SIGINFO commit 10469350e345599dfef3fa78a7c19fb230e674c1 upstream. Previously, when a signal was registered with SA_SIGINFO, parameters 2 and 3 of the signal handler were written to registers r1 and r2 before the register set was saved. This led to corruption of these two registers after returning from the signal handler (the wrong values were restored). With this patch, registers are now saved before any parameters are passed, thus maintaining the processor state from before signal entry. Signed-off-by: Christian Ruppert christian.rupp...@abilis.com Signed-off-by: Vineet Gupta vgu...@synopsys.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org --- Extract of changes of Linux 3.10.6: --- ARM: move signal handlers into a vdso-like page ARM: make vectors page inaccessible from userspace ARM: fix a cockup in 48be69a02 (ARM: move signal handlers into a vdso-like page) ARM: fix nommu builds with 48be69a02 (ARM: move signal handlers into a vdso-like page) --- Commit: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=48be69a02 I would like to make sure that the bug is not a kernel bug. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21131 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel = 3.10
Bohuslav Slavek Kabrda added the comment:
I'm also surprised that this depends on kernel version, however that's what I
found out (and the opensuse guys seem to only have reproduced this on kernel =
3.10, too).
- Full kernel version (uname -r output): 3.13.0-0.rc7.28.sa2.aarch64
- The reproducer *doesn't* crash with chain=False.
- HAVE_SIGACTION:
import sysconfig; print(sysconfig.get_config_var('HAVE_SIGACTION'))
1
- I'll do rebuild with #undef HAVE_SIGACTION and post my results here as soon
as it's finished.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21131
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18652] Add itertools.first_true (return first true item in iterable)
Roundup Robot added the comment: New changeset 3e2354dde892 by Raymond Hettinger in branch '3.4': Issue #18652: Add an itertools recipe for first_true() http://hg.python.org/cpython/rev/3e2354dde892 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18652 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18652] Add itertools.first_true (return first true item in iterable)
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18652 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel = 3.10
Bohuslav Slavek Kabrda added the comment: Ok, so with #undef HAVE_SIGACTION both the reproducer and the original test (as well as all tests in test_faulthandler) pass fine. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21131 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21130] equivalent functools.partial instances should compare equal
Thomas Heller added the comment: Sure. I'm not sure 'equivalent' is the word I should have used. I suggest (and I would have expected) that partial instances (a, b) should compare equal when a.func == b.func \ and a.args == b.args \ and a.keywords == b.keywords -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21130 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19662] smtpd.py should not decode utf-8
Sreepriya Chalakkal added the comment: Hi David, The variable decode_data is included to control decoding. But I am not sure what needs to be done while calling the process_message inside found_terminator when it is binary data. How to work around with binary data? Can you tell me what are the data types concerning binary data? -- Added file: http://bugs.python.org/file34700/switch_while_decode1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19662 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17846] Building Python on Windows - Supplementary info
Martin v. Löwis added the comment: The limitation of build.bat (as you also reported) is that it builds a debug build. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17846 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21130] equivalent functools.partial instances should compare equal
eryksun added the comment: Function equality is based on identity, as inherited from object. But there's a precedent for this idea in method_richcompare, which compares the method's __func__ and __self__: http://hg.python.org/cpython/file/04f714765c13/Objects/classobject.c#l208 -- nosy: +eryksun ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21130 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21132] Failure to import win32api
New submission from David Woakes: I've seen issue 21050 and tried a complete uninstall, delete c:\python34 and install of python 3.4. I can't get win32api to load unless I copy pythoncom34.dll and psywintypes34.dll to C:\Python34\Lib\site-packages\win32 from C:\Python34\Lib\site-packages\pywin32_system32. Here's output from a python -v session: import win32api Traceback (most recent call last): File stdin, line 1, in module File frozen importlib._bootstrap, line 2214, in _find_and_load File frozen importlib._bootstrap, line 2203, in _find_and_load_unlocked File frozen importlib._bootstrap, line 1191, in _load_unlocked File frozen importlib._bootstrap, line 1161, in _load_backward_compatible File frozen importlib._bootstrap, line 539, in _check_name_wrapper File frozen importlib._bootstrap, line 1692, in load_module File frozen importlib._bootstrap, line 321, in _call_with_frames_removed ImportError: DLL load failed: The specified module could not be found. import pdb; pdb.pm() # C:\Python34\lib\__pycache__\pdb.cpython-34.pyc matches C:\Python34\lib\pdb.py # code object from 'C:\\Python34\\lib\\__pycache__\\pdb.cpython-34.pyc' # C:\Python34\lib\__pycache__\re.cpython-34.pyc matches C:\Python34\lib\re.py # code object from 'C:\\Python34\\lib\\__pycache__\\re.cpython-34.pyc' # C:\Python34\lib\__pycache__\sre_compile.cpython-34.pyc matches C:\Python34\lib\sre_compile.py # code object from 'C:\\Python34\\lib\\__pycache__\\sre_compile.cpython-34.pyc' # C:\Python34\lib\__pycache__\sre_parse.cpython-34.pyc matches C:\Python34\lib\sre_parse.py # code object from 'C:\\Python34\\lib\\__pycache__\\sre_parse.cpython-34.pyc' # C:\Python34\lib\__pycache__\sre_constants.cpython-34.pyc matches C:\Python34\lib\sre_constants.py # code object from 'C:\\Python34\\lib\\__pycache__\\sre_constants.cpython-34.pyc' import 'sre_constants' # _frozen_importlib.SourceFileLoader object at 0x02EB21B0 import 'sre_parse' # _frozen_importlib.SourceFileLoader object at 0x02EAE4B0 import 'sre_compile' # _frozen_importlib.SourceFileLoader object at 0x027D4BF0 # C:\Python34\lib\__pycache__\copyreg.cpython-34.pyc matches C:\Python34\lib\copyreg.py # code object from 'C:\\Python34\\lib\\__pycache__\\copyreg.cpython-34.pyc' import 'copyreg' # _frozen_importlib.SourceFileLoader object at 0x02EB23B0 import 're' # _frozen_importlib.SourceFileLoader object at 0x027D44D0 # C:\Python34\lib\__pycache__\cmd.cpython-34.pyc matches C:\Python34\lib\cmd.py # code object from 'C:\\Python34\\lib\\__pycache__\\cmd.cpython-34.pyc' # C:\Python34\lib\__pycache__\string.cpython-34.pyc matches C:\Python34\lib\string.py # code object from 'C:\\Python34\\lib\\__pycache__\\string.cpython-34.pyc' import 'string' # _frozen_importlib.SourceFileLoader object at 0x02EB2CB0 import 'cmd' # _frozen_importlib.SourceFileLoader object at 0x02EAEDF0 # C:\Python34\lib\__pycache__\bdb.cpython-34.pyc matches C:\Python34\lib\bdb.py # code object from 'C:\\Python34\\lib\\__pycache__\\bdb.cpython-34.pyc' # C:\Python34\lib\__pycache__\fnmatch.cpython-34.pyc matches C:\Python34\lib\fnmatch.py # code object from 'C:\\Python34\\lib\\__pycache__\\fnmatch.cpython-34.pyc' # C:\Python34\lib\__pycache__\posixpath.cpython-34.pyc matches C:\Python34\lib\posixpath.py # code object from 'C:\\Python34\\lib\\__pycache__\\posixpath.cpython-34.pyc' import 'posixpath' # _frozen_importlib.SourceFileLoader object at 0x02EBBFD0 import 'fnmatch' # _frozen_importlib.SourceFileLoader object at 0x02EBBD30 # C:\Python34\lib\__pycache__\inspect.cpython-34.pyc matches C:\Python34\lib\inspect.py # code object from 'C:\\Python34\\lib\\__pycache__\\inspect.cpython-34.pyc' # C:\Python34\lib\__pycache__\ast.cpython-34.pyc matches C:\Python34\lib\ast.py # code object from 'C:\\Python34\\lib\\__pycache__\\ast.cpython-34.pyc' import 'ast' # _frozen_importlib.SourceFileLoader object at 0x02ED7D30 # C:\Python34\lib\importlib\__pycache__\__init__.cpython-34.pyc matches C:\Python34\lib\importlib\__init__.py # code object from 'C:\\Python34\\lib\\importlib\\__pycache__\\__init__.cpython-34.pyc' # C:\Python34\lib\__pycache__\warnings.cpython-34.pyc matches C:\Python34\lib\warnings.py # code object from 'C:\\Python34\\lib\\__pycache__\\warnings.cpython-34.pyc' import 'warnings' # _frozen_importlib.SourceFileLoader object at 0x02EF94B0 import 'importlib' # _frozen_importlib.SourceFileLoader object at 0x02EF92D0 # C:\Python34\lib\importlib\__pycache__\machinery.cpython-34.pyc matches C:\Python34\lib\importlib\machinery.py # code object from 'C:\\Python34\\lib\\importlib\\__pycache__\\machinery.cpython-34.pyc' import 'importlib.machinery' # _frozen_importlib.SourceFileLoader object at 0x02EF9410 # C:\Python34\lib\__pycache__\linecache.cpython-34.pyc matches C:\Python34\lib\linecache.py # code object from 'C:\\Python34\\lib\\__pycache__\\linecache.cpython-34.pyc' # C:\Python34\lib\__pycache__\tokenize.cpython-34.pyc matches C:\Python34\lib\tokenize.py # code object from
[issue21124] _struct module compilation error under Cygwin 1.7.17 on Python 3.4
Masayuki Yamamoto added the comment: I wrote a patch file. In other extention module source codes, global variable PyTypeObject has initialized to using PyVarObject_HEAD_INIT(NULL, 0). And so, as with other modules, I tried to edit and compiling _struct.c in Cygwin 1.7.28. The module compiling was passing, And struct module passed a test python3.4 -m test test_struct. -- keywords: +patch nosy: +masamoto Added file: http://bugs.python.org/file34701/3.4-struct.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21124 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21133] unittest discover should allow option to run each package separately
New submission from the mulhern: You can run python -m unittest discover some args and the unittests discovered by discover will be run. This is nice. However, it is actually desirable to run each unittest package individually, rather than in the same interpreter instance. When run via discover, imports from previous unittests corrupt the namespace of subsequent unittests and lead to failures (usually if there are mock objects in previously imported unit tests) and successes (usually if some other test module has imported something that the current test module ought to import but does not) which are both erroneous. discover should have some option to start the interpreter afresh for each unittest package or perhaps just clear all its imports. -- components: Library (Lib) messages: 215380 nosy: the.mulhern priority: normal severity: normal status: open title: unittest discover should allow option to run each package separately type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21133 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20375] ElementTree: Document handling processing instructions
Eli Bendersky added the comment: I left some comments in Rietveld. There shouldn't be a problem getting these into 3.4 too - doc changes are usually excempt from most restrictions. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20375 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21028] ElementTree objects should support all the same methods as Element objects
Eli Bendersky added the comment: Do you have concrete suggestions? Make the tree iterable? Add all element methods to the tree, implicitly forwarding to the root? Yes, that is the feature request. Add all the element methods to the elementtree object. Implicitly forwarding to the root would be a reasonable way to do it, but that is just an implementation detail. Porting over all methods of Element to ElementTree sounds like an overkill to me. How about just making a sensibly-behaving __iter__ for ElementTree? This should be easy because ElementTree already has a iter() method that behaves as needed (goes over all elements including root). Would iteration + perhaps clearer documentation solve most of the problem? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21028 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21128] testing stdlib and compatibility with pypy
Changes by Brett Cannon br...@python.org: -- nosy: +brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21128 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21028] ElementTree objects should support all the same methods as Element objects
Stefan Behnel added the comment: How about just making a sensibly-behaving __iter__ for ElementTree? Well, the problem is to determine what sensibly-behaving is. I can see three options. 1) tree.iter() == tree.getroot().iter() 2) iter(tree.getroot()) 3) iter([tree.getroot()]) The second option feels plain wrong to me. The last one would allow the extension towards PI/comment siblings, as I described before. There isn't currently a way to get at them (which doesn't hurt, because ET doesn't currently even pass them through from its parser, as discussed in issue 9521). Once there is a way in ET to parse them in (as in lxml), making ElementTree objects iterable would nicely solve the issue of how to process them afterwards. It's not the only solution for that problem, though, adding a .gettoplevel() method would similarly work. Thus, either 1) or 3) would fit the API, with the downside of 1) being that it's just completely redundant functionality and I don't consider saving 7 simple characters worth the increase in API overhead. That leaves 3) as an option. It's nice because the iteration then works on the same axis as for Elements, so x.iter() and iter(x) would behave in the same way for both classes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21028 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21134] Segfault when stringifying UnicodeEncodeError (or UnicodeDecodeError) created with __new__()
New submission from Marek Kowalski: I'm attaching a minimal script to reproduce. I tested only with 3.2 and 2.7 versions. Its possible that it has been fixed since 3.2. -- components: Unicode files: segv.py messages: 215384 nosy: Marek.Kowalski, ezio.melotti, haypo priority: normal severity: normal status: open title: Segfault when stringifying UnicodeEncodeError (or UnicodeDecodeError) created with __new__() type: crash versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file34702/segv.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21134 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21124] _struct module compilation error under Cygwin 1.7.17 on Python 3.4
dellair jie added the comment: Yamamoto, Thanks, the patch you offered did make the _struct error disappeared. I will do a bit more testing. Dellair -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21124 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21134] Segfault when stringifying UnicodeEncodeError (or UnicodeDecodeError) created with __new__()
STINNER Victor added the comment: Python 3.2 is not getting bugfixes anymore, only 3.4 and 3.5 (and 2.7). -- versions: +Python 3.4, Python 3.5 -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21134 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21120] PyArena type is used in headers from the limited API
Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21120 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21118] str.translate is absurdly slow in majority of use cases (takes up to 60x longer than similar functions)
Antoine Pitrou added the comment: bytes.translate() is much faster because it builds a C array of 256 items to fast table lookup, whereas str.translate() requires a Python dict lookup for each character, which is much slower. It should be easy to devise a simple hash table for the common case of one-to-one translation (and also deletion). -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21118 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17390] display python version on idle title bar
bagrat lazaryan added the comment: guys, the filename should be the first thing on the titlebar of idle editor window. that way, on taskbar, one can see the file that's open in editor. i suggest the format of editor's title be changed to: xxx.py - python x.y.z - path or whatever you will as separator between elements. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17390 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21134] Segfault when stringifying UnicodeEncodeError (or UnicodeDecodeError) created with __new__()
Roundup Robot added the comment: New changeset 140c5da3dc82 by Benjamin Peterson in branch '3.4': bail in unicode error's __str__ methods if the objects are not properly initialized (closes #21134) http://hg.python.org/cpython/rev/140c5da3dc82 New changeset afa7fb2cbe3b by Benjamin Peterson in branch '2.7': bail in unicode error's __str__ methods if the objects are not properly initialized (closes #21134) http://hg.python.org/cpython/rev/afa7fb2cbe3b New changeset 0aeaea247d7d by Benjamin Peterson in branch 'default': merge 3.4 (#21134) http://hg.python.org/cpython/rev/0aeaea247d7d -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21134 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21134] Segfault when stringifying UnicodeEncodeError (or UnicodeDecodeError) created with __new__()
STINNER Victor added the comment: Benjamin: I don't like your change. You silently ignore the error. I would prefer to raise an exception on str(exc) if the Unicode exception object was not properly initialized. -- resolution: fixed - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21134 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21134] Segfault when stringifying UnicodeEncodeError (or UnicodeDecodeError) created with __new__()
Benjamin Peterson added the comment: I don't care as long as it doesn't segfault. -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21134 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21019] PyMethodDef ml_name is char* instead of const char*
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21019 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21027] difflib new cli interface
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21027 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21034] Python docs reference the Distribute package which has been deprecated in favor of Setuptools
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21034 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17846] Building Python on Windows - Supplementary info
Terry J. Reedy added the comment: Since a debug build (F7 in VS) is the only thing I have ever built, or that a developer like me needs to build, that is not a limitation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17846 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17390] display python version on idle title bar
Terry J. Reedy added the comment: Bagrat, are you on XP by any chance? In Win7, all windows for a program are attached to one program icon on the taskbar, which has the program name. When I hover over the program icon, mini views of each window are displayed, with each window view showing about 30 chars of the window title. For instance Python 3.4.0: CallTipsWindow, which is fine for me. Moving the mouse over the mini window displays the complete title. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17390 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20942] _frozen_importlib should not have a __file__ attribute
Boštjan Mejak added the comment: No one interested in fixing this anymore, despite the patch and all? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20942 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20942] _frozen_importlib should not have a __file__ attribute
Brett Cannon added the comment: My Python free time is on Fridays, which is when I plan to make a final call and either apply to Python 3.4 and 3.5 or just Python 3.5. -- assignee: - brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20942 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21135] Remove useless _vb_pattern parameter in cgi.valid_boundary
New submission from Eijebong: The parameter _vb_pattern parameter in cgi.valid_boundary has no reason to exist since it's forced to a value later. -- components: Library (Lib) files: valid_boundary.patch keywords: patch messages: 215396 nosy: Eijebong priority: normal severity: normal status: open title: Remove useless _vb_pattern parameter in cgi.valid_boundary type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file34703/valid_boundary.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21135 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21130] equivalent functools.partial instances should compare equal
Raymond Hettinger added the comment: What is the use case? What would be the criteria for comparing functions? Would the func_name have to match? Would the func_defaults have to match? Would the f.__code__.co_names have to match (the internal variable names? Do the function attributes in f.__dict__ have to match? Does the func.__doc__ have to match? The problem is that functions are complex objects and the equivalence criteria means different things to different people. In the absence of a clear spec that makes sense to most people, object identity is the only sure definition of equivalence. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21130 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19662] smtpd.py should not decode utf-8
Changes by Sreepriya Chalakkal sreepriya1...@gmail.com: Added file: http://bugs.python.org/file34704/switch_while_decode2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19662 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19640] Dynamically generate the _source attribute of namedtuple to save memory)
Raymond Hettinger added the comment: Victor, I don't think the added complexity is worth 2k per named tuple class. Every time I've gone down the path of lazy evaluation, I've paid an unexpected price for it down the road. If the savings were huge, it might be worth it, but that isn't the case here. This isn't really different than proposing that all docstring be in a separate module to be lazily loaded only when people look at help. -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19640 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17390] display python version on idle title bar
bagrat lazaryan added the comment: terry, i'm on 7 but i have my taskbar configured not to combine buttons. see the screenshot attached. (does anyone know why on earth i am not receiving email notifications when someone posts to an issue i have started or i have commented to?) -- Added file: http://bugs.python.org/file34705/taskbar.png ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17390 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17862] itertools.chunks(iterable, size, fill=None)
Raymond Hettinger added the comment: Nothing new is happening in this thread, so I'm closing it for the reasons listed in the other posts. The main issue is that the generic concept of break data into chunks tends to occur is situations where the iterator protocol would be at odds with a clean solution. A reshape() method on lists would be much better suited to the task. -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17862 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20198] xml.etree.ElementTree.ElementTree.write attribute sorting
bagrat lazaryan added the comment: well... ElementTree.py imports some c accelerators as can be seen at the end of the file. i have no idea how to get to those accelerators, and even if i had, i don't think i would make anything of them. as far as the pure python code concerns in the rest of ElementTree.py, it suffices not to sort the items in _serialize_xml: line 929 of ElementTree.py: -for k, v in sorted(items): # lexical order +for k, v in items: i gather something similar must be done in c accelerators. (by the way, does anyone know why i am not receiving email notifications when someone posts to an issue i have started or i have commented to?) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20198 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20198] xml.etree.ElementTree.ElementTree.write attribute sorting
Changes by bagrat lazaryan bagra...@live.com: -- versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20198 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21130] equivalent functools.partial instances should compare equal
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- Removed message: http://bugs.python.org/msg215397 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21130 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21117] inspect.signature: inaccuracies for partial functions
Yury Selivanov added the comment: Please review the attached patch. Here's the new partial signature semantics: foo(a, b, /, c, d, *args, e) partial(foo, 10) - (b, /, c, d, *args, e) partial(foo, 10, c=11) - (b, /, *, c=11, d, e) partial(foo, 10, 20, 30) - (d, *args, e) partial(foo, 10, 20, 30, 40, 50) - (*args, e) partial(foo, 10, 20, c=20) - (*, c=20, d, e) Good news: 1. no more special attributes and other hidden hacks. 2. only with this patch we properly support functools.partial. So this is definitely something we can classify as a bug fix and push in 3.4.1. -- keywords: +patch Added file: http://bugs.python.org/file34706/signature_partial_fix_01.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21117 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21130] equivalent functools.partial instances should compare equal
R. David Murray added the comment: But since the two partial instances are (conceptually, I don't care how they are implemented) two separate functions, then reasoning by analogy from two identical functions not comparing equal, I would expect two partial instances to not compare equal. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21130 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21116] Failure to create multiprocessing shared arrays larger than 50% of memory size under linux
Charles-François Natali added the comment: Zero-filling mmap's backing file isn't really optimal: why not use truncate() instead? This way, it'll avoid completely I/O on filesystems that support sparse files, and should still work on FS that don't. -- nosy: +neologix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21116 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21130] equivalent functools.partial instances should compare equal
R. David Murray added the comment: Of course, as soon as I hit send, I had second thoughts :). I guess a partial is a binding, not a function. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21130 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17390] display python version on idle title bar
Ezio Melotti added the comment:
Other editors (e.g. Kate) use the format filename - editor name. This is
common for other applications as well (e.g. Firefox uses page title - Mozilla
Firefox), so the request seems reasonable to me.
If you want to go the extra mile you could have an option to decide if the
filename should be first or not or even a format string that would allow users
to fully configure the titlebar (e.g. {file} - IDLE {version}), but that
might be out of the scope of this issue. FWIW I don't think Kate has an option
for that, but it has one to show the full path in titlebar.
(@bagrat: assuming your email address is correct, if you are not getting
notifications they might have ended up in the spam folder.)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17390
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21116] Failure to create multiprocessing shared arrays larger than 50% of memory size under linux
Médéric Boquien added the comment: If I remember correctly the problem is that some OS like linux (and probably others) do not really allocate space until something is written. If that's the case then the process may get killed later on when it writes something in the array. Here is a quick example: $ truncate -s 1T test.file $ ls -lh test.file -rw-r--r-- 1 mederic users 1.0T Apr 2 23:10 test.file $ df -h Filesystem Size Used Avail Use% Mounted on /dev/sdb1 110G 46G 59G 44% /home -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21116 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21116] Failure to create multiprocessing shared arrays larger than 50% of memory size under linux
Richard Oudkerk added the comment: Using truncate() to zero extend is not really portable: it is only guaranteed on XSI-compliant POSIX systems. Also, the FreeBSD man page for mmap() has the following warning: WARNING! Extending a file with ftruncate(2), thus creating a big hole, and then filling the hole by modifying a shared mmap() can lead to severe file fragmentation. In order to avoid such fragmentation you should always pre-allocate the file's backing store by write()ing zero's into the newly extended area prior to modifying the area via your mmap(). The fragmentation problem is especially sensitive to MAP_NOSYNC pages, because pages may be flushed to disk in a totally random order. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21116 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21136] fractions.Fraction.__pow__ does unneeded renormalization
New submission from William Ehlhardt: The following Python runs unnecessarily slowly: import fractions fractions.Fraction(6249919, 625) ** 89993 The problem here is that Fraction.__pow__ constructs a new Fraction() to return, and Fraction.__new__ tries to gcd to normalize the numerator/denominator. The gcd is very, very slow, and more to the point, unnecessary; raising a normalized fraction to an integer power will always yield another normalized fraction. fractions.Fraction.__pow__ should use this trick to make the code snippet above fast. -- components: Library (Lib) messages: 215409 nosy: Orborde priority: normal severity: normal status: open title: fractions.Fraction.__pow__ does unneeded renormalization type: performance versions: Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21136 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21136] fractions.Fraction.__pow__ does unneeded renormalization
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti, mark.dickinson, rhettinger stage: - needs patch versions: +Python 3.5 -Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21136 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
paul j3 added the comment: There are a couple of complications to using 'fileno'. We probably don't want to close 'sys.stdin' or 'sys.stdout' (not even if they are redirected to other files?). That means using: open(sys.stdin.fileno(), ..., closefd=False) 'closefd', on the other hand, has to be True for string file specifications. But in 'test_argparse.py', 'sys.stdout' is redirected to an 'io.StringIO'. This has many of the same features as an open file, but 'fileno' is not implemented. So the TypeFile probably needs to make an exception for this case. I don't how this will play with a 'BytesIO' for 'wb' cases. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14156 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1191964] asynchronous Subprocess
Josiah Carlson added the comment: Had some time to work on this today. I was missing something in my earlier versions of the code, and have managed to get overlapped IOs to work, so at least I'm not quite so far behind the dozen or so core developers who know more about the Windows pieces than I do. Richard, thank you for the post, I wasn't looking hard enough for how to get overlapped IOs to work, and your message made me look harder. On Linux, it is trivial to support the blocking communicate() and non-blocking additions. There's only one weirdness, and that's the fcntl bit flipping during write. On Windows, it's not all that difficult to switch to using overlapped IOs for *all* writes, and maybe even for communicate()-based reads, which would remove the need for threads. Ironically enough, non-blocking reads actually *don't* require overlapped IO thanks to PeekNamedPipe, which could even be used to cut the number of extra threads from 2 to 1 in communicate(). Now that I've got it working, I can do one of the following (from least changes to the most): 1. Add a nonblocking flag, which pre-flips the fcntl bit in Linux and uses overlapped IO on writes in Windows - this would be documented to remove the ability to call communicate() 2. As an alternative to #1, I can create a new class that lacks the communicate() method and adds the non-blocking methods 3. Gut/rewrite the Windows-based communicate() function to use overlapped IO on everything, removing the threads, and making it at least superficially like Linux (prepare your overlapped IO, then use WaitForMultipleObjects() to multiplex), while also adding the non-blocking methods Unless someone brings up an important counterpoint, I'll work on #3 tonight or tomorrow evening to get an initial code/test patch, with docs coming shortly after (if not immediately). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1191964 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21136] fractions.Fraction.__pow__ does unneeded renormalization
Raymond Hettinger added the comment: This looks easily doable. -- assignee: - rhettinger keywords: +easy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21136 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21137] Better repr for threading.Lock()
New submission from Raymond Hettinger: It is really nice to have the open/closed status in the __repr__ of file objects: open file 'data.txt', mode 'r' at 0x102c8ec90 closed file 'data.txt', mode 'r' at 0x102c8ec90 I would like to have the same for locks: unlocked thread.lock object at 0x1002b1330 locked thread.lock object at 0x1002b1330 This would be nice in logs and tracebacks for example. -- components: Library (Lib) keywords: easy messages: 215413 nosy: rhettinger priority: normal severity: normal status: open title: Better repr for threading.Lock() type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21137 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21136] fractions.Fraction.__pow__ does unneeded renormalization
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file34707/fraction_pow.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21136 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21138] mimetypes.MimeType UnicodeDecodeError
New submission from tanbro: when new a mimetypes.MimeType instance in a my Windows, whose default coding is mbcs, UnicdeDecodeError occurred. Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)] on win 32 Type help, copyright, credits or license for more information. from mimetypes import MimeTypes mt = MimeTypes() Traceback (most recent call last): File stdin, line 1, in module File D:\Python27\lib\mimetypes.py, line 66, in __init__ init() File D:\Python27\lib\mimetypes.py, line 358, in init db.read_windows_registry() File D:\Python27\lib\mimetypes.py, line 258, in read_windows_registry for subkeyname in enum_types(hkcr): File D:\Python27\lib\mimetypes.py, line 249, in enum_types ctype = ctype.encode(default_encoding) # omit in 3.x! UnicodeDecodeError: 'ascii' codec can't decode byte 0xc7 in position 8: ordinal not in range(128) i think this error was caused by the code in mimetypes.py's line 256 default_encoding = sys.getdefaultencoding() if change this line to: default_encoding = sys.getfilesystemencoding() such error will be resolved -- components: Library (Lib) messages: 215414 nosy: tanbro priority: normal severity: normal status: open title: mimetypes.MimeType UnicodeDecodeError type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21138 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20375] ElementTree: Document handling processing instructions
Nikolaus Rath added the comment: Thanks for your feedback! I've attached an updated patch. -- Added file: http://bugs.python.org/file34708/issue20375.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20375 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20375] ElementTree: Document handling processing instructions
Changes by Nikolaus Rath nikol...@rath.org: Added file: http://bugs.python.org/file34709/issue20375.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20375 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21137] Better repr for threading.Lock()
Berker Peksag added the comment: Here's a patch with a test. Example repr of threading.Lock(): $ ./python -c import threading; print(threading.Lock()) unlocked _thread.lock object -- keywords: +patch nosy: +berker.peksag Added file: http://bugs.python.org/file34710/issue21137.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21137 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21139] Idle: change default reformat width from 70 to 72
New submission from Terry J. Reedy: PEP 8 specifies a limit of 72 chars for flowing text (comments, multiline strings). The current default limit for Idle's Format / Reformat Paragraph is 70. Increase it to PEP 8's 72. -- messages: 215417 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: Idle: change default reformat width from 70 to 72 type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21139 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21139] Idle: change default reformat width from 70 to 72
Changes by Terry J. Reedy tjre...@udel.edu: -- components: +IDLE ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21139 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21138] mimetypes.MimeType UnicodeDecodeError
tanbro added the comment: and in line 249, changes: if isinstance(ctype, unicode): ctype = ctype.encode(default_encoding) # omit in 3.x! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21138 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21140] Idle: saving an OutputWindow should default to .txt
New submission from Terry J. Reedy: If possible, when saving an instance of an OutputWindow, the file type should default to .txt (or possibly even nothing) instead of .py. At present, OutputWindows are only used for Find in Files (grep) output, which is very much not Python code. The same should be true of any other OutputWindow uses, which I except there will be, making OutputWindow saves more common. A patch should be tested and verified on Mac, Linux, and Windows. -- components: IDLE messages: 215419 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: Idle: saving an OutputWindow should default to .txt type: behavior versions: Python 2.7, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21140 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1191964] asynchronous Subprocess
eryksun added the comment: multiprocessing.connection uses the _winapi module for overlapped I/O and named pipes in case you're looking for examples: http://hg.python.org/cpython/file/3.4/Lib/multiprocessing/connection.py -- nosy: +eryksun ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1191964 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21141] Don't mention Perl in Windows build output
New submission from Zachary Ware: Attached is a patch that prevents mentioning Perl in the Windows build output, thereby avoiding giving the indication that Perl is necessary to build Python. To make this work, the patch converts PCbuild/build_ssl.py into PCbuild/prepare_ssl.py and removes the actual building of OpenSSL from that script. Instead, prepare_ssl.py takes a directory name as an argument (which is assumed to be a directory containing OpenSSL sources) and does what it has always done to prepare the way for building, except now it does it for both platforms. PCbuild/build_ssl.bat is also updated to match. Meanwhile, the actual building is moved entirely within ssl.vcxproj, which now runs a short script that copies buildinf*.h and opensslconf*.h into place and calls nmake with the appropriate makefile (x64 builds also run the appropriate nasm command first). Since this is all done inside ssl.vcxproj, the dependency on python.vcxproj is dropped, allowing SSL to be built in parallel with pythoncore, tcl, tk, and tix when using the '/m' msbuild command line switch. As a part of converting build_ssl.py into prepare_ssl.py, the comments at the top of the file have been updated. Also, some dead code has been trimmed: the -a flag has been completely unused for a long time, and debug builds have been disabled as well; all code relating to either feature has been removed. I've tested this by successfully preparing (once) and building openssl-1.0.1f in both 32 and 64 bit builds. -- components: Build, Windows files: no_perl.diff keywords: patch messages: 215421 nosy: loewis, terry.reedy, tim.golden, zach.ware priority: normal severity: normal stage: patch review status: open title: Don't mention Perl in Windows build output type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file34711/no_perl.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21141 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17390] display python version on idle title bar
Terry J. Reedy added the comment: The general issue of Idle title bars is definitely not finished, though I may close this issue and open others. 1. 'Python' versus Idle' versus neither in titles (assuming not both). 1a. Shell: Since the link in msg183874 is dead, I don't know what Bagrat suggested. I said 'Python' in msg183932, hinted 'Idle' in msg184620, and pushed the patch that had 'Python'. I could argue either way, but 'Python x.y.z Shell' (versus 'Idle x.y.z Shell') works as the name of the Idle product and also identifies what will run the code entered. I am now thinking 'neither' and propose making the title 'Shell x.y.z' -- see the more on this below. 1b. Editor: The patch I applied followed the same pattern, and again, I could argue for either 'Idle x.y.z' (what is doing the editing) or 'Python x.y.z' (what will run the code with F5)'. In this and the shell case, the version is the most important new information. If we consider the titles of other windows (see still more below), I think the class title should be 'Editor x.y.z'. 1c. OutputWindow: This is a bit tougher. 'Output' only works, sort of, as long as the class is only used for FIF, (Find in Files, grep). The initial title is actually '*Output*', indicating unsaved content, with no file name specified. Once saved, the title changes to Output - file name. This is a precedent for 'Editor - file name' Since this issue started about adding versions, and version is not relevant to this and the following windows, a patch for OutputWindows should be a new issue. However, the design options need to be considered together. 1d. Read-only windows: We have Debug Control, Path Browser, and Class Browser - Output Window. (For the last, - Output Window should go since it adds nothing and misleads in that the window is not an OutputWindow. It could be replaced with the class name.) 2. Order of generic and specific (or class and instance) components. Most windows have a generic title for windows of a class. Part of my thinking above in suggesting 'Shell x.y.z' and 'Editor x.y.z' for the respective classes is that none of the class titles should contain either 'Python' or 'Idle' [separate? issue 0 -- it would be a correction of the patches on this issue]. Once an OutputWindow is saved, its title has a generic and specific component, in that order. The specific component identifies the specific contents of the instance. While I expect to replace 'Output' with names that reflect the subclasses of usage, the pattern will remain the same [separate issue 1]. Before we added a generic component for editor windows, they were unique in not having one. They currently follow the output pattern. I am also thinking a giving the title for ClassBrowswer (which is really ModuleBrowser) a specific component -- the module name [separate issue 2]. My point is that we have gone from one generic-specific (class-instance) name pair to two, and soon to more. If someone wants one pair flipped, then it seems logical to me that the same person would want all such pairs flipped, for the same reason. Bagrat, is this true for you? I know you only mentioned editor pairs, but you may not have known about output pairs, and certainly not future pairs that do not exist yet. I am willing to consider a user-settable option [separate issue 3], but I would think it should cover all such pairs, and not just editor window pairs. Currently, editor window titles are also unique in repeating part of the specific title. Output windows, when saved, do not repeat the short file name. Do any other editor programs do this? I expect we may decide to eliminate the redundancy as it exist now. Notepad++ puts complete path - Notepad++ on the title bar and the filename on the notebook tab. When the tabbed selected changes, the title bar changes. Firefox does the title to match the tab also. There is already an issue to use tabbed notebooks with Idle and when we do that, I would expect to remove the duplication in the title and imitate Notepad++. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17390 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20550] Use specific asserts in collections tests
Raymond Hettinger added the comment: Sorry, I don't think this makes the tests any better as all. It is code churn for no benefit. In our own code, the more specific tests risk hiding important details behind the abstraction (losing knowledge of what is actually tested). For example, I don't like that assertIn actually does a not in test or that assertIsNot runs is. In those two cases, it doesn't make a difference but does hint at the loss of knowledge. Also, changing tests carries a higher set of risks than changing other code because there are no tests-for-the-tests. This means that it would easy to accidentally break a test from testing what it is supposed to and not know about it. The has a nicer error message is a vacuous promise. The new output: Traceback (most recent call last): File /Users/raymond/Documents/tmp14.py, line 10, in test_one self.assertIs(a, b) AssertionError: a is not b Isn't any better than the current output: Traceback (most recent call last): File /Users/raymond/Documents/tmp14.py, line 13, in test_two self.assertTrue(a is b) AssertionError: False is not true Both of them show a failing is test and the first one mysteriously outputs is not which is technically a different operator (albeit, unimportantly so). -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20550 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19505] OrderedDict views don't implement __reversed__
Raymond Hettinger added the comment: This is approved. Go ahead and apply the patch. One minor nit, please position the three new views classes before the _Link class rather than after. -- assignee: rhettinger - serhiy.storchaka versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19505 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
