[issue24018] add a Generator ABC
Stefan Behnel added the comment: Good catch with the RuntimeError. Patch updated. -- Added file: http://bugs.python.org/file39157/generator_abc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24018 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24018] add a Generator ABC
Stefan Behnel added the comment: should inspect.isgenerator() be changed? Replying to myself, one thing that speaks against this approach is that inspect also has the functions getgeneratorlocals() and getgeneratorstate(), which depend on gen.gi_frame. Cython could emulate that, but normal user code usually can't. It's definitely not part of the Generator protocol but an implementation detail of GeneratorType. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24018 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16840] Tkinter doesn't support large integers
Roundup Robot added the comment: New changeset 5116916e4f7f by Serhiy Storchaka in branch '2.7': Issue #16840. Turn off bignum support in tkinter with with Tcl earlier than 8.5.8 https://hg.python.org/cpython/rev/5116916e4f7f -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16840 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24020] threading.local() must be run at module level (doc improvement)
Paul Moore added the comment: I should also say, I'll try to work up a doc patch for this, once I've got my head round how to explain it :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24020 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24020] threading.local() must be run at module level (doc improvement)
Eric Snow added the comment: FYI, I've used thread-local namespaces with success in several different ways and none of them involved binding the thread-local namespace to global scope. I don't think anything needs to be fixed here. The SO answer is misleading and perhaps even wrong. The problem it describes is about sharing the thread-local NS *between function calls*. Persisting state between function calls is not a new or mysterious problem, nor unique to thread-local namespaces. In the example they give, rather than a global they could have put it into a default arg or into a class: def hi(threadlocal=threading.local()): ... class Hi: threadlocal = threading.local() def __call__(self): ... # change threadlocal to self.threadlocal hi = Hi() This is simply a consequence of Python's normal scoping rules (should be unsurprising) and the fact that threading.local is a class (new instance per call) rather than a function (with the assumption of a singleton namespace per thread). At most the docs could be a little more clear that threading.local() produces a new namespace each time. However, I don't think even that is necessary and suggest closing this as won't fix. -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24020 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23008] pydoc enum.{,Int}Enum fails
Roundup Robot added the comment: New changeset d1b9eb9de8af by Serhiy Storchaka in branch '2.7': Issue #23008: Fixed resolving attributes with boolean value is False in pydoc. https://hg.python.org/cpython/rev/d1b9eb9de8af New changeset a480f470c469 by Serhiy Storchaka in branch '3.4': Issue #23008: Fixed resolving attributes with boolean value is False in pydoc. https://hg.python.org/cpython/rev/a480f470c469 New changeset 03330e5edb37 by Serhiy Storchaka in branch 'default': Issue #23008: Fixed resolving attributes with boolean value is False in pydoc. https://hg.python.org/cpython/rev/03330e5edb37 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23008 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24019] str/unicode encoding kwarg causes exceptions
Mahmoud Hashemi added the comment: Python already has one approach that fails to decode non-bytestrings: the .decode() method. This is about removing unicode barriers to entry and making the str constructor in Python 3 as succinctly useful as possible. There are several problems the helper does not solve: 1) Usage-wise, str/unicode is used to turn values into text. From a high-level perspective, the content does not change, only the representation format. Should this fundamental operation really require type inspection and explicit try/except blocks every single time? Or should it just work? sorted() does not raise an exception if the values are already sorted, why does str() raise an exception when the value is already a str?* 2) By and large, among developers, keyword arguments are viewed as optional arguments that have defaults which can be overridden. However, that is not the case here; str is not simply str(obj, encoding=sys.getdefaultencoding()). Explicitly passing the keyword argument breaks the call. 3) The helper does not help promote Python adoption when it must be copied and pasted it into new developer's projects. It does not help break down the misconception that unicode is a punishing concept to be around in Python. * This question is posed here rhetorically, but I have gotten variations on it from multiple Python developers in training. -- versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24019 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24020] threading.local() must be run at module level (doc improvement)
Paul Moore added the comment: That seems to merely be saying that each threading.local() object is distinct, so if you want to share threadlocal data between workers, creating local objects won't work. I think I see what the confusion is (although I can't quite explain it yet, I'll need to think some more about it) but threading.local() needs to be run at global scope is not accurate (for example, if I understand correctly, a class attribute which is a threading.local value would work fine, and it's not global scope. Basically, each time you call threading.local() you get a brand new object. It looks like a dictionary, but in fact it's a *different* dictionary for each thread. Within one thread, though, you can have multiple threading.local() objects, and they are independent. The wrong code in the SO discussion created a new threading-local() object as a local variable in a function, and tried to use it to remember state from one function call to the next (like a C static variable). That would be just as wrong in a single-threaded program where you used dict() instead of threading.local(), and for the same reasons. I don't know what your code was doing, so it may well be that the problem you were encountering was more subtle than the one on the wont_work() function. But threading.local() must be run in global scope is *not* the answer (even if doing that resulted in your problem going away). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24020 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21483] Skip os.utime() test on NFS?
Skip Montanaro added the comment: Any chance this will make it into 3.5? It's not a big deal, but I notice that it's still present in 3.5.0a4. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21483 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23008] pydoc enum.{,Int}Enum fails
Changes by Serhiy Storchaka storch...@gmail.com: -- assignee: - serhiy.storchaka resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23008 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24018] add a Generator ABC
Stefan Behnel added the comment: Yes, and there are certainly other compilers and tools. However, it's going to be a short list, so if Py3.5 takes the lead, they can all just agree on the one way to do it and let the first patcher win. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24018 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24020] threading.local() must be run at module level (doc improvement)
Paul Moore added the comment: You're right, the SO answer is simply wrong. I've posted a (hopefully clearer) answer. If anyone wants to check it for accuracy, that'd be great. Agreed this can probably be closed as not a bug. On first reading, I thought the docs could do with clarification, but now I think that was just because I had been confused by the SO posting :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24020 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23008] pydoc enum.{,Int}Enum fails
Ethan Furman added the comment: Patch looks good, get it in! :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23008 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22619] Possible implementation of negative limit for traceback functions
Serhiy Storchaka added the comment: As francismb noted, there are too long lines in the patch. They should be wrapped. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22619 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15582] Enhance inspect.getdoc to follow inheritance chains
Ethan Furman added the comment: I know it will take some time to add doc strings to places where they are missing, but I would not roll-back the patch for that. File new issues and get the over-riding methods properly documented. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15582 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23966] More clearly expose/explain native and cross-build target information
Toshio Kuratomi added the comment: Note for doko/barry: The multiarch/Tuples page should have a section on how the MultiArch Tuples interact with hwcaps (or a link to such a section in a different document). The rationale for not using Gnu-Triplets in MulitArch/Tuples currently says that we do not want separate entries for (as an example) i386 vs i686 instructions but does not tell why. https://wiki.debian.org/Multiarch/TheCaseForMultiarch#Mixed_ABIs_and_instruction_set_extensions says that the i386 vs i686 use case is probably better addressed by glibc's hwcaps but points back to MultiArch/Tuples for rationale. A section of rationale and example to show how the multiarch tuple and hwcaps complement each other would fix that. -- nosy: +a.badger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23966 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24019] str/unicode encoding kwarg causes exceptions
Eric V. Smith added the comment: As this is an enhancement request, I've changed the versions. I'm opposed to this change. If I pass an encoding along with a type for which it makes no sense, I'd prefer an error instead of silently ignoring the encoding. I think your helper function is an appropriate solution to your problem. -- components: +Interpreter Core -Unicode nosy: +eric.smith type: behavior - enhancement versions: -Python 2.7, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24019 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS)
Harrison Grundy added the comment: The attached patch just explicitly cuts precision down for the test. It may be worth adding code to set delta to the expected level of precision for a given platform, rather than just universally saying Microseconds are okay. -- nosy: +harrison.grundy Added file: http://bugs.python.org/file39159/almostequaltime.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15745 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16840] Tkinter doesn't support large integers
Serhiy Storchaka added the comment: This didn't help. Actually we should turn on bignum support only since 8.5.8, because tclTomMath.h was broken before. But this is not related, because tclTomMath.h is not found itself on this buildbot. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16840 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16840] Tkinter doesn't support large integers
Changes by Serhiy Storchaka storch...@gmail.com: -- resolution: fixed - stage: resolved - patch review versions: +Python 2.7, Python 3.4 Added file: http://bugs.python.org/file39158/tkinter_hexversion.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16840 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS)
Changes by koobs koobs.free...@gmail.com: -- components: +Tests keywords: +needs review stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15745 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16287] Sporadic test_utime() failures on Solaris
Changes by koobs koobs.free...@gmail.com: -- nosy: +koobs ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16287 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23630] support multiple hosts in create_server/start_server
Yann Sionneau added the comment: ping ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23630 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16840] Tkinter doesn't support large integers
Serhiy Storchaka added the comment: Ah, we should also test full version of 8.6, because bignums was not supported in earlier alphas and betas (if I remember correctly, this buildbot uses beta version of 8.6). TK_VERSION_HEX packs fields in wrong order, not suitable for comparing of non-final releases. It's value for 8.6a3 is larger than 8.6.1. Here is a patch that adds TK_HEX_VERSION with correctly packed fields and turn off bignum support in non-final 8.6. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16840 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12006] strptime should implement %G, %V and %u directives
Erik Cederstrand added the comment:
I think POLA would be to raise ValueError on time.strptime('2015', '%G') and
other situations that don't make sense or are ambiguous.
That, or reproduce the bugs that the native OS strptime() implementation has. I
got the %G, %V, and %u directives accepted for the next POSIX spec
(http://austingroupbugs.net/view.php?id=879). But it will be years before
operating systems catch up, so I would opt for the ValueError approach instead.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12006
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24018] add a Generator ABC
Guido van Rossum added the comment: Is it an option to leave inspect alone? Its definition and use of generators is very focused on the builtin implementation. Although this means that code that wants to do the right thing but also be backwards compatible has to use something like ``` def isgen(g): if hasattr(collections.abc, 'Generator'): return isinstance(c, collections.abc.Generator) else: return inspect.isgenerator(g) ``` -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24018 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24020] threading.local() must be run at module level (doc improvement)
New submission from Ethan Furman: In order to work correctly, threading.local() must be run in global scope, yet that tidbit is missing from both the docs and the _threading_local.py file. Something like: .. note:: threading.local() must be run at global scope to function properly. That would have saved me hours of time. Thank goodness for SO! ;) -- assignee: docs@python messages: 241713 nosy: docs@python, ethan.furman priority: normal severity: normal status: open title: threading.local() must be run at module level (doc improvement) versions: Python 2.7, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24020 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24020] threading.local() must be run at module level (doc improvement)
Raymond Hettinger added the comment: Also, don't use a .. note::, regular sentences work fine, especially in documentation that is already very short. -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24020 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24020] threading.local() must be run at module level (doc improvement)
eryksun added the comment:
Could you clarify what the problem is? I have no apparent problem using
threading.local in a function scope:
import threading
def f():
tlocal = threading.local()
tlocal.x = 0
def g():
tlocal.x = 1
print('tlocal.x in g:', tlocal.x)
t = threading.Thread(target=g)
t.start()
t.join()
print('tlocal.x in f:', tlocal.x)
f()
tlocal.x in g: 1
tlocal.x in f: 0
--
nosy: +eryksun
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24020
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24020] threading.local() must be run at module level (doc improvement)
Ethan Furman added the comment: Raymond, okay, thanks. Eryksun, I've written a FUSE file system (for $DAYJOB) and when I switched over to using threads I would occasionally experience errors such as 'thread.local object does not have attribute ...'; as soon as I found the SO answer and moved the call to 'threading.local()' to the global scope, the problem vanished. To reliably detect the problem I started approximately 10 threads, each getting an os.listdir() 1,000 times of an area on the FUSE. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24020 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24022] Python heap corruption issue
Roundup Robot added the comment: New changeset 414e08c478f4 by Benjamin Peterson in branch '3.4': do not call into python api if an exception is set (#24022) https://hg.python.org/cpython/rev/414e08c478f4 New changeset 03b2259c6cd3 by Benjamin Peterson in branch 'default': merge 3.4 (#24022) https://hg.python.org/cpython/rev/03b2259c6cd3 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24022 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24018] add a Generator ABC
Guido van Rossum added the comment: Realistically only Cython will care much about this, so I'm okay if Cython just monkeypatches the collections package. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24018 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24018] add a Generator ABC
Stefan Behnel added the comment: Yes, code usually doesn't fall from the sky with a new CPython release. If something wants to make use of this ABC, it still has to find ways to also work with older CPythons. What would be a good fallback? A backport on PyPI? I wouldn't even mind shipping this class with Cython and dropping it right into collections.abc if it's missing. Cython already contains lots of compatibility code, and we need to patch *something* in all current CPythons either way. Then your code snippet would be the right thing to do for user code (with the twist that Py2.x doesn't have collections.abc...). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24018 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24020] threading.local() must be run at module level (doc improvement)
Paul Moore added the comment: Link to the SO answer? Does it explain *why* this is a requirement? -- nosy: +paul.moore ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24020 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24022] Python heap corruption issue
Changes by Benjamin Peterson benja...@python.org: Added file: http://bugs.python.org/file39160/f69354561u44075.zip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24022 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24022] Python heap corruption issue
Serhiy Storchaka added the comment: Where are test scripts? -- nosy: +serhiy.storchaka versions: -Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24022 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24021] document urllib.urlretrieve
Changes by Karl Richter krichter...@aol.de: -- assignee: docs@python components: Documentation nosy: docs@python, krichter priority: normal severity: normal status: open title: document urllib.urlretrieve versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24021 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24022] Python heap corruption issue
New submission from Benjamin Peterson: Reported by Hug Bounter to security@ Hello, I would like to report a heap corruption issue in Python/Parser/tokenizer.c:922, affecting latest Python 3.4.3 (from python.org) and also 2.7 ( tested 2.7.9-r1 on Gentoo ). The latest version available - 3.5.0a3 is also affected. It doesn't seem to affect 3.3 branch (tested with 3.3.5-r1 on Gentoo). The issue occurs when a malformed python script is executed by python binary, which results in a out-of-bound read access of heap and therefore a segmentation fault. I couldn't confirm nor deny its exploitability, to my knowledge this would be more of a infoleak, if anything. Nevertheless, as Google Project Zero proved many times, no heap corruption issue should be treated lightheartedly. :-) Hence the reason why I'm reporting it to secur...@python.org I tried to dig into the details of the bug and I have to admit the defeat - the Python Parser is quite a complex beast... What I was able to determine was that given malformed script (attached), the infinite 'for' loop defined in tokenizer.c:900 never reaches any of the exit conditions, which causes a infinite incrementation of *tok-cur and thus reading character by character of the heap, until the heap segment boundary is reached and segmentation fault occurrs. There seem to be a race condition involved as well, as the malformed script does not always result in crash sometimes producing the error below: ./python ~/Fuzz/crashes/python_stuff/heap_pattern.py File /home/user/Fuzz/crashes/python_stuff/heap_pattern.py, line 44 SyntaxError: Non-UTF-8 code starting with '\x9e' in file /home/user/Fuzz/crashes/python_stuff/heap_pattern.py on line 45, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details I acknowledge that attack scenario is somehow limited, because one has to be in a position to provide their own script for execution. Nevertheless, at the very least, a malicious user could crash python environment. Depending on the particular script, ASAN detects either as a 'heap-use-after-free' or 'heap-buffer-overflow'. HEAP-BUFFER-OVERFLOW according to asan: $ ./python ~/heap3.py = ==23461==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6251e0ff at pc 0xc90075 bp 0x7ffe53018fd0 sp 0x7ffe53018fc0 READ of size 1 at 0x6251e0ff thread T0 #0 0xc90074 in tok_nextc Parser/tokenizer.c:1021 #1 0xc9a6ef in tok_get Parser/tokenizer.c:1341 #2 0xca0640 in PyTokenizer_Get Parser/tokenizer.c:1738 #3 0xc81109 in parsetok Parser/parsetok.c:208 #4 0xa0c449 in PyParser_ASTFromFileObject Python/pythonrun.c:2356 #5 0xa0c449 in PyRun_FileExFlags Python/pythonrun.c:2126 #6 0xa15f0b in PyRun_SimpleFileExFlags Python/pythonrun.c:1606 #7 0x43a1aa in run_file Modules/main.c:319 #8 0x43a1aa in Py_Main Modules/main.c:751 #9 0x4234d3 in main Modules/python.c:69 #10 0x7efcd1cf1f9f in __libc_start_main (/lib64/libc.so.6+0x1ff9f) #11 0x426a7c (/home/user/Fuzz/targets/Python-3.4.3_ASAN/python+0x426a7c) 0x6251e0ff is located 1 bytes to the left of 8192-byte region [0x6251e100,0x62520100) allocated by thread T0 here: #0 0x7efcd29eb7c7 in malloc (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/libasan.so.1+0x577c7) #1 0xc9997a in PyTokenizer_FromFile Parser/tokenizer.c:852 SUMMARY: AddressSanitizer: heap-buffer-overflow Parser/tokenizer.c:1021 tok_nextc Shadow bytes around the buggy address: 0x0c4a7fffbbc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c4a7fffbbd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c4a7fffbbe0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c4a7fffbbf0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c4a7fffbc00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =0x0c4a7fffbc10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa[fa] 0x0c4a7fffbc20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c4a7fffbc30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c4a7fffbc40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c4a7fffbc50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c4a7fffbc60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Contiguous container OOB:fc ASan internal: fe ==23461==ABORTING Below is an example of ASAN detecting a 'use-after-free': ./python ~/heap4_asan.py
[issue22619] Possible implementation of negative limit for traceback functions
Dmitry Kazakov added the comment: Thanks, completely missed the abs(limit) part. Here's the updated documentation patch. -- Added file: http://bugs.python.org/file39161/traceback_limit_doc_rev.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22619 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22619] Possible implementation of negative limit for traceback functions
Changes by Dmitry Kazakov jsb...@gmail.com: Added file: http://bugs.python.org/file39162/traceback_limit_doc_rev2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22619 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10435] Document unicode C-API in reST
Alexander Belopolsky added the comment: Sorry for the broken link, the correct header file is Include/unicodeobject.h -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10435 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24020] threading.local() must be run at module level (doc improvement)
Eric Snow added the comment: @Ethan, it may help you to read through the module docstring in Lib/_threading_local.py. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24020 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23994] argparse fails to detect program name when there is a slash at the end of the program's path
paul j3 added the comment: This overlaps with http://bugs.python.org/issue22240 argparse support for python -m module in help This issue also tries to handle zip files as well. Deducing the `prog` was moved to a separate function. One challenge with that issue was constructing a test framework. Here the testing might simpler since the `foo/` directory doesn't have to exist (or at least we can fake it with a custom `sys.argv`). -- nosy: +paul.j3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23994 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24020] threading.local() must be run at module level (doc improvement)
Ethan Furman added the comment: Here's a basic outline of what I was trying: --- CONTEXT = None class MyFUSE(Fuse): def __call__(self, op, path, *args): global CONTEXT ... CONTEXT = threading.local() # set several CONTEXT vars ... # dispatch to correct function to handle 'op' Under stress, I would eventually get threading.local objects that were missing attributes. Points to consider: - I have no control over the threads; they just arrive wanting their 'op's fulfilled - the same thread can be a repeat customer, but with the above scenario they would/should get a new threading.local each time Hmmm... could my problem be that even though function locals are thread-safe, the globals are not, so trying to create a threading.local via a global statement was clobbering other threading.local instances? While that would make sense, I'm still completely clueless why having a single global statement, which (apparently) creates a single threading.local object, could be distinct for all the threads... unless, of course, it can detect which thread is accessing it and react appropriately. Okay, that's really cool. So I was doing two things wrong: - calling threading.local() inside a function (although this would probably work if I then passed that object around, as I do not need to persist state across function calls -- wait, that would be the same as using an ordinary, function-local dict, wouldn't it?) - attempting to assign the threading.local object to a global variable from inside a function (this won't work, period) Many thanks for helping me figure that out. Paul, in your SO answer you state: - Just like an ordinary object, you can create multiple threading.local instances in your code. They can be local variables, class or instance members, or global variables. - Local variables are already thread-safe, aren't they? So there would be no point in using threading.local() there. - Instance members (set from __init__ of someother method): wouldn't that be the same problem I was having trying to update a non-threadsafe global with a new threading.local() each time? It seems to me the take-away here is that you only want to create a threading.local() object /once/ -- if you are creating the same threading.local() object more than once, you're doing it wrong. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24020 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24020] threading.local() must be run at module level (doc improvement)
Paul Moore added the comment: On 21 April 2015 at 23:11, Ethan Furman rep...@bugs.python.org wrote: Hmmm... could my problem be that even though function locals are thread-safe, the globals are not, so trying to create a threading.local via a global statement was clobbering other threading.local instances? While that would make sense, I'm still completely clueless why having a single global statement, which (apparently) creates a single threading.local object, could be distinct for all the threads... unless, of course, it can detect which thread is accessing it and react appropriately. Okay, that's really cool. You're not creating a single threading object. You're creating one each call() and overwriting the old one. So I was doing two things wrong: - calling threading.local() inside a function (although this would probably work if I then passed that object around, as I do not need to persist state across function calls -- wait, that would be the same as using an ordinary, function-local dict, wouldn't it?) Yes, a dict should be fine if you're only using it within the one function call. - attempting to assign the threading.local object to a global variable from inside a function (this won't work, period) It does work, it's just there isn't *the* object, there's lots and you keep overwriting. The thread safety issue is that if you write over the global in one thread, before another thread has finished, you lose the second thread's values (because they were on the old, lost, namespace. So basically you'd see unpredictable, occasional losses of all your CONTEXT vars in a thread. Many thanks for helping me figure that out. (If you did :-) - hope the clarifications above helped). Paul, in your SO answer you state: - Just like an ordinary object, you can create multiple threading.local instances in your code. They can be local variables, class or instance members, or global variables. - Local variables are already thread-safe, aren't they? So there would be no point in using threading.local() there. Not unless you're going to return them from your function, or something like that. But yes, it's unlikely they will be needed there. I only mentioned it to avoid giving any impression that only set at global scope was important. - Instance members (set from __init__ of someother method): wouldn't that be the same problem I was having trying to update a non-threadsafe global with a new threading.local() each time? You'd set vars on the namespace held in the instance variable. It's much like the local variable case, except you are more likely to pass an instance around between threads. It seems to me the take-away here is that you only want to create a threading.local() object /once/ -- if you are creating the same threading.local() object more than once, you're doing it wrong. Well, sort of. You can only create *any* object once :-) There seems to be a confusion (in the SO thread and with you, maybe) that threading.local objects are somehow singletons in that you create them repeatedly and get the same object. That's just wrong - they are entirely normal objects, that you can set arbitrary attributes on. The only difference is that each thread sees an independent set of attributes on the object. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24020 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20035] Clean up Tcl library discovery in Tkinter on Windows
Mark Lawrence added the comment: ping. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20035 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24020] threading.local() must be run at module level (doc improvement)
Changes by Eric Snow ericsnowcurren...@gmail.com: -- resolution: - not a bug stage: - resolved status: open - closed type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24020 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21483] Skip os.utime() test on NFS?
Skip Montanaro added the comment: On Tue, Apr 21, 2015 at 2:56 PM, Larry Hastings rep...@bugs.python.org wrote: Issac doesn't have commit bit... ... but you do. Alas, my commit bit long ago fell into disuse. I haven't checked anything in since long before the days of Mercurial and the current workflow. I would almost certainly mess something up. In fact, to avoid confusion in the future, removal of my commit bit might not be a bad idea. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21483 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10435] Document unicode C-API in reST
Mark Lawrence added the comment: Okay Alexander I'll give it a go, but not tonight :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10435 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23863] Fix EINTR Socket Module issues in 2.7
Jeff McNeil added the comment: Fixing the underlying connect call should also address EINTR failing with a operation already in progress when a connect+timeout fails due to a signal. I can understand not addressing EINTR generically (though it is already partially addressed in 2.7's socket.py - this just completes it), but IMO, not handling it on connect responding with a seemingly unrelated error is the wrong thing to do. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23863 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10435] Document unicode C-API in reST
Mark Lawrence added the comment: I've looked at c-api/unicode.rst and I can't see any correlation between it and the names listed here in msg121302. So either this was never completed or it's been all change in the mean time, so could somebody take a look please. -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10435 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21483] Skip os.utime() test on NFS?
Larry Hastings added the comment: Issac doesn't have commit bit... ... but you do. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21483 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22619] Possible implementation of negative limit for traceback functions
Changes by Dmitry Kazakov jsb...@gmail.com: Removed file: http://bugs.python.org/file39161/traceback_limit_doc_rev.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22619 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10435] Document unicode C-API in reST
Alexander Belopolsky added the comment: Mark, Unicode C-APIs have changed a lot since this issue was opened, but I think many of the listed functions are still present but not properly documented. You can help by checking the Include/unicode.h file and compiling a list of functions that are there, don't start with _ and not documented in the reference manual. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10435 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21327] socket.type value changes after using settimeout()
Raúl Cumplido added the comment: ping, any comment on the patch that was provided during the PyCon 2015 sprints? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21327 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24019] str/unicode encoding kwarg causes exceptions
Martin Panter added the comment: I don’t think changes to Python 2 are considered here, unless they are bug fixes, and this does not sound like a bug fix. For Python 3, it sounds like you are proposing that str() accept encoding arguments even when not decoding from bytes. It sounds like this would mask the error if you called str(buffer, ascii), and the buffer happened to be an integer or a list, etc, by accident. Also, this woul It seems str() is designed to have two separate modes: 1. str(object) is basically equivalent to format(object), with a warning if “object” happens to be a byte string or array 2. str(object, encoding, ...) is normally equivalent to object.decode(encoding, ...), or if that is not supported, codecs.decode(object, encoding, ...) Your proposal sounds like it would make it easier to confuse these two modes. What should str(b123, encoding=None) do? Why should the behaviour of str(file, encoding) vary depending on whether an ordinary file object or a memory-mapped file is passed? IMO in a perfect Python 4 world, str() would only have a single personality (perhaps always returning an empty string, or a more strict conversion). Making a formatted string representations of arbitrary objects would be left to the format() and repr() functions, and decoding bytes to text would be left to the existing decode() methods and functions, or maybe a separate str.from_bytes() constructor, mirroring int.from_bytes(). -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24019 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24019] str/unicode encoding kwarg causes exceptions
Mahmoud Hashemi added the comment: Martin, it sounds that way because that is what is being proposed: Merging and simplifying the two modes. Given the existence of .decode() on bytestrings, the only objects that generally need decoding in Python 2 and 3, the existence of str/unicode's second mode constitutes a design bug. Without a doubt, Python has frequently preferred convenient idioms over EAFP. Look at dict.get for an excellent example of defaults being used instead of forcing users to catch KeyErrors. That conversation could have gone a different way, but Python is better off having stuck to its pragmatic roots. In answer to your questions, Martin, 1) I'd expect str(b123, encoding=None) to do the same thing as str(b123) and 2) I'd expect str(obj) behavior to continue to depend on whether the object passed is string-like. Python is a duck-typed, dynamic language, and dynamic languages are most powerful when their core types reflect usability. Consistency is one of the foremost factors of usability, and having to frequently switch between two call patterns of the str constructor feels inconsistent and unusable. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24019 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17475] Better doc on using python-gdb.py
Changes by Carol Willing willi...@willingconsulting.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17475 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24021] document urllib.urlretrieve
New submission from Berker Peksag: urllib.urlretrieve is already documented at https://docs.python.org/2.7/library/urllib.html#urllib.urlretrieve Can you please give us more information about your problem with the urllib.urlretrieve documentation? -- nosy: +berker.peksag ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24021 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23863] Fix EINTR Socket Module issues in 2.7
Gregory P. Smith added the comment: ... Code review: In socket_eintr.5.patch I don't think the thread safety concerns about the s.settimeout() calls being done from Python code should be an issue but I'll ponder that for a bit. When you've got a socket s, why would code ever be calling s.recv() in one thread while calling another method on the same socket s in another thread? That seems unwise. (For UDP it might be a valid thing to do but it still has an odd smell to it) If you're worried about timer resolution, just check that the new timeout value deadline - now is less than the previous timeout value and if not, ensure the value decreases by some small amount. So long as it continually goes down, it will eventually timeout. Even if the duration isn't accurate in the face of a bunch of EINTRs, this is a degenerate case; it should still be reasonable behavior. On POSIX systems using os.times()[4] rather than an absolute time.time(), which can be changed out from underneath the process (even though that is rare on functioning systems), could be useful. But conditionally using that seems overly complex. I wouldn't bother. ... Side discussion Some things in 2.7 related to EINTR have already been fixed in the past few years such as data loss in readline() and IIRC writelines(). Correctness isn't a feature. Do you consider it an API change to prevent an error that nobody relies on or even expects (as PEP 475 notes) and virtually no code is written to properly handle when it _does_ happen? I don't. It is a bug fix. It's mostly a matter of if we can do it sanely and in a maintainable manner. Please don't WONTFIX this issue, I intend to get safe fixes in. ... Motivation The underlying motivation here is to enable the use of a signal based sampling profiler on a program that is using Python 2.7 (entirely, or embedded as one part of a larger C/C++ application). Signals (SIGPROF) used in that scenario cause EINTR returns from syscalls that otherwise rarely (read: never) have them in most environments. Result: Bugs show up making such a sampling profiler impossible to deploy in practice until those issues are fixed. Fixing the Python standard library is high value as it is a higher up place where these can be handled properly as you cannot even use some standard library modules at all otherwise because the unhandled EINTR surfaces too late or causes other unrecoverable errors internally before you see it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23863 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24019] str/unicode encoding kwarg causes exceptions
R. David Murray added the comment: It does feel like the encoding argument is left over from the translation of the unicode constructor into the str constructor. I wouldn't be opposed to deprecating it, myself, though we'd probably never remove it. I would be opposed to making it work on non-bytes-like objects. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24019 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24019] str/unicode encoding kwarg causes exceptions
Martin Panter added the comment: Okay, I was trying to confirm your proposal in Python 3 terms, because in Python 2, str has a different meaning and I was confused. I agree that the existence of the decoding mode is a design bug, so how would you feel about deprecating it, at least in the documentation? I.e. in Python 3, deprecate usage like str(buffer, utf-8) in favour of buffer.decode(utf-8) or using the codecs module directly. If this was done, it would clearly remove the need for an encoding parameter to str() in all cases. I would be in favour of deprecating the complementary bytes() and bytearray() encoding modes as well. Do you have an example use case in Python 3 that would benefit from always allowing an encoding parameter? I can understand that your to_unicode() function could be useful in Python 2. But in Python 3, byte strings tend to hold raw data that is not necessarily textual at all. There are some places (warts in my opinion) such as the binascii module where ASCII-encoded byte strings are common, but I still don’t think this proposal would be very helpful with that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24019 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16574] clarify policy on updates to final peps
Changes by Carol Willing willi...@willingconsulting.com: -- stage: patch review - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16574 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24019] str/unicode encoding kwarg causes exceptions
Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: +berker.peksag ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24019 ___ ___ 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
Carol Willing added the comment: Thank you kathweaver and others who worked on this issue. After reviewing the long history of this issue and the changes made to the Windows sections of the devguide, I am closing this issue. I recognize that Terry Reedy's final comment about isolated build directories may need additional documentation. My recommendation would be to file a new issue if more documentation is needed on isolated build directories for Windows and tcl. -- nosy: +willingc resolution: - fixed stage: patch review - resolved status: open - closed ___ 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
[issue5305] imaplib should support international mailbox names
Changes by Jean-Paul Calderone jean-p...@clusterhq.com: -- nosy: -exarkun ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5305 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24019] str/unicode encoding kwarg causes exceptions
Eric V. Smith added the comment: I agree with deprecating (in the documentation) but never removing the encoding argument to str() in Python 3. .decode() is the better way to convert a bytes-like object to a str. Every change proposed here would be an enhancement in 2.7, and we are not implementing enhancements there. -- versions: +Python 3.6 -Python 2.7, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24019 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24021] document urllib.urlretrieve
Martin Panter added the comment: I suspect the complaint might be about the lack of doc string, but a more specific bug report would be nice to clarify this. $ pydoc2 urllib.urlretrieve Help on function urlretrieve in urllib: urllib.urlretrieve = urlretrieve(url, filename=None, reporthook=None, data=None, context=None) $ -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24021 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22137] Test imaplib API on all methods specified in RFC 3501
Milan Oberkirch added the comment: Thanks a lot for reviewing my patch! I'm currently travalling so I'm totally fine with you taking over this issue (would take me a few weeks till I can work on it). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22137 ___ ___ 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: My comment was addressed by other patches (by Zach, I believe). There now is an external directory for each version, within each pythonxy repository. I agree with closing this. Any documentation issues with the current build process should be a new issue. -- ___ 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
[issue16574] clarify policy on updates to final peps
Berker Peksag added the comment: Thanks! -- nosy: +berker.peksag resolution: - fixed stage: commit review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16574 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows
Larry Hastings added the comment: Is this problem gone, now that Serhiy changed everything over to the file preset? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20323 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13814] Document why generators don't support the context management protocol
Changes by Martin Panter vadmium...@gmail.com: -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13814 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20851] Update devguide to cover testing from a tarball
Carol Willing added the comment: Brett, Is documentation for a testing a tarball dumped for an RC still needed? If so, are the following steps accurate? 1. Download tarball 2. Extract tarball into a directory tar -xzvf release.tar.gz 3. Change directory into release directory cd release 4. Install the release sudo python setup.py install My assumption: After installation above, testing should be similar to the existing devguide instructions for testing. Thoughts? -- nosy: +willingc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20851 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23227] Generator's finally block not run if close() called before first iteration
Changes by Martin Panter vadmium...@gmail.com: -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23227 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16574] clarify policy on updates to final peps
Roundup Robot added the comment: New changeset 0c4006b7c7ff by Berker Peksag in branch 'default': Issue #16574: Clarify that once a PEP has implemented, it needs be https://hg.python.org/devguide/rev/0c4006b7c7ff -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16574 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15183] it should be made clear that the statement in the --setup option and the setup kw arg aren't included in the count
Roundup Robot added the comment: New changeset e0e3d2ec56b6 by Andrew Kuchling in branch '3.4': #15183: clarify timeit documentation to say that setup statement isn't timed https://hg.python.org/cpython/rev/e0e3d2ec56b6 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15183 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15183] it should be made clear that the statement in the --setup option and the setup kw arg aren't included in the count
A.M. Kuchling added the comment: Committed to 3.4 and default. Thanks for your patch! -- nosy: +akuchling resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15183 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22785] range docstring is less useful than in python 2
Ned Batchelder added the comment: (By the time I got to the source, the word virtual had been removed...) Attached is a patch to make the help read: | range(stop) - range object | range(start, stop[, step]) - range object | | Return an object that produces a sequence of integers from start (inclusive) | to stop (exclusive) by step. range(i, j) produces i, i+1, i+2, ..., j-1. | start defaults to 0, and stop is omitted! range(4) produces 0, 1, 2, 3. | These are exactly the valid indices for a list of 4 elements. | When step is given, it specifies the increment (or decrement). -- keywords: +patch Added file: http://bugs.python.org/file39163/22785.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22785 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15582] Enhance inspect.getdoc to follow inheritance chains
Martin Panter added the comment: My example was taken from a package that tends to “properly document” everything in separate documentation files, rather than in the source code. I don’t really think Python should dictate if and how one document their code based on what base classes they use, and pydoc is still useful with code that has no doc strings. But if this is to be the way of the future, perhaps a warning in the “What’s New” page might be a good idea. The inspect.getdoc() documentation should probably also have a “Changed in version 3.5” warning. I guess it would be less automatic, but maybe another option might have been to add an @inherit_docstring decorator, or some explicit way to say a particular API (re)implements an (abstract) API documented elsewhere. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15582 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2716] Document license under which audioop is used
A.M. Kuchling added the comment: Van: what do you think? I can prepare a patch for Aaron's suggested changes. -- nosy: +akuchling, vanl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2716 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24020] threading.local() must be run at module level (doc improvement)
Eric Snow added the comment: Think of threading.local this way: instances of threading.local are shared between all the threads, but the effective __dict__ of each instance is per-thread. Basically, the object stores a dict for each thread. In __getattribute__, __setattr__, and __delattr__ it swaps the dict for the current thread into place and then does proceeds normally. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24020 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23979] Multiprocessing Pool.map pickles arguments passed to workers
Luis added the comment: Thanks for information and explanations. The option of writing a tweaked serialization mechanism in Queue for Pool and implement a sharedmem sounds like fun, not sure if the pure-copy-on-write of forking can be achieved tho, it would be nice to know if it is actually possible (the project mentioned in issue17560 still needs to dump the arrays in the filesystem) As quick fix for us, I've created a simple wrapper around Pool and its map, it creates a Queue for the results and uses Process to start the workers, this works just fine. Simplicity and consistency are great, but I still believe that Pool, in LINUX-based systems, by serializing arguments, creates duplication and works inefficiently, and this could be avoided. Obviously it's not me who takes the decisions and I don't have the time to investigate it further, so, after this petty rant, should we close this bug? : -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23979 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24018] add a Generator ABC
Antoine Pitrou added the comment: In some distant future, Numba might also care too :) (right now, we only support compiling basic generators, i.e. no send() and no throw()) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24018 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6731] Add option of non-zero exit status of setup.py when building of extensions has failed
Mark Lawrence added the comment: I'm assuming that this will not be implemented until 3.6. -- nosy: +BreamoreBoy versions: +Python 3.6 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6731 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24020] threading.local() must be run at module level (doc improvement)
Ethan Furman added the comment: http://stackoverflow.com/q/1408171/208880 No, it just says (towards the top): -- One important thing that everybody seems to neglect to mention is that writing threadLocal = threading.local() at the global level is required. Calling threading.local() within the worker function will not work. It is now my experience that will not work (reliably) is accurate. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24020 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
