docs November 2019

docs@python.org

12 participants
363 discussions

[issue24650] Error in yield expression documentation

by swanson

New submission from swanson: https://docs.python.org/3/reference/expressions.html in 6.2.9. Yield expressions end of 1st paragraph: "Using a yield expression in a function’s body causes that function to be a generator." NO! As the very next sentence explains, a generator is what's returned by such a function, not the function itself. Basically, it should be sufficient to add the word "function" to the end of that sentence: "... generator function." However, this error does NOT exist in 3.0 to 3.2 - just in 3.3 to 3.6, so I suggest just using the same wording as 3.0 to 3.2: "Using a yield expression in a function definition is sufficient to cause that definition to create a generator function instead of a normal function." ---------- assignee: docs@python components: Documentation messages: 246841 nosy: docs@python, swanson priority: normal severity: normal status: open title: Error in yield expression documentation versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue24650> _______________________________________

5 days, 3 hours

[issue24711] Document getpass.getpass behavior on ^C

by Markus Unterwaditzer

New submission from Markus Unterwaditzer: getpass.getpass doesn't enter a newline when the user aborts input with ^C, while input/raw_input does. This behavior is surprising and can lead to mis-formatting of subsequent output. However, since this behavior exists since 2.7 and applications may have started to rely on it, I'd add a note to the documentation. ---------- assignee: docs@python components: Documentation messages: 247302 nosy: docs@python, untitaker priority: normal severity: normal status: open title: Document getpass.getpass behavior on ^C 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/issue24711> _______________________________________

5 days, 23 hours

[issue34804] Repetition of 'for example' in documentation

by Aydin

New submission from Aydin <bagiyevaydin(a)gmail.com>: In the documentation of Python 3.7.0 there is an error in the usage of the world 'for example'. ---------- assignee: docs@python components: Documentation files: Functional Programming HOWTO — Python 3.7.0 documentation.png messages: 326418 nosy: docs@python, rarblack priority: normal severity: normal status: open title: Repetition of 'for example' in documentation versions: Python 3.7 Added file: https://bugs.python.org/file47825/Functional Programming HOWTO — Python 3.7.0 documentation.png _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue34804> _______________________________________

6 days, 22 hours

[issue38413] Remove or change "Multithreading" section

by Vladimir Ryabtsev

New submission from Vladimir Ryabtsev <greatvovan(a)gmail.com>: This is regarding the page https://docs.python.org/3.7/library/sqlite3.html. I believe this section on the very bottom of the page has been kept here for pretty long time, during that both SQLite and the sqlite3 module evolved and improved. Now the content contradicts to the description of function "connect()" in the part describing "check_same_thread" parameter. The function description says that using connections from multiple threads is allowed with serialization handled by the user (and it is true), while the bottom "Mutithreading" section says sharing connections is not allowed. I think we can remove "Mutithreading" section entirely unless there is something important to add to what already mentioned. ---------- assignee: docs@python components: Documentation messages: 354227 nosy: Vladimir Ryabtsev, docs@python priority: normal severity: normal status: open title: Remove or change "Multithreading" section versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue38413> _______________________________________

1 week, 3 days

[issue34451] docs: tutorial/introduction doesn't mention toggle of prompts

by Jonathan Fine

New submission from Jonathan Fine <jfine2358(a)gmail.com>: Interactive code examples need the prompt to be stripped, before copy-and-paste. This is explained in https://docs.python.org/3/tutorial/introduction.html But this page does not tell us about the [>>>] prompt-toggle at top of each interactive code example. This caused a user error, reported in https://mail.python.org/pipermail/python-ideas/2018-August/052869.html. The [>>>] toggle isn't in the Python 2.7 docs, so nothing to fix there! ---------- assignee: docs@python components: Documentation messages: 323839 nosy: docs@python, jfine2358 priority: normal severity: normal status: open title: docs: tutorial/introduction doesn't mention toggle of prompts versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue34451> _______________________________________

1 week, 4 days

[issue36675] Doctest directives and comments not visible or missing from code samples

by Steven D'Aprano

New submission from Steven D'Aprano <steve+python(a)pearwood.info>: (Apologies if this is the wrong place for reporting website bugs.) The website is not rendering doctest directives or comments, either that or the comments have been stripped from the examples. On the doctest page itself, all the comments are missing: https://docs.python.org/3/library/doctest.html#directives The first example says: >>> print(list(range(20))) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19] but without the directive, the test would fail. Screen shot attached. Doctest directives are also missing from here: https://docs.python.org/3/library/ctypes.html My browser: Firefox 45.1.1 Also checked with text browser "lynx". ---------- assignee: docs@python components: Documentation files: missing_directives.png messages: 340570 nosy: docs@python, steven.daprano priority: normal severity: normal status: open title: Doctest directives and comments not visible or missing from code samples type: behavior Added file: https://bugs.python.org/file48277/missing_directives.png _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36675> _______________________________________

1 week, 5 days

[issue15097] Improving wording on the thread-safeness of import

by Merlijn van Deen

