[issue23081] Document PySequence_List(o) as equivalent to list(o)
New submission from Lars Buitinck:
PySequence_List has accepted iterables since changeset 6c82277e77f3 of May 1,
2001 ("NEEDS DOC CHANGES" :), but its documentation still only speaks of
sequences. I suggest that it is changed to promise to handle arbitrary
iterables, just like PySequence_Tuple.
--
assignee: docs@python
components: Documentation
files: PySequence_List-doc.patch
keywords: patch
messages: 232875
nosy: docs@python, larsmans
priority: normal
severity: normal
status: open
title: Document PySequence_List(o) as equivalent to list(o)
versions: Python 3.5
Added file: http://bugs.python.org/file37493/PySequence_List-doc.patch
___
Python tracker
<http://bugs.python.org/issue23081>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22565] missing const in declaration of PyErr_WarnEx in C-API docs
New submission from Lars Buitinck: The declaration for PyErr_WarnEx in Doc/c-api/exceptions.rst is missing a const compared to Include/warnings.h. -- assignee: docs@python components: Documentation files: pyerr_warnex_const.patch keywords: patch messages: 228657 nosy: docs@python, larsmans priority: normal severity: normal status: open title: missing const in declaration of PyErr_WarnEx in C-API docs versions: Python 3.5 Added file: http://bugs.python.org/file36824/pyerr_warnex_const.patch ___ Python tracker <http://bugs.python.org/issue22565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18999] Support different contexts in multiprocessing
Lars Buitinck added the comment: I also tried from multiprocessing.pool import Pool but that died with ImportError: cannot import name get_context -- ___ Python tracker <http://bugs.python.org/issue18999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18999] Support different contexts in multiprocessing
Lars Buitinck added the comment:
Strange, I can't actually get it to work:
>>> from multiprocessing import Pool, get_context
>>> forkserver = get_context('forkserver')
>>> Pool(context=forkserver)
Traceback (most recent call last):
File "", line 1, in
TypeError: Pool() got an unexpected keyword argument 'context'
--
___
Python tracker
<http://bugs.python.org/issue18999>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18999] Support different contexts in multiprocessing
Lars Buitinck added the comment: Thanks, much better than my solution! -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue18999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18999] Robustness issues in multiprocessing.{get, set}_start_method
Lars Buitinck added the comment: Ok, great. -- ___ Python tracker <http://bugs.python.org/issue18999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18999] Robustness issues in multiprocessing.{get, set}_start_method
Lars Buitinck added the comment: > BTW, the context objects are singletons. I haven't read all of your patch yet, but does this mean a forkserver will be started regardless of whether it is later used? That would be a good thing, since starting the fork server after reading in large data sets would mean the fork server would hold on to large swaths of memory even when the data set is deallocated in the master process. -- ___ Python tracker <http://bugs.python.org/issue18999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18999] Robustness issues in multiprocessing.{get, set}_start_method
Lars Buitinck added the comment: Ok. Do you (or jnoller?) have time to review my proposed patch, at least before 3.4 is released? I didn't see it in the release schedule, so it's probably not planned soon, but I wouldn't want the API to change *again* in 3.5. -- ___ Python tracker <http://bugs.python.org/issue18999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18999] Robustness issues in multiprocessing.{get, set}_start_method
Lars Buitinck added the comment: I don't really see the benefit of a context manager over an argument. It's a power user feature anyway, and context managers (at least to me) signal cleanup actions, rather than construction options. -- ___ Python tracker <http://bugs.python.org/issue18999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18999] Robustness issues in multiprocessing.{get, set}_start_method
Changes by Lars Buitinck : -- nosy: +jnoller ___ Python tracker <http://bugs.python.org/issue18999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18999] Robustness issues in multiprocessing.{get, set}_start_method
Lars Buitinck added the comment: In my patched version, the private popen.get_start_method gets a kwarg set_if_needed=True. popen.Popen calls that as before, so its behavior should not change, while the public get_start_method sets the kwarg to False. I realise now that this has the side effect that get_start_method's output changes when multiprocessing has first been used, but then that reflects how the library works. Maybe this should be documented. As for the contexts, those would be great. -- ___ Python tracker <http://bugs.python.org/issue18999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18999] Robustness issues in multiprocessing.{get, set}_start_method
Lars Buitinck added the comment: Cleaned up the patch. -- Added file: http://bugs.python.org/file31722/mp_getset_start_method.patch ___ Python tracker <http://bugs.python.org/issue18999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18999] Robustness issues in multiprocessing.{get, set}_start_method
Changes by Lars Buitinck : Removed file: http://bugs.python.org/file31721/mp_getset_start_method.patch ___ Python tracker <http://bugs.python.org/issue18999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18999] Allow multiple calls to multiprocessing.set_start_method
Changes by Lars Buitinck : -- nosy: +sbt ___ Python tracker <http://bugs.python.org/issue18999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18999] Robustness issues in multiprocessing.{get, set}_start_method
Changes by Lars Buitinck :
--
title: Allow multiple calls to multiprocessing.set_start_method -> Robustness
issues in multiprocessing.{get,set}_start_method
___
Python tracker
<http://bugs.python.org/issue18999>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18999] Allow multiple calls to multiprocessing.set_start_method
New submission from Lars Buitinck:
The new multiprocessing based on forkserver (issue8713) looks great, but it has
two problems. The first:
"set_start_method() should not be used more than once in the program."
The documentation does not explain what the effect of calling it twice would
be. Judging from the documentation, it should be possible to do
start_method = get_start_method()
if start_method is None:
set_start_method('forkserver')
but this code shows the second problem: it always succeeds with the
(undocumented!) side-effect of setting the start method in get_start_method, to
the system default, if it hasn't been set already.
I was just going to forge a patch for joblib (http://pythonhosted.org/joblib/)
to set the start method to forkserver at import time. But in the current state
of affairs, it would be impossible for the user to safely override the start
method before importing joblib, because joblib can't figure out if it's been
set already without setting it.
The enclosed patch solves the problem by making the new functions more robust:
* get_start_method no longer sets anything, but returns None if the start
method has not been set already;
* set_start_method raises a RuntimeError (for want of a better exception type)
when resetting the start method is attempted.
Unfortunately, I had to hack up the tests a bit, because they were violating
the set_start_method contract. There is a test for the new set_start_method
behavior, though, and all {fork,forkserver,spawn} tests pass on Linux.
--
components: Library (Lib)
files: mp_getset_start_method.patch
keywords: patch
messages: 197444
nosy: larsmans
priority: normal
severity: normal
status: open
title: Allow multiple calls to multiprocessing.set_start_method
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31721/mp_getset_start_method.patch
___
Python tracker
<http://bugs.python.org/issue18999>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9369] const char* for PyObject_CallMethod and PyObject_CallFunction
Lars Buitinck added the comment: I'm sorry, I really don't understand this refcounts.dat file and I'm not going to hack it further. Does the patch as it currently stands solve the issue with CallMethod and CallFunction, or not? (It has the changes to the docs.) -- ___ Python tracker <http://bugs.python.org/issue9369> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9369] const char* for PyObject_CallMethod and PyObject_CallFunction
Lars Buitinck added the comment: Oops, forgot to save changes to Doc/c-api/object.rst. PyObject_CallMethodObjArgs takes a PyObject*, mustn't that be non-const for reference counting to work? PyDict_GetItemString already has const, just not in refcounts.dat. Fixed. -- Added file: http://bugs.python.org/file28656/constness.patch ___ Python tracker <http://bugs.python.org/issue9369> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9369] const char* for PyObject_CallMethod and PyObject_CallFunction
Lars Buitinck added the comment: Redid the patch. -- Added file: http://bugs.python.org/file28653/constness.patch ___ Python tracker <http://bugs.python.org/issue9369> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9369] const char* for PyObject_CallMethod and PyObject_CallFunction
Lars Buitinck added the comment: Any reason why this issue is still open? I just got a lot of compiler warnings when building Numpy, so this isn't just relevant to C++ programmers. (Btw., I did RTFM: the issue's Resolution is "accepted" but that option is not documented.) -- nosy: +larsmans ___ Python tracker <http://bugs.python.org/issue9369> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16052] Typo in "What's new in 3.3"
Lars Buitinck added the comment: Sorry about the bundle, I'm an hg noob and only noticed that bundles are binary after I submitted it. Will create a regular patch next time. -- ___ Python tracker <http://bugs.python.org/issue16052> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16052] Typo in "What's new in 3.3"
New submission from Lars Buitinck: I spotted a minor typo in the "What's new" for Py 3.3, introduced yesterday. See attached patch. -- assignee: docs@python components: Documentation files: typo.hg messages: 171333 nosy: docs@python, larsmans priority: normal severity: normal status: open title: Typo in "What's new in 3.3" versions: Python 3.3 Added file: http://bugs.python.org/file27312/typo.hg ___ Python tracker <http://bugs.python.org/issue16052> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14968] Section "Inplace Operators" of :mod:`operator` should be a subsection
New submission from Lars Buitinck : The section "Inplace Operators" of the module docs for operator now show up in TOC at http://docs.python.org/dev/library/. I don't think that's intended as it does not describe a separate module. -- assignee: docs@python components: Documentation files: operator-module-docs.patch keywords: patch messages: 161996 nosy: docs@python, larsmans priority: normal severity: normal status: open title: Section "Inplace Operators" of :mod:`operator` should be a subsection type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25772/operator-module-docs.patch ___ Python tracker <http://bugs.python.org/issue14968> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13121] collections.Counter's += copies the entire object
Lars Buitinck added the comment: If this is not implemented because it is backwards incompat, then it might be useful to add a note to update's docstring explaining that it is much more efficient than +=. I was very surprised that it took *minutes* to add a few thousand moderate-sized Counters. -- ___ Python tracker <http://bugs.python.org/issue13121> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13121] collections.Counter's += copies the entire object
New submission from Lars Buitinck : I've found some counterintuitive behavior in collections.Counter while hacking on the scikit-learn project [1]. I wanted to use a bunch of Counters to do some simple term counting in a set of documents, roughly as follows: count_total = Counter() for doc in documents: count_current = Counter(analyze(doc)) count_total += count_current count_per_doc.append(count_current) Performance was horrible. After some digging, I found out that Counter [2] does not have __iadd__ and += copies the entire left-hand side in __add__. I've attached a patch that fixes the issue (for += only, and I've not patched the testsuite.) [1] https://github.com/scikit-learn/scikit-learn/commit/de6e93094499e4d81b8e3b15fc66b6b9252945af -- components: Library (Lib) files: cpython-counter-iadd.diff keywords: patch messages: 145063 nosy: larsmans priority: normal severity: normal status: open title: collections.Counter's += copies the entire object type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file23336/cpython-counter-iadd.diff ___ Python tracker <http://bugs.python.org/issue13121> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
