docs November 2017

docs@python.org

17 participants
533 discussions

[issue22167] iglob() has misleading documentation (does indeed store names internally)

by Roy Smith

New submission from Roy Smith: For background, see: https://mail.python.org/pipermail/python-list/2014-August/676291.html In a nutshell, the iglob() docs say, "Return an iterator which yields the same values as glob() without actually storing them all simultaneously." The problem is, internally, it calls os.listdir(), which apparently *does* store the entire list internally, defeating the whole purpose of iglob() I recognize that iglob() is not going to get fixed in 2.7, but at least the documentation should be updated to point out that it doesn't really do what it says it does. Or rather, it doesn't really not do what it says it doesn't :-) ---------- assignee: docs@python components: Documentation messages: 225048 nosy: docs@python, roysmith priority: normal severity: normal status: open title: iglob() has misleading documentation (does indeed store names internally) type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22167> _______________________________________

8 months, 2 weeks

[issue23750] Clarify difference between os.system/subprocess.call in section "Replacing os.system()"

by Andreas Sommer

New submission from Andreas Sommer: Reading over the section "Replacing os.system()" (https://docs.python.org/2/library/subprocess.html#replacing-os-system), one might assume that the return value of os.system and subprocess.call are equivalent. status = os.system("mycmd" + " myarg") # becomes status = subprocess.call("mycmd" + " myarg", shell=True) However, they are not. Example: import sys import os import subprocess print subprocess.call("false") print os.system("false") gives 1 and 256, respectively. Maybe this could be rephrased for clarity, or a hint added. ---------- assignee: docs@python components: Documentation messages: 239028 nosy: Andreas Sommer, docs@python priority: normal severity: normal status: open title: Clarify difference between os.system/subprocess.call in section "Replacing os.system()" type: enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23750> _______________________________________

8 months, 3 weeks

[issue24475] The docs never define what a pool "task" is

by Zahari Dim

New submission from Zahari Dim: See: http://stackoverflow.com/questions/30943161/multiprocessing-pool-with-maxta… The documentation never makes clear what a "task" in the context of Pool.map. At best, it says: "This method chops the iterable into a number of chunks which it submits to the process pool as separate tasks. The (approximate) size of these chunks can be specified by setting chunksize to a positive integer." in the map documentation. However it does not say how this chunks are calculated by default, making the maxtasksperchild argument not very useful. The fact that a function evaluated by map is not a "task" should be much clearer in the documentation. Also, in the examples, such as: with multiprocessing.Pool(PROCESSES) as pool: # # Tests # TASKS = [(mul, (i, 7)) for i in range(10)] + \ [(plus, (i, 8)) for i in range(10)] results = [pool.apply_async(calculate, t) for t in TASKS] imap_it = pool.imap(calculatestar, TASKS) imap_unordered_it = pool.imap_unordered(calculatestar, TASKS) TASKS are not actually "tasks" but rather "task groups". ---------- assignee: docs@python components: Documentation messages: 245509 nosy: Zahari.Dim, docs@python priority: normal severity: normal status: open title: The docs never define what a pool "task" is versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue24475> _______________________________________

8 months, 3 weeks

[issue11975] Fix intersphinx-ing of built-in types (list, int, ...)

by Jonas H.

New submission from Jonas H. <jonas(a)lophus.org>: Intersphinx-ing of int, list, float, ... should work with ":class:`int`" (list, float, ...). Also, intersphinx-ing list methods, e.g. ":meth:`list.insert`", should work. ---------- assignee: docs@python components: Documentation messages: 134923 nosy: docs@python, jonash priority: normal severity: normal status: open title: Fix intersphinx-ing of built-in types (list, int, ...) _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11975> _______________________________________

8 months, 3 weeks

[issue20692] Tutorial section 9.4

by Jon Shemitz

New submission from Jon Shemitz: The tutorial says "Each value is an object, and therefore has a class (also called its type). It is stored as object.__class__." So, I tried >>> 3.__class__ File "<stdin>", line 1 3.__class__ ^ SyntaxError: invalid syntax Yet, "foo".__class__ worked, as did 3j.__class__ and 3.5.__class__. When my son (!) suggested that I try (3).__class__, I did indeed get <type 'int'>, while (3,).__class__ gave <type 'tuple'>. This *looks like* a minor error in the parser, where seeing \d+\. puts it in a state where it expects \d+ and it can't handle \w+ This may be the sort of thing that only a newbie would even think to try, so may not be worth fixing. If so, it may be worth mentioning in the tutorial. ---------- assignee: docs@python components: Documentation, Interpreter Core messages: 211670 nosy: Jon.Shemitz, docs@python priority: normal severity: normal status: open title: Tutorial section 9.4 type: behavior versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20692> _______________________________________

8 months, 3 weeks

[issue26629] Need an ability to build standard DLLs with distutils

by Buraddin Ibn-Karlo

New submission from Buraddin Ibn-Karlo: I want to make a a dynamic library to run its function with ctypes. Also I want to build the library from sources with distutils (the C++ sources are distributed with my Python code). But alas! Our distutils fails, if the library doesn't have initialization function (something like init_<module_name>). Even if the module does not need any initialization. I did a quick and dirty solution: added a dummy function: void init_<module_name>(){} It somehow works, but I don't think that it is a good idea. Cannot you add the possibility to tell distutils, that this extention module is just a simple DLL, that will be used via ctypes (or somehow else) and it does not need any extra init script? Also, cannot you add an extra section to ctypes documentation? With a description how to build such extensions via distutils? ---------- assignee: docs@python components: Build, Documentation, Extension Modules, Windows, ctypes messages: 262308 nosy: Buraddin Ibn-Karlo, docs@python, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Need an ability to build standard DLLs with distutils type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26629> _______________________________________

8 months, 3 weeks

[issue31055] All Sphinx generated pages could have a new "Edit This Page" link adjacent to the existing "Show Source"

by Paul Hammant

New submission from Paul Hammant: Show Source links to: https://github.com/python/cpython/blob/path/to/resource.rst Edit This Page would link to https://github.com/python/cpython/edit/path/to/resource.rst And yes, GitHub does the right thing if you're not ordinarily permitted to change python/cpython ---------- assignee: docs@python components: Documentation messages: 299306 nosy: Paul Hammant, docs@python priority: normal severity: normal status: open title: All Sphinx generated pages could have a new "Edit This Page" link adjacent to the existing "Show Source" versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31055> _______________________________________

8 months, 3 weeks

[issue27420] Docs for os.link - say what happens if link already exists

by Niall Mansfield

New submission from Niall Mansfield: In os.link(source, link_name) Change Create a hard link pointing to source named link_name. to Create a hard link pointing to source named link_name. If link_name already exists, OSError is raised. ---------- assignee: docs@python components: Documentation messages: 269572 nosy: docs@python, python-bugs-uit priority: normal severity: normal status: open title: Docs for os.link - say what happens if link already exists type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue27420> _______________________________________

8 months, 3 weeks

[issue16386] imp.find_module does not specify registry key it searches on windows

by Jan Duzinkiewicz

New submission from Jan Duzinkiewicz: quote from http://docs.python.org/3/library/imp.html#imp.find_module: "...on some systems some other places are looked in as well (on Windows, it looks in the registry which may point to a specific file)." I actually didn't know the registry key is listed in "using Python on Window" guide until I grepped for PythonCore (which kind of requires to know the key already) - so I'm submitting a patch that cross references find_module docs and using Python on Windows guide. ---------- assignee: docs@python components: Documentation files: import_nt_reg.patch keywords: patch messages: 174508 nosy: dhgmgn, docs@python priority: normal severity: normal status: open title: imp.find_module does not specify registry key it searches on windows versions: Python 2.7, Python 3.3 Added file: http://bugs.python.org/file27843/import_nt_reg.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16386> _______________________________________

8 months, 3 weeks

[issue11977] Document int.conjugate, .denominator, ...

by Jonas H.

New submission from Jonas H. <jonas(a)lophus.org>: Various `int` attributes and methods seem undocumented (at least it does not work to intersphinx them): * .conjugate * .denominator * .imag * .numerator * .real ---------- assignee: docs@python components: Documentation messages: 134926 nosy: docs@python, jonash priority: normal severity: normal status: open title: Document int.conjugate, .denominator, ... versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11977> _______________________________________

8 months, 4 weeks

Jump to page:

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

docs November 2017