[issue5784] raw deflate format and zlib module
A.M. Kuchling added the comment: Here's a short patch that expands the discussion of wbits, and duplicates it under both the compressobj() and decompress() methods. Should I avoid the duplication and just have a reference? -- nosy: +akuchling Added file: http://bugs.python.org/file39102/patch-5784.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5784 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
levkivskyi added the comment: I would like to add that since the introduction of asyncio module that heavily uses yield from syntax, binding of yield inside comprehensions/generator expressions could lead to unexpected results/confusing behavior. See for example this question on SO: http://stackoverflow.com/questions/29334054/why-am-i-getting-different-results-when-using-a-list-comprehension-with-coroutin -- nosy: +levkivskyi ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10544 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5784] raw deflate format and zlib module
Martin Panter added the comment: Looks good in general (apart from one grammar comment). It might be best to only include one copy, and reference the others. There are actually three places “wbits” is allowed that I can see: * compressobj() * decompress() * decompressobj() Maybe just pointing from decompress() and decompressobj() back to the compressobj() description would be good enough. Unless if you know if wbits=0 is also accepted or not for decompression. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5784 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23993] Use surrogateescape error handler by default in open() if the locale is C
STINNER Victor added the comment: I am -1 on this. (Or may be more). What's the rationale? See the issue #19977. In many cases you get the C locale by mistake. For example, by setting the LANG environment variable to an empty string to run a program in english (whereas LC_MESSAGES is the appropriate variable). For deamons, in many cases you get the C locale and it's hard to configure all systems to run the daemon with the user locale. I read that systemd runs daemons with the user locale, but I'm not sure. The idea is to reduce the pain caused by this locale. When porting an application from Python 2 to Python 3, it's annoying to start to get unicode errors everywhere. This issue starts to make Python 3 more convinient. I could see using utf-8 by default if the locale is C, This has been proposed many times, but I'm opposed to that. Python must be interoperable with other programs, and other programs use the locale encoding. For example, you get the ASCII locale encoding when the LC_CTYPE is the POSIX locale (C). If Python writes UTF-8, other applications will be unable to decode UTF-8 data. Maybe I'm wrong and you should continue to investigate this option. This issue is very specific to OS data: environment variables, filenames, command line arguments, standard streams (stdin, stdout, stderr). You may do other choices for other kind of data unrelated to the locale encoding. For example, JSON must use UTF-8, it's well defined. XML announces its encoding. etc. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23993 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: This is exactly analogous to what you are seeing with __call__ and callable(). Your example is incorrect, __next__ is what makes an object iterable but not what makes an object have an iterator (what __iter__ does). This correctly characterises the issue: class NonIter: ... pass ... iter(NonIter()) Traceback (most recent call last): File stdin, line 1, in module TypeError: 'NonIter' object is not iterable class DynamicNonIter: ... has_iter = False ... ... @property ... def __iter__(self): ... if self.has_iter: ... from functools import partial ... return partial(iter, [1, 2, 3]) ... else: ... raise AttributeError(Not really ...) ... dni = DynamicNonIter() iter(dni) Traceback (most recent call last): File stdin, line 1, in module TypeError: 'DynamicNonIter' object is not iterable dni.has_iter = True iter(dni) list_iterator object at 0x0362FF60 Now, if this is possible for `iter`, why shouldn't it be possible for `callable`? I'm not opposed to writing a PEP but the issue with `callable` is the only one I'm aware of, and this seems too small in scope anyway. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ 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
Carol Willing added the comment: The current devguide on gdb (https://docs.python.org/devguide/gdb.html?highlight=gdb) satisfies this issue. I am marking this languishing issue as a duplicate and closing it. -- nosy: +willingc resolution: - duplicate stage: patch review - resolved ___ 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
[issue20962] Rather modest chunk size in gzip.GzipFile
Martin Panter added the comment: The gzip (as well as LZMA and bzip) modules should now use buffer and chunk sizes of 8 KiB (= io.DEFAULT_BUFFER_SIZE) for most read() and seek() type operations. I have a patch that adds a buffer_size parameter to the three compression modules if anyone is interested. It may need a bit work, e.g. adding the parameter to open(), mimicking the built-in open() function when buffer_size=0, etc. I did a quick test of seeking 100 MB into a gzip file, using the original Python 3.4.3 module, the current code that uses 8 KiB chunk sizes, and then my patched code with various chunk sizes. It looks like 8 KiB is significantly better than the previous code. My tests are peaking at about 64 KiB, but I guess that depends on the computer (cache etc). Anyway, 8 KiB seems like a good compromise without hogging all the fast memory cache or whatever, so I suggest we close this bug. Command line for timing looked like: python -m timeit -s 'import gzip' \ 'gzip.GzipFile(100M.gz, buffer_size=8192).seek(int(100e6))' Python 3.4.3: 10 loops, best of 3: 2.36 sec per loop Currently (8 KiB chunking): 10 loops, best of 3: 693 msec per loop buffer_size=1024: 10 loops, best of 3: 2.46 sec per loop buffer_size=8192: 10 loops, best of 3: 677 msec per loop buffer_size=16 * 1024: 10 loops, best of 3: 502 msec per loop buffer_size=int(60e3): 10 loops, best of 3: 400 msec per loop buffer_size=64 * 1024: 10 loops, best of 3: 398 msec per loop buffer_size=int(80e3): 10 loops, best of 3: 406 msec per loop buffer_size=16 * 8192: 10 loops, best of 3: 469 msec per loop -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20962 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23993] Use surrogateescape error handler by default in open() if the locale is C
R. David Murray added the comment: I am -1 on this. (Or may be more). What's the rationale? I could see using utf-8 by default if the locale is C, but I don't think we want to encourage going back to a world where people don't pay attention to the encoding of their data. A more productive approach to solving the problem that I think you are trying to solve here would be to work on including chardet in the standard library, something that was brought up, and seemed to receive positive reception (or at least not negative), during the Requests segment of the PyCon language summit. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23993 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23725] update tempfile docs to say that TemporaryFile is secure
Changes by Zbyszek Jędrzejewski-Szmek zbys...@in.waw.pl: Added file: http://bugs.python.org/file39104/tempfile_docs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23536] Add explicit information on config file format not supporting filters
Roundup Robot added the comment: New changeset df28044b7e14 by Vinay Sajip in branch '2.7': Issue #23536: Clarified scope of fileConfig()'s API. https://hg.python.org/cpython/rev/df28044b7e14 New changeset 968c086bf6cc by Vinay Sajip in branch '3.4': Issue #23536: Clarified scope of fileConfig()'s API. https://hg.python.org/cpython/rev/968c086bf6cc New changeset 439517000aa2 by Vinay Sajip in branch 'default': Closes #23536: Clarified scope of fileConfig()'s API. https://hg.python.org/cpython/rev/439517000aa2 -- nosy: +python-dev resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23536 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5784] raw deflate format and zlib module
Changes by A.M. Kuchling a...@amk.ca: -- stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5784 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23993] Use surrogateescape error handler by default in open() if the LC_CTYPE locale is C at startup
Changes by STINNER Victor victor.stin...@gmail.com: -- title: Use surrogateescape error handler by default in open() if the locale is C - Use surrogateescape error handler by default in open() if the LC_CTYPE locale is C at startup ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23993 ___ ___ 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
Carol Willing added the comment: This patch should close this languishing devguide issue. This patch adds wording suggested by Terry Reedy re: pep documentation reference to section 7.4.5 Inline markup (https://docs.python.org/devguide/documenting.html#id3). The devguide covers the pep process and PEP 1 in section 20.1.2 (https://docs.python.org/devguide/langchanges.html?highlight=pep#pep-process). -- keywords: +patch nosy: +willingc stage: - patch review Added file: http://bugs.python.org/file39101/iss16574.patch ___ 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
[issue17703] Trashcan mechanism segfault during interpreter finalization in Python 2.7.4
Daniel added the comment:
Guillaume already mentioned this, its still causing a Fatal Error. To fix this
PyThreadState_GET() in Py_TRASHCAN_SAFE_BEGIN must be replaced with
_PyThreadState_Current
#define Py_TRASHCAN_SAFE_BEGIN(op) \
do { \
PyThreadState *_tstate = _PyThreadState_Current; \
--
nosy: +m_python
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17703
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23993] Use surrogateescape error handler by default in open() if the LC_CTYPE locale is C at startup
STINNER Victor added the comment: For a more concrete use case, see the makefile problem in Mercurial wiki page: http://mercurial.selenic.com/wiki/EncodingStrategy#The_.22makefile_problem.22 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23993 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23993] Use surrogateescape error handler by default in open() if the locale is C
STINNER Victor added the comment: Updated and better patch: version 2. - revert changes on fileutils.c: it's not useful to check for check_force_ascii(), because this function is more strict than checking of the LC_CTYPE is C - fix _pyio.py: add sys import - complete the documentation - tests pass -- Added file: http://bugs.python.org/file39103/default_error_handler-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23993 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23725] update tempfile docs to say that TemporaryFile is secure
Zbyszek Jędrzejewski-Szmek added the comment: Replying to review here... I get 500 server error in the patch review reply dialogue :( On 2015/04/15 02:40:14, r.david.murray wrote: http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst File Doc/library/tempfile.rst (left): http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#oldcode55 Doc/library/tempfile.rst:55: :keyword:`with` statement, just like a normal file. Why did you remove this statement? It is redundant. The fact that this can be used as CM is already mentioned in the introduction and in the description of TemporaryFile. http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst File Doc/library/tempfile.rst (right): http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode25 Doc/library/tempfile.rst:25: The need to use the insecure :func:`mktemp` function is eliminated. How about we get even more radical. Let's eliminate the mention of mktemp from the documentation, except for a Deprecated Functions section at the end, where we explain that it is deprecated because it is insecure and anything you could do with it you can do with the un-deprecated functions. Agreed. I'll submit a new version which removes all the historical notes and adds a Deprecated section at the end for tempdir and mktemp. http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode27 Doc/library/tempfile.rst:27: instead a string of six random characters is used. Let's likewise eliminate the mention of the process id, and just leave the explanation that six random characters are used. OK. http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode31 Doc/library/tempfile.rst:31: directories. It is no longer necessary to use the global *tempdir* variable. The global tempdir variable can likewise be moved to the deprecated section and removed from mention here. OK. http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode42 Doc/library/tempfile.rst:42: collected). Under Unix, the directory entry for the file is either not created at all or removed or is removed OK. http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode247 Doc/library/tempfile.rst:247: There should be another blank line here. v5: - relegate `tempdir` and `mktemp` descriptions to 'Deprecated functions and variables' section at the end. This requires moving some descriptions around. - add missing is pointed out in review - add missing 's' -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: On Sat, Apr 18, 2015 at 7:23 PM, Ethan Furman rep...@bugs.python.org wrote: class GenericProxy: def __init__(self, proxied): self.proxied = proxied # in case proxied is an __iter__ iterator @property def __iter__(self): if not hasattr(self.proxied, '__iter__'): raise AttributeError else: return self @property def __next__(self): if not hasattr(self.proxied, '__next__'): raise AttributeError else: return next(self.proxied) Unfortunately your implementation is incorrect as you forgot to that the property needs to return a function. This is a correct implementation that works as expected (in the sense that *iter does in fact honor the descriptor protocol)*: class GenericProxy: def __init__(self, proxied): self.proxied = proxied # in case proxied is an __iter__ iterator @property def __iter__(self): if not hasattr(self.proxied, '__iter__'): raise AttributeError else: return *lambda:* self @property def __next__(self): if not hasattr(self.proxied, '__next__'): raise AttributeError else: return *lambda: *next(self.proxied) The iter machinery doesn't grab values and call them, you've misinterpreted the error. Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23961] IDLE autocomplete window does not automatically close when selection is made
Al Sweigart added the comment: I should clarify: I'm referring to the Show Completion feature. The repro steps are (on Windows 7 64-bit, Python 3.5) 1. Type pri 2. Press Ctrl+Space or click Edit Show Completions. The autocomplete window appears. 3. Press Tab. The text updates from pri to print 4. However, the autocomplete window is still there. 5. Pressing space or ( will then cause the autocomplete window to disappear. This is distinct from issue 15786, but close enough that I'll close this bug and add this comment to it. Thanks for the input! -- resolution: - duplicate ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23961 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23496] Steps for Android Native Build of Python 3.4.2
Cyd Haselton added the comment: Do you have the time/means to create a quick patch for that? I ask because even a simple flip like that becomes a major pain when working with nano on a tablet. If not, I'll start on it. Just thought Id ask -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23995] msvcrt could not be imported
New submission from petrikas: Python cannot access msvcrt's putwch() when using manage.py syncdb To reproduce: 1. Call manage.py syncdb and try to create a new superuser 2. It crashes after inputting email (or before asking for the password) Reproducible with 3.5a3, seems to be a regression from 3.4.3. Downgrading fixed the issue -- components: Library (Lib) messages: 241438 nosy: petrikas priority: normal severity: normal status: open title: msvcrt could not be imported type: crash versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23995] msvcrt could not be imported
petrikas added the comment: Edit: I am using a windows 8.1 system and django 1.8 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23989] Add recommendation to use requests to the documentation, per summit
Gregory P. Smith added the comment: nice and simple. that wording looks good to me. -- nosy: +gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23989 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values
Ned Deily added the comment: Current source releases of Python do not specify which version of Tk they should be run with; that is largely up to the distributors of Python (including python.org binary installers for Windows and OS X) and the conventions of the platform the instances are running on. There are versions of current Python 3.4.x and Python 2.7.x running on supported platforms (like OS X) with various flavors of Tk 8.6, 8.5, and even 8.4. So Python documentation has to be careful to avoid making assumptions about Tk version-specific features. FWIW, a link to Tk 8.6 differences is provided on the Tcl/Tk 8.6 release page (http://www.tcl.tk/software/tcltk/8.6.html) - Changes in Tcl/Tk 8.6 (http://wiki.tcl.tk/21276). -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23725] update tempfile docs to say that TemporaryFile is secure
R. David Murray added the comment: Made one minor suggestion in review comments (related to that deleted line). Otherwise this looks good to me, thanks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ethan Furman added the comment: Perhaps callable() should be in the inspect module? ;) Speaking of which, how do all the is... functions there work with this descriptor implementation? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23995] msvcrt could not be imported
R. David Murray added the comment: Can you reproduce this without involving Django? That would make it more likely that someone will have time to take a look at it. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
R. David Murray added the comment: They use isinstance, except for a couple that also check co_flags, and the ones that check if the object is a descriptor. I haven't thought this through fully, but I think this means that in general the descriptor protocol has been invoked or not by the caller of inspect before inspect checks the object. There is no 'callable' type in python, so the closest analog in the inspect module to 'callable' are the functions that look for __get__ and __set__ methods on descriptors. If one of *those* is a descriptor, my head will start hurting :). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: Turns out I've replied through email, and code got mangled. This is the correct version: class GenericProxy: def __init__(self, proxied): self.proxied = proxied @property def __iter__(self): if not hasattr(self.proxied, '__iter__'): raise AttributeError else: return lambda: self @property def __next__(self): if not hasattr(self.proxied, '__next__'): raise AttributeError else: return lambda: next(self.proxied) Note the lambdas. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23496] Steps for Android Native Build of Python 3.4.2
Ryan Gonzalez added the comment:
Ok...try going to Python/pylifecycle.c and changing lines 220-230 from:
#elif defined(HAVE_LANGINFO_H) defined(CODESET)
char* codeset = nl_langinfo(CODESET);
if (!codeset || codeset[0] == '\0') {
PyErr_SetString(PyExc_ValueError, CODESET is not set or empty);
return NULL;
}
return get_codec_name(codeset);
#elif defined(__ANDROID__)
char* m = malloc(6);
strcpy(m, ascii);
return m;
to:
#elif defined(__ANDROID__)
char* m = malloc(6);
strcpy(m, ascii);
return m;
#elif defined(HAVE_LANGINFO_H) defined(CODESET)
char* codeset = nl_langinfo(CODESET);
if (!codeset || codeset[0] == '\0') {
PyErr_SetString(PyExc_ValueError, CODESET is not set or empty);
return NULL;
}
return get_codec_name(codeset);
I just swapped the `elif`'s around.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23496
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ethan Furman added the comment: I am happy to be proven wrong. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Christian Heimes added the comment:
On 2015-04-18 19:43, Ionel Cristian Mărieș wrote:
Ionel Cristian Mărieș added the comment:
On Sat, Apr 18, 2015 at 8:35 PM, Christian Heimes rep...@bugs.python.org
wrote:
You also haven't shown that this behavior violates the documentation and
language spec.
How can I show it violates the spec when there's not such thing? :-)
AFAIK, `callable` is not specified in any PEP. Please give some references
when you make such statements.
The language specs is made up from two things:
1) the CPython reference implemention
2) the documentation of the CPython reference implementation
3) accepted and implemented PEPs
If 3) doesn't exist and 2) doesn't contain any point that contradicts
1), then 1) and 2) agree on an implementation and therefore it is
informally specified. The fact that PyPy and Jython show the same
behavior, adds additional weight to 1), too.
callable() has been implemented like that since the introduction of new
style classes, too.
$ hg checkout v2.2
$ grep -A20 ^PyCallable_Check Objects/object.c
PyCallable_Check(PyObject *x)
{
if (x == NULL)
return 0;
if (PyInstance_Check(x)) {
PyObject *call = PyObject_GetAttrString(x, __call__);
if (call == NULL) {
PyErr_Clear();
return 0;
}
/* Could test recursively but don't, for fear of endless
recursion if some joker sets self.__call__ = self */
Py_DECREF(call);
return 1;
}
else {
return x-ob_type-tp_call != NULL;
}
}
You really have to make a *very* good case with a PEP in order to get
everybody to switch to a different behavior!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23990
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23964] Update README documentation for IDLE tests.
Al Sweigart added the comment: I'll add a note about running the human-mediated tests to section 0. Running python -m test.test_idle for 64-bit 3.4.3 on Windows 7 works fine for me (Ran 142 tests in 0.605s OK) I'll take out the indented code. You make a good point about copy/paste. I've added section 4 on human-mediated tests. I'd like to take a crack at improving the documentation a bit in htest.py before figuring out what to add to section 4. This can be addressed in a later patch. -- Added file: http://bugs.python.org/file39107/idle_test_readme.2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23964 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23496] Steps for Android Native Build of Python 3.4.2
Ryan Gonzalez added the comment:
Here:
diff -r 38f5b3beeb2a Python/pylifecycle.c
--- a/Python/pylifecycle.c Thu Mar 19 15:16:03 2015 -0500
+++ b/Python/pylifecycle.c Sat Apr 18 13:07:36 2015 -0500
@@ -217,6 +217,10 @@
char codepage[100];
PyOS_snprintf(codepage, sizeof(codepage), cp%d, GetACP());
return get_codec_name(codepage);
+#elif defined(__ANDROID__)
+char* m = malloc(6);
+strcpy(m, ascii);
+return m;
#elif defined(HAVE_LANGINFO_H) defined(CODESET)
char* codeset = nl_langinfo(CODESET);
if (!codeset || codeset[0] == '\0') {
@@ -224,10 +228,6 @@
return NULL;
}
return get_codec_name(codeset);
-#elif defined(__ANDROID__)
-char* m = malloc(6);
-strcpy(m, ascii);
-return m;
#else
PyErr_SetNone(PyExc_NotImplementedError);
return NULL;
On Sat, Apr 18, 2015 at 12:39 PM, Cyd Haselton rep...@bugs.python.org
wrote:
Cyd Haselton added the comment:
Do you have the time/means to create a quick patch for that?
I ask because even a simple flip like that becomes a major pain when
working with nano on a tablet.
If not, I'll start on it. Just thought Id ask
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23496
___
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23496
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
R. David Murray added the comment: I understand Ionel's point, and it is indeed 'callable' that is the outlier here. It only looks for the *existence* of the attribute, rather than actually retrieving it through the descriptor protocol (and therefore getting the AttributeError from the property). Protocols like iter, on the other hand, actually use the attribute, and therefore do access it via the descriptor protocol, and properties therefore act like one would naively expect them to. That doesn't mean we should definitely change callable, but it does mean the idea isn't obviously wrong. IMO it is indeed callable that has the surprising behavior here. (Note: I did not think that at first, but I do after reading the iter discussion. (NB: in general, __iter__ should *not* return self; that's a bug waiting to happen.)) But, callable is also...not exactly Pythonic at its core, as evidenced by Guido's desire to get rid of it. So the fact that it is in some sense buggy or at least surprising is perhaps something that we just live with because of that. IMO, code that depends on a __call__ property is a bit suspect anyway. Something should be callable or not, not conditionally callable. If a program wants things to be conditionally callable, the program can establish its own protocol for that. (The same applies to __iter__, but there's no reason to intentionally break the fact that it does work, since it just falls out of how the language works.) So I guess my feeling is...callable is buggy, but callable is a buggy API :) So I'm 0 on this issue (not even +0 or -0). -- nosy: +r.david.murray resolution: - not a bug stage: test needed - resolved status: open - closed type: enhancement - behavior versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4 -Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ 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
Gregory P. Smith added the comment: I think this was just overlooked when implementing argparse. Most code out there is likely to get the executable name using: os.path.basename(sys.argv[0]) Which is going to do exactly what you are seeing here when sys.argv[0] ends with a /. feel free to submit a patch. perhaps as simple as this? os.path.basename(sys.argv[0].rstrip(os.path.sep)) But I'd expect a bunch of other code out there to have the same problem. -- nosy: +gregory.p.smith ___ 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
[issue23955] Add python.ini file for embedded/applocal installs
Steve Dower added the comment: I could reuse the venv config file but it would need a new property to forcibly use the 'home' value regardless of whether '$home\Lib\os.py' exists (in case the stdlib is zipped) and to make it relative to the file's path rather than the user's current directory. How about adding an 'applocal=True' property to pyvenv.cfg that basically implies -I, PYTHONHOME=os.dirname(pyvenv_cfg), and skips the registry lookup on Windows completely (which there's currently no way to achieve)? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23955 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5784] raw deflate format and zlib module
A.M. Kuchling added the comment: Thanks! Here's an updated version with some more rewriting -- the list is now in only one place and is linked-to from the decompression documentation. -- Added file: http://bugs.python.org/file39105/patch-5784.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5784 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23955] Add python.ini file for embedded/applocal installs
Steve Dower added the comment: Arguably we should be making 'home' in pyvenv.cfg relative to the pyvenv.cfg file's directory anyway... AFAIK it's always generated as an absolute path, but I see no good reason to prevent people from manually configuring a relative path here. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23955 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23984] Documentation error: Descriptors
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- assignee: docs@python - rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23984 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15786] IDLE code completion window can hang or misbehave with mouse
Al Sweigart added the comment: Additionally, pressing tab after the autocomplete window has appeared should not just update the text but also close the autocomplete window. The repro steps are (on Windows 7 64-bit, Python 3.5): 1. Type pri 2. Press Ctrl+Space or click Edit Show Completions. The autocomplete window appears. 3. Press Tab. The text updates from pri to print 4. However, the autocomplete window is still there. 5. Pressing space or ( will then cause the autocomplete window to disappear. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15786 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Christian Heimes added the comment: All major Python implementation have a mutual agreement that callable() just checks for a __call__ member on the type. You also haven't shown that this behavior violates the documentation and language spec. The check for existence of __call__ on the type is well in the range of expected behavior. I as well as other core devs had the same gut feeling. Finally your suggestion makes the implementation of callable() more complex and much, much slower. Right now and for more than a decade it is a simple, fast and straight forward code path for new style classes. It just requires two pointer derefs and one comparison to NULL. I'm still -1 on the change. If you want to go forth with your request then you must write a PEP and convince all implementors of Python implementations to change the current way callable() and other protocols like iter work. $ python2.7 Python 2.7.8 (default, Nov 10 2014, 08:19:18) [GCC 4.9.2 20141101 (Red Hat 4.9.2-1)] on linux2 Type help, copyright, credits or license for more information. class A(object): ... @property ... def __call__(self): ... raise AttributeError ... a = A() print(callable(a)) True a() Traceback (most recent call last): File stdin, line 1, in module File stdin, line 4, in __call__ AttributeError $ jython Jython 2.7b3+ (, Nov 3 2014, 11:02:14) [OpenJDK 64-Bit Server VM (Oracle Corporation)] on java1.8.0_40 Type help, copyright, credits or license for more information. class A(object): ... @property ... def __call__(self): ... raise AttributeError ... a = A() print(callable(a)) True a() Traceback (most recent call last): File stdin, line 1, in module File stdin, line 4, in __call__ AttributeError $ pypy Python 2.7.8 (a980ebb26592ed26706cd33a4e05eb45b5d3ea09, Sep 24 2014, 07:41:52) [PyPy 2.4.0 with GCC 4.9.1 20140912 (Red Hat 4.9.1-9)] on linux2 Type help, copyright, credits or license for more information. class A(object): @property def __call__(self): raise AttributeError a = A() print(callable(a)) True a() Traceback (most recent call last): File stdin, line 1, in module File stdin, line 4, in __call__ AttributeError -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ 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
New submission from Mert Bora Alper: Sorry if the title is not descriptive enough. When I try to execute a program from a directory which contains an `__main__.py` file, argparse fails to detect programs name. For example: $ ls foo __main__.py $ python3 foo usage: foo [-h] [-c COUNT] length foo: error: the following arguments are required: length $ python3 foo/ usage: [-h] [-c COUNT] length : error: the following arguments are required: length argparse.__version__ '1.1' I followed same steps using Python 2.7.6 and got same result. It will probably be same on other versions too. Same result can also be obtained when using zip files instead of directories. I don't know if this is a bug since I don't know if I do something wrong or is this a design decision or not. Thank you, Bora -- components: Library (Lib) files: __main__.py messages: 241434 nosy: boramalper priority: normal severity: normal status: open title: argparse fails to detect program name when there is a slash at the end of the program's path type: behavior versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file39106/__main__.py ___ 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
[issue23971] dict(list) and dict.fromkeys() doesn't account for 2/3 fill ratio
Gregory P. Smith added the comment: fwiw, as for 2.7 i personally don't think I would change its behavior around this at this point. make sure 3.5+ do something desirable. (my link to dictobject.c above is from 2.7) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23971 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23992] multiprocessing: MapResult shouldn't fail fast upon exception
Changes by Ned Deily n...@acm.org: -- nosy: +davin, sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23992 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23995] msvcrt could not be imported
eryksun added the comment: The new CRT used by 3.5 has a separate header, corecrt_wconio.h, for declarations shared by conio.h and wchar.h. Thus the _WCONIO_DEFINED macro is no longer defined, and consequently PC/msvcrtmodule.c skips defining getwch, getwche, putwch, and ungetwch. I guess this check was added to support DOS-based Windows 9x. NT-based Windows would always support wide-character console I/O. -- components: +Windows nosy: +eryksun, steve.dower, tim.golden, zach.ware ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ethan Furman added the comment:
Your example shows /having/ an iterator, while mine is /being/ an iterator.
A simple iterator:
# iterator protocol
class uc_iter():
def __init__(self, text):
self.text = text
self.index = 0
def __iter__(self):
return self
def __next__(self):
try:
result = self.text[self.index].upper()
except IndexError:
raise StopIteration
self.index += 1
return result
ucii = uc_iter('abc')
I believe your over-arching goal is a proxy class?
class GenericProxy:
def __init__(self, proxied):
self.proxied = proxied
# in case proxied is an __iter__ iterator
@property
def __iter__(self):
if not hasattr(self.proxied, '__iter__'):
raise AttributeError
else:
return self
@property
def __next__(self):
if not hasattr(self.proxied, '__next__'):
raise AttributeError
else:
return next(self.proxied)
and then two proxies to test -- a non-iterable and an iterable:
gp_ni = GenericProxy(object())
gp_ucii = GenericProxy(ucii)
and a quick harness:
try:
for _ in iter(gp_ni):
print(_)
except Exception as e:
print(e)
try:
for _ in iter(gp_ucii):
print(_)
except Exception as e:
print(e)
Note: the presence/absence of iter() makes no difference to the results below.
The non-iterable gives the correct error: 'GenericProxy' object is not iterable
But the iterable gives: 'GenericProxy' object is not callable
That error message is a result of the iter machinery grabbing the __next__
attribute and trying to call it, but property attributes are not callable.
In other words, iter() does not honor the descriptor protocol.
So now we have two: callable() and iter(). How many more are there?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23990
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
Ionel Cristian Mărieș added the comment: On Sat, Apr 18, 2015 at 8:35 PM, Christian Heimes rep...@bugs.python.org wrote: You also haven't shown that this behavior violates the documentation and language spec. How can I show it violates the spec when there's not such thing? :-) AFAIK, `callable` is not specified in any PEP. Please give some references when you make such statements. [...] write a PEP and convince all implementors of Python implementations to change the current way callable() and other protocols like iter work. `iter` works fine, as outlined above? Am I missing something? What other protocols do you have in mind, wrt honoring descriptors? Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23993] Use surrogateescape error handler by default in open() if the LC_CTYPE locale is C at startup
R. David Murray added the comment: Hmm. Upon reflection I guess I can see the validity of if you are using the C locale you or the OS are broken anyway, so we'll just pass the bytes through. I'm not entirely convinced this won't cause issues, but I suppose it might not cause any more issues that having things break due to the C locale does. It is, however, going to return us to the days when a program that works fine most of the time suddenly blows up in the face of non-ascii data, and that's my biggest concern. I'd certainly be fine with it if it wasn't the default (that is, programs who need this have to opt in to it). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23993 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23971] dict(list) and dict.fromkeys() doesn't account for 2/3 fill ratio
Gregory P. Smith added the comment: Won't we always consume the memory thanks to a memset(newtable, 0, ...) https://hg.python.org/cpython/file/df28044b7e14/Objects/dictobject.c#l654 ? (also, i'm not sure if Windows is allocates mapped pages on demand as posix systems tend to) -- nosy: +gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23971 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23725] update tempfile docs to say that TemporaryFile is secure
R. David Murray added the comment: Oh, because of the O_TMPDIR bits, this patch is only applicable to 3.5, so I'm removing 3.4 from versions. I don't think it is worth it to make a version that would apply to 3.4, since it is not the case that the 3.4 docs are *wrong*. -- versions: -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23990] Callable builtin doesn't respect descriptors
R. David Murray added the comment: Oops, I accidentally changed the bug status due to not refreshing before I posted. -- resolution: not a bug - stage: resolved - status: closed - open versions: +Python 3.5 -Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23990 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23496] Steps for Android Native Build of Python 3.4.2
Cyd Haselton added the comment: Ryan, Sorry...same problem. Segmentation fault generate-posix-vars failed make: *** [pybuilddir.txt] Error 1 /bld/python/cpython-master/cpython $ addr2line -C -f -e /lib/libpython3.5m.so.1.0 0008f42c _PyMem_RawStrdup /bld/python/cpython-master/cpython/Objects/obmalloc.c:358 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23984] Documentation error: Descriptors
Raymond Hettinger added the comment: In addition to being broken, the code is a crummy example that gives no hint of why one might want to use a staticmethod. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23984 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23997] unicodedata_UCD_lookup() has theoretical buffer overflow
New submission from Christian Heimes: Coverity has found a potential buffer overflow in the unicodedata module. The function call _getcode() which calls _cmpname(). _cmpname() copies data into fixed size buffer of length NAME_MAXLEN. Neither lookup() nor _getcode() limit name_length to NAME_MAXLEN. Therefore the buffer could theoretical overflow. In practice the buffer overflow can't be abused because Tools/unicode/makeunicodedata.py already limits max name length. I still like to fix the bug because it is a low hanging fruit. In most versions of Python the code already checks that name_length fits in INT_MAX. CID 1295028 (#1 of 1): Out-of-bounds access (OVERRUN) overrun-call: Overrunning callee's array of size 256 by passing argument (int)name_length (which evaluates to 2147483647) in call to _getcode -- files: unicode_name_maxlen.patch keywords: patch messages: 241461 nosy: benjamin.peterson, christian.heimes, ezio.melotti, haypo, lemburg, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: unicodedata_UCD_lookup() has theoretical buffer overflow type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39109/unicode_name_maxlen.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23997 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23998] PyImport_ReInitLock() doesn't check for allocation error
New submission from Christian Heimes: _PyImport_ReInitLock() doesn't check the return value of PyThread_allocate_lock(). A failed lock allocation can either lead to a NULL pointer dereference or to race conditions caused by a missing import lock. As there is no way to recover from a failed lock allication I recommend to abort with a fatal error. CID 1295025 (#1 of 1): Dereference after null check (FORWARD_NULL) var_deref_model: Passing null pointer import_lock to PyThread_acquire_lock, which dereferences it. -- files: import_reinit_fatal.patch keywords: buildbot, easy, patch messages: 241462 nosy: christian.heimes priority: normal severity: normal stage: patch review status: open title: PyImport_ReInitLock() doesn't check for allocation error type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39110/import_reinit_fatal.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23998 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17227] devguide: buggy heading numbers
Carol Willing added the comment: Correct Python Developer FAQ Section 28 to match the style of Section 27. Section numbers should now flow correctly in Sphinx. A section contents is displayed at the top of the section page for the user's convenience (especially since the FAQ questions have long titles). -- assignee: - willingc nosy: +willingc stage: - patch review Added file: http://bugs.python.org/file39111/iss17227.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17227 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions
New submission from Stefan Behnel: The yield-from implementation calls _PyGen_FetchStopIterationValue() to get the exception value. If the StopIteration exception is not normalised, e.g. because it was set by PyErr_SetObject() in a C extension, then _PyGen_FetchStopIterationValue() will cast to (PyStopIterationObject*) whatever the exception value is and happily interpret an arbitrary memory position as PyObject*. I attached a possible patch for the function. Another place to fix it would be in the yield-from code in ceval.c, but directly genobject.c seems the safer place. -- components: Interpreter Core files: fix_stopiteration_crash.patch keywords: patch messages: 241454 nosy: scoder priority: normal severity: normal status: open title: _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions type: crash versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39108/fix_stopiteration_crash.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23996 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23992] multiprocessing: MapResult shouldn't fail fast upon exception
Davin Potts added the comment: This is a nice example demonstrating what I agree is a problem with the current implementation of close. A practical concern with what I believe is being proposed in your trivial fix: if the workers are engaged in very long-running tasks (and perhaps slowly writing their overly large results to the results queue) then we would have to wait for quite a long time for these other workers to reach their natural completion. That said, I believe close should in fact behave just that way and have us subsequently wait for the others to be completed. It is not close's job to attempt to address the general concern I bring up. This change could be felt by people who have written their code to expect the result handler's immediate shutdown if there are no other visible results -- it is difficult to imagine what the impact would be. This is my long-winded way of saying it seems very sensible and welcome to me if you took the time to prepare a patch. -- stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23992 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23999] Undefined behavior in dtoa.c (rshift 32 of 32bit data type)
New submission from Christian Heimes: Coverity has found undefined behavior in dtoa.c:d2b(). lo0bits() can return 32 which z = 32, where z is an uint32. I've talked to doku at PyCon. He suggested to update dtoa.c to a more recent version. Our copy is based on a version from 2001. There are more modern versions available, e.g. https://searchcode.com/codesearch/view/52748288/ from 2006. CID 1202735 (#1 of 1): Bad bit shift operation (BAD_SHIFT) large_shift: In expression z = k, right shifting by more than 31 bits has undefined behavior. The shift amount, k, is 32. -- messages: 241464 nosy: christian.heimes, doko, eric.smith, mark.dickinson, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Undefined behavior in dtoa.c (rshift 32 of 32bit data type) type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23999 ___ ___ 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
Davin Potts added the comment: Though it's been discussed elsewhere, issue17560 is a good one where the matter of really big objects are being communicated between processes via multiprocessing. In it, Richard shares some detail about the implementation in multiprocessing, its constraints and motivation. That discussion also highlights that the pickler has been made pluggable in multiprocessing since Python 3.3. That is, if you wish, you can use something other than Python's pickle to serialize objects and, in the extreme, potentially communicate them in a completely new way (perhaps even via out-of-band communication, though that was not the intention and would be arguably extreme). I do not think Python's pickle is necessarily what we should expect multiprocessing to use to help communicate objects between processes. Just because pickle is Python's serialization strategy does not also mean it must necessarily also be used in such communications. Thankfully, we have the convenience of using something other than pickle (or newer versions of pickle, since there have been versioned updates to pickle's format over time with some promising improvements). @Luis: To your specific question about the need for Queue, the benefits of a consistent behavior and methodology whether forking/spawning on one OS with its caveats versus another are just that: simplicity. The pluggable nature of the pickler opens up the opportunity for folks (perhaps such as yourself) to construct and plug-in optimized solutions for scenarios or edge cases of particular interest. The fact that we all start with a consistent behavior across platforms and process creation strategies is very appealing from a reduced complexity point of view. -- nosy: +davin ___ 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
[issue23995] msvcrt could not be imported
Steve Dower added the comment: You're right, we should be able to remove the ifdef for these (or hide them behind MS_WINDOWS if necessary). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23995 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23993] Use surrogateescape error handler by default in open() if the LC_CTYPE locale is C at startup
STINNER Victor added the comment: if you are using the C locale you or the OS are broken anyway, so we'll just pass the bytes through Exactly. Even if you use Unicode, the Python 3 str type, you store text as raw bytes (in a custom format, as surrogate characters). I'm not entirely convinced this won't cause issues, but I suppose it might not cause any more issues that having things break due to the C locale does. The most obvious issue is the come back of mojibake. Since you manipulate raw bytes, it's easy to concatenate two bytes strings encoded to two different encodings. https://unicodebook.readthedocs.org/definitions.html#mojibake The problem is that the question is not how bad it is use to manipulate text as bytes. The problem is that a working application written for Python 2 starts to randomly fail (on non-ASCII characters) on Python 3 when the LC_CTYPE locale is the POSIX locale (C). The first question is: should I keep Python 2 or write my application in a language which doesn't force me to understand Unicode? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23993 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16930] mention limitations and/or alternatives to hg graft
Changes by Carol Willing willi...@willingconsulting.com: -- assignee: - willingc nosy: +willingc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16930 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16931] mention work-around to create diffs in default/non-git mode
Changes by Carol Willing willi...@willingconsulting.com: -- assignee: - willingc nosy: +willingc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16931 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15566] tarfile.TarInfo.frombuf documentation is out of date
Martin Panter added the comment: Very simple documentation fix; looks good to me. -- nosy: +vadmium stage: needs patch - commit review versions: +Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24000] More fixes for the Clinic mapping of converters to format units
New submission from Larry Hastings: I found another bug in the mapping of converters to format units. (s#, z#, and y# all allow zeroes.) I've redone the approach for str_converter in an attempt to make it easier to read. It'd be swell if, after this gets checked in (or rejected), somebody *else* took a pass to see if they could find any bugs. -- assignee: larry files: larry.one.more.clinic.format.unit.map.cleanup.1.txt messages: 241468 nosy: larry, serhiy.storchaka, zach.ware priority: normal severity: normal stage: patch review status: open title: More fixes for the Clinic mapping of converters to format units type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file39113/larry.one.more.clinic.format.unit.map.cleanup.1.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24000 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24001] Clinic: use raw types in types= set
New submission from Larry Hastings:
New proposed semantics for the types= parameter to converters: where possible,
pass in actual types. The resulting syntax:
c: int(types={str}) # maps to 'U'
s: str(types={str, robuffer}, length=True, zeroes=True) # maps to 's#'
Since buffer, robuffer, and rwbuffer are fake pseudotypes, I created
empty classes with those names.
Serhiy: with this change in place, the types= parameter uses almost the same
number of characters as it used to when it was a string. (The new syntax
requires commas between elements, so for two or more types it's slightly
longer.) Yet this makes the types= parameter far more accurate in illustrating
what it's supposed to represent.
Does this make you happy? :)
--
assignee: larry
components: Argument Clinic
files: larry.clinic.use.raw.types.1.txt
messages: 241469
nosy: larry, serhiy.storchaka, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Clinic: use raw types in types= set
type: enhancement
Added file: http://bugs.python.org/file39114/larry.clinic.use.raw.types.1.txt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24001
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17227] devguide: buggy heading numbers
Berker Peksag added the comment: Thanks! The patch doesn't address msg182641 and I think this is a Sphinx bug(or perhaps a feature request?). tocdepth should not change the heading numbers. I couldn't find any similar report on the Sphinx issue tracker. So I suggest opening an issue there and closing this one as third party. -- nosy: +berker.peksag ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17227 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15566] tarfile.TarInfo.frombuf documentation is out of date
Roundup Robot added the comment: New changeset d737ab3ea1ae by Berker Peksag in branch '3.4': Issue #15566: Document encoding and errors parameters of TarInfo.frombuf(). https://hg.python.org/cpython/rev/d737ab3ea1ae New changeset 85cba64e24dc by Berker Peksag in branch 'default': Issue #15566: Document encoding and errors parameters of TarInfo.frombuf(). https://hg.python.org/cpython/rev/85cba64e24dc -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23275] Can assign [] = (), but not () = []
Nick Coghlan added the comment: As Raymond notes, this is a fairly harmless quirk - it changes a SyntaxError to an iterable length dependent ValueError: () = [] File stdin, line 1 SyntaxError: can't assign to () [] = () [] = [1] Traceback (most recent call last): File stdin, line 1, in module ValueError: too many values to unpack (expected 0) I only found out about this after being puzzled when a typo in a live demo at PyCon 2015 failed to fail as I expected after seeing the presenter type a [] into the LHS of an assignment instead of the intended _. Removing the data dependence to make the assignment fail immediately (even if never tested against a non-empty iterable) would involve making the handling of List_kind match that of Tuple_kind in the switch statement that eryksun quoted. I don't think it's an urgent fix, but if someone wanted to fix it (including a new test), I think it would be a reasonable contribution to accept. -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23275 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23901] Force console stdout to use UTF8 on Windows
STINNER Victor added the comment: If sys.stdout is modified, it must be carefully tested in various scenario: - Windows console, default config - Windows console, TrueType font - PowerShell = see #21927, it looks like PowerShell has its own set of Unicode issues - Redirect output into a file - etc. Very good articles by Michael S. Kaplan on Windows stdout/console: - Conventional wisdom is retarded, aka What the @#%* is _O_U16TEXT? http://www.siao2.com/2008/03/18/8306597.aspx - Myth busting in the console http://www.siao2.com/2010/10/07/10072032.aspx - Cunningly conquering communicated console caveats. Comprende, mon Capitán? http://www.siao2.com/2010/05/07/10008232.aspx See also fwide() function. Good luck... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23901 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23740] http.client request and send method have some datatype issues
Changes by Akshit Khurana axitkhur...@gmail.com: -- nosy: +axitkhurana ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23740 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23725] update tempfile docs to say that TemporaryFile is secure
Zbyszek Jędrzejewski-Szmek added the comment: v6: - add newline -- Added file: http://bugs.python.org/file39112/tempfile_docs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15566] tarfile.TarInfo.frombuf documentation is out of date
Berker Peksag added the comment: Thanks! -- nosy: +berker.peksag resolution: - fixed stage: commit review - resolved status: open - closed versions: -Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15566 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23275] Can assign [] = (), but not () = []
Martin Panter added the comment: I would prefer this be fixed in the opposite direction, to allow “unpacking” an empty iterable using round brackets. I have used this syntax on purpose as a concise way to ensure that a generator is exhaused with no more yields: def gen(): ... yield partial computation ... print(computation allowed to complete) ... g = gen() next(g) 'partial computation' [] = g computation allowed to complete -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23275 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24001] Clinic: use raw types in types= set
Larry Hastings added the comment: Should types= be renamed accept= ? It's a set of the types of the Python objects that this parameter should accept. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24001 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23920] Should Clinic have nullable or types=NoneType?
Larry Hastings added the comment:
I'm now converging on changing types= to accept a set of real types, see issue
#24001. That change has an impact on this decision.
(By the way, let's assume that if nullable, I have to rename it to
accepts_none. I'll use that name below.)
What makes me want to use types={NoneType} is the Zen: There should be one
(and preferably only one) obvious way to do it, and Special cases aren't
special enough to break the rules. But Argument Clinic's input isn't Python,
so maybe the Zen doesn't need to be as strict here.
What makes me not want to use types={NoneType} is that it's generally longer,
and it requires you to know the default types accepted by a converter.
Currently (after the rename) to get format unit z you write:
s: str(accepts_none=True)
If I changed this (and #24001 goes in), you'd have to write:
s: str(types={str, NoneType})
It requires you to know all the default types of the converter in question,
just so you can add NoneType to it. And it's longer.
We could fix it if converter classes generally published their default types.
So you could say
s: str(types=str_converter.default_types + {NoneType})
And it's even longer. So we probably shouldn't bother with this.
On the other hand, out of all the converters that exist, only three have a
types= argument (int, str, and Py_buffer). And it's not unreasonable to expect
the caller to know the default types= set. Although, we'd have to add types=
to a fourth converter (Py_UNICODE), which currently supports nullable= but
doesn't need types=.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23920
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24002] Add un-parse function to ast
New submission from Larry Hastings: Twice recently I've wanted a function that transforms an AST node tree back into text: * In the hacked-up Tools/clinic/clinic.py for issue #24001 * In the hacked-up Lib/inspect.py for issue #23967 Both times I did a half-assed job just to get the patch working, so we could decide whether or not we want to go this route. It seems useful and reasonable to do a proper job and add this functionality to ast. -- components: Library (Lib) messages: 241477 nosy: benjamin.peterson, georg.brandl, larry priority: normal severity: normal stage: needs patch status: open title: Add un-parse function to ast type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24002 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23967] Make inspect.signature expression evaluation more powerful
Larry Hastings added the comment: I should mention that evalify_node() is pretty hacked up here, and is not ready to be checked in. (I'm proposing separately that we simply add something like this directly into the standard library, see issue #24002.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23967 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24001] Clinic: use raw types in types= set
Larry Hastings added the comment: I should mention that evalify_node() is pretty hacked up here, and is not ready to be checked in. (I'm proposing separately that we simply add something like this directly into the standard library, see issue #24002.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24001 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24002] Add un-parse function to ast
Changes by Larry Hastings la...@hastings.org: -- nosy: +serhiy.storchaka, zach.ware ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24002 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23920] Should Clinic have nullable or types=NoneType?
Serhiy Storchaka added the comment: accepts_none=True looks as doesn't accept anything to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23920 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24002] Add un-parse function to ast
Berker Peksag added the comment: Perhaps a NodeVisitor subclass (something like Armin Ronacher's codegen module https://github.com/berkerpeksag/astor/blob/master/astor/codegen.py#L54 can be added to the ast module. -- nosy: +berker.peksag ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24002 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24001] Clinic: use raw types in types= set
Serhiy Storchaka added the comment: accept= (or accept_types=) LGTM. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24001 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24002] Add un-parse function to ast
Larry Hastings added the comment: Good idea, I'll go ahead and borrow Guido's time machine. https://docs.python.org/3/library/ast.html#ast.NodeVisitor However, NodeVisitor does not transform the ast tree back into text. So in what way is this helpful? Also, for what it's worth: both my use cases only need to handle expressions (r-values if you prefer). I don't need to generate classes, functions, blocks, or even statements. If we wanted to weaken the implementation to only handle expressions I'd be happy. (In fact, I'd be happier this way, because it means the implementation would be much simpler!) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24002 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23920] Should Clinic have nullable or types=NoneType?
Larry Hastings added the comment: Oh, I misremembered. The name allow_none was inflicted on me by python-dev, in this thread: https://mail.python.org/pipermail/python-dev/2014-August/135650.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23920 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19087] bytearray front-slicing not optimized
Martin Panter added the comment: I think the changes for this issue are causing the crash and unexpected buffer expansion described in Issue 23985. Appending to a bytearray() can overstep the memory buffer because it doesn’t account for ob_start when checking for resizing. And “del” can expand the allocated memory due to an off-by-one error. Please have a look at my patches. Perhaps there are other operations that also need patching to account for ob_start. -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19087 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23991] ZipFile sanity checks
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +alanmcintyre, serhiy.storchaka, twouters ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23991 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23985] Crash when deleting slices from duplicated bytearray
Martin Panter added the comment: This bug might have been caused by the changes for Issue 19087, so I left a note there. It looks like that issue added the ob_start field to bytearray() objects, so that deleting from the start does not require memory copying. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23985 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14438] _cursesmodule build fails on cygwin
Changes by Masayuki Yamamoto light2happy@gmail.com: -- nosy: +masamoto ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14438 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13756] Python3.2.2 make fail on cygwin
Changes by Masayuki Yamamoto light2happy@gmail.com: -- nosy: +masamoto ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13756 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19051] Unify buffered readers
Martin Panter added the comment: The LZMA, gzip and bzip modules now all use BufferedReader, so Serhiy’s patch is no longer relevant for them. Serhiy’s patch also changed the zipfile module, which may be still relevant. On the other hand, perhaps it would be more ideal to use BufferedReader for the zipfile module as well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19051 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23992] multiprocessing: MapResult shouldn't fail fast upon exception
New submission from Charles-François Natali: hanger.py from time import sleep def hang(i): sleep(i) raise ValueError(x * 1024**2) The following code will deadlock on pool.close(): from multiprocessing import Pool from time import sleep from hanger import hang with Pool() as pool: try: pool.map(hang, [0,1]) finally: sleep(0.5) pool.close() pool.join() The problem is that when one of the tasks comprising a map result fails with an exception, the corresponding MapResult is removed from the result cache: def _set(self, i, success_result): success, result = success_result if success: [snip] else: self._success = False self._value = result if self._error_callback: self._error_callback(self._value) === del self._cache[self._job] self._event.set() === Which means that when the pool is closed, the result handler thread terminates right away, because it doesn't see any task left to wait for. Which means that it doesn't drain the result queue, and if some worker process is trying to write a large result to it (hence the large valuerrror to fill the socket/pipe buffer), it will hang, and the pool won't shut down (unless you call terminate()). Although I can see the advantage of fail-fast behavior, I don't think it's correct because it breaks the invariant where results won't be deleted from the cache until they're actually done. Also, the current fail-fast behavior breaks the semantics that the call only returns when it has completed. Returning while some jobs part of the map are still running is potentially very bad, e.g. if the user call retries the same call, assuming that all the jobs are done. Retrying jobs that are idempotent but not parallel execution-safe would break with the current code. The fix is trivial, use the same logic as in case of success to only signal failure when all jobs are done. I'll provide a patch if it seems sensible :-) -- components: Library (Lib) messages: 241404 nosy: neologix, pitrou priority: normal severity: normal status: open title: multiprocessing: MapResult shouldn't fail fast upon exception type: behavior versions: Python 2.7, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23992 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23993] Use surrogateescape error handler by default in open() if the locale is C
New submission from STINNER Victor: As a following of the issue #19977, I propose to use also the surrogateescape error handler in open() by default if the locale is C. Attached issue adds a new sys.getdefaulterrorhandler() function and use it in io.TextIOWrapper (and _pyio.TextIOWrapper). We may use sys.getdefaulterrorhandler() in more places. I don't think that it would be correct to use in for str.encode() or bytes.decode(). -- components: Unicode files: default_error_handler.patch keywords: patch messages: 241405 nosy: ezio.melotti, haypo, ncoghlan priority: normal severity: normal status: open title: Use surrogateescape error handler by default in open() if the locale is C versions: Python 3.5 Added file: http://bugs.python.org/file39100/default_error_handler.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23993 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23993] Use surrogateescape error handler by default in open() if the locale is C
STINNER Victor added the comment: The patch is a work-in-progress, I didn't have time to run unit tests, and the documentation is not completed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23993 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