New submission from Merlijn van Deen <valhallasw(a)gmail.com>: http://docs.python.org/library/threading.html#importing-in-threaded-code Currently, the documentation states "Firstly, other than in the main module, an import should not have the side effect of spawning a new thread and then waiting for that thread in any way. Failing to abide by this restriction can lead to a deadlock if the spawned thread directly or indirectly attempts to import a module." which, I think, fails to make the main point: a call to import acquires the import lock. A call to import from a second thread will thus block. As such, I would suggest rephrasing it to something like: "Firstly, an import acquires the import lock for that thread. Therefore, the import should not have the side effect of waiting for a different thread in any way, as this can lead to a deadlock if that thread directly or indirectly attempts to import a module." There are two additional points that might be interesting to note: (1) Any module can be imported. If the import causes a deadlock, that is a bad thing. Every module *will* be imported by tools such as nosetests. (1b) so: never, ever, have code that causes locks in a different thread in module level code witout 'if __name__=="__main__" ' blocks? (2) The lock is also acquired if a module has already been imported. For instance, in import sys # (1) def f(): import sys # (2) the import lock is acquired in (1) /and/ (2). Adding example code and/or a flow diagram might be a bit too much, but it does clarify how easy it is to make this mistake. See the attached for an example (both a simple example script, as well as a flow diagram explaining what happens). ---------- assignee: docs@python components: Documentation files: deadlock.py messages: 163068 nosy: docs@python, valhallasw priority: normal severity: normal status: open title: Improving wording on the thread-safeness of import type: enhancement Added file: http://bugs.python.org/file26037/deadlock.py _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15097> _______________________________________

2 weeks, 3 days

[issue8595] Unexpected default timeout in http-client-related libraries

by Julian

New submission from Julian <python_org(a)somethinkodd.com>: Since Python 2.6, httplib has offered a timeout parameter for fetches. As the documentation explains, if this parameter is not provided, it uses the global default. What the document doesn't explain is httplib builds on top of the socket library. The socket library has a default timeout of None (i.e. forever). This may be an appropriate default for general sockets, but it is a poor default for httplib; typical http clients would use a timeout in the 2-10 second range. This problem is propagated up to urllib2, which sits on httplib, and further obscures that the default might be unsuitable. >From an inspection of the manuals, Python 3.0.1 suffers from the same problem except, the names have changed. urllib.response sits on http.client. I, for one, made a brutal mistake of assuming that the "global default" would be some reasonable default for fetching web pages; I didn't have any specific timeout in mind, and was happy for the library to take care of it. Several million successful http downloads later, my server application thread froze waiting forever when talking to a recalcitrant web-server. I imagine others have fallen for the same trap. While an ideal solution would be for httplib and http.client to use a more generally acceptable default, I can see it might be far too late to make such a change without breaking existing applications. Failing that, I would recommend that the documentation for httplib, urllib, urllib2, http.client and urllib.request (+ any other similar libraries sitting on socket? FTP, SMTP?) be changed to highlight that the default global timeout, sans deliberate override, is to wait a surprisingly long time. ---------- assignee: docs@python components: Documentation, Library (Lib) messages: 104763 nosy: docs@python, oddthinking priority: normal severity: normal status: open title: Unexpected default timeout in http-client-related libraries type: behavior versions: Python 2.6, Python 2.7, Python 3.1 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8595> _______________________________________

2 weeks, 5 days

[issue8822] datetime naive and aware types should have a well-defined definition that can be cross-referenced

by anatoly techtonik

New submission from anatoly techtonik <techtonik(a)gmail.com>: 'naive' and 'aware' are key datetime types - they need a proper definition and anchor for crossrefences. If you take a look at http://docs.python.org/library/datetime.html - the definition of distinction between them is too vague and this seeds of uncertainty grow through the rest of the doc. It is not said how to make non-naive object, how to detect if object of naive or aware. All this stuff is very important for troubleshooting datetims issues in Python projects. It needs a proper documentation. ---------- assignee: docs@python components: Documentation messages: 106524 nosy: docs@python, techtonik priority: normal severity: normal status: open title: datetime naive and aware types should have a well-defined definition that can be cross-referenced _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8822> _______________________________________

2 weeks, 5 days

[issue38649] tkinter messagebox is sloppy

by David Lambert

New submission from David Lambert <b49p23tivg(a)gmail.com>: Does aksokcancel return "true" or True ? The docstring should say True This is pervasive throughout the module. tkinter has such a mishmash of numbers supplied as strings, strings supplied as constants making this carelessness egregious. On the topic of constants, the messagebox module redefines OK. You might argue that the definition didn't change. I suspect this issue applies to all versions of tkinter or Tkinter having the messagebox. # types ABORTRETRYIGNORE = "abortretryignore" OK = "ok" ... # replies ... OK = "ok" def askokcancel(title=None, message=None, **options): "Ask if operation should proceed; return true if the answer is ok" s = _show(title, message, QUESTION, OKCANCEL, **options) return s == OK ---------- assignee: docs@python components: Documentation messages: 355729 nosy: David Lambert, docs@python priority: normal severity: normal status: open title: tkinter messagebox is sloppy type: enhancement versions: Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue38649> _______________________________________

3 weeks, 1 day

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

docs November 2019