docs July 2019

docs@python.org

20 participants
403 discussions

by Merlin Fisher-Levine

New submission from Merlin Fisher-Levine <merlin.fisherlevine(a)gmail.com>: Dataclasses docs don't mention needing import for @dataclass decorator https://docs.python.org/3/library/dataclasses.html ---------- assignee: docs@python components: Documentation messages: 340510 nosy: docs@python, mfisherlevine priority: normal severity: normal status: open title: Missing import in docs type: enhancement versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36661> _______________________________________

1 week, 3 days

[issue18280] Documentation is too personalized

by Serhiy Storchaka

New submission from Serhiy Storchaka: Some documentation files contain a number of I/my/me. Looks like they grew from personal modules and personal articles. Perhaps the official documentation needs more depersonalized style. Here is full list of such files: Doc/c-api/exceptions.rst Doc/c-api/long.rst Doc/distutils/builtdist.rst Doc/extending/extending.rst Doc/extending/windows.rst Doc/howto/argparse.rst Doc/howto/curses.rst Doc/howto/functional.rst Doc/howto/regex.rst Doc/howto/sockets.rst Doc/howto/urllib2.rst Doc/install/index.rst Doc/library/audioop.rst Doc/library/ctypes.rst Doc/library/doctest.rst Doc/library/heapq.rst Doc/library/numbers.rst Doc/library/ossaudiodev.rst Doc/library/tk.rst Doc/library/unittest.mock-examples.rst Doc/library/unittest.mock.rst Doc/reference/introduction.rst Doc/tutorial/classes.rst The list doesn't include FAQs where it may be appropriate and whatsnew files. Andrew Kuchling recently has fixed Doc/howto/unicode.rst for this issue (as part of issue4153). ---------- assignee: docs@python components: Documentation messages: 191636 nosy: akuchling, docs@python, eric.araujo, ezio.melotti, georg.brandl, serhiy.storchaka priority: normal severity: normal status: open title: Documentation is too personalized versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18280> _______________________________________

1 week, 4 days

[issue37082] Assignment expression operator (walrus) not in built-in help()

by Matthias Bussonnier

New submission from Matthias Bussonnier <bussonniermatthias(a)gmail.com>: Do the following at a Python prompt: ``` >>> help() Welcome to Python 3.8's help utility! [...]SNIP help> symbols Here is a list of the punctuation symbols which Python assigns special meaning to. Enter any symbol to get more help. != + <= __ " += <> ` """ , == b" % - > b' %= -= >= f" & . >> f' &= ... >>= j ' / @ r" ''' // J r' ( //= [ u" ) /= \ u' * : ] | ** < ^ |= **= << ^= ~ *= <<= _ ``` Oh no ! Our favorite `:=` is missing :-( ---------- assignee: docs@python components: Documentation messages: 343813 nosy: docs@python, mbussonn priority: normal severity: normal status: open title: Assignment expression operator (walrus) not in built-in help() versions: Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue37082> _______________________________________

1 week, 6 days

[issue23802] patch: __deepcopy__ memo dict argument usage

by Daniel Shahaf

New submission from Daniel Shahaf: In the 'copy' module documentation, it wasn't fully clear to me how __deepcopy__ implementations should treat the memo dict argument. The attached patch clarifies that __deepcopy__ implementations should treat the memo dict argument as an opaque type. ---------- assignee: docs@python components: Documentation files: opaque.diff keywords: patch messages: 239473 nosy: danielsh, docs@python priority: normal severity: normal status: open title: patch: __deepcopy__ memo dict argument usage type: enhancement Added file: http://bugs.python.org/file38723/opaque.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23802> _______________________________________

4 weeks, 1 day

[issue35786] get_lock() method is not present for Values created using multiprocessing.Manager()

by Lorenzo Persichetti

New submission from Lorenzo Persichetti <lpersichetti(a)gmail.com>: According to the documentation of the multiprocessing.Value() class available here https://docs.python.org/3.6/library/multiprocessing.html#multiprocessing.Va… Operations like += which involve a read and write are not atomic. So if, for instance, you want to atomically increment a shared value it is insufficient to just do counter.value += 1 Assuming the associated lock is recursive (which it is by default) you can instead do with counter.get_lock(): counter.value += 1 What happens is that when running the following snippet import multiprocessing manager = multiprocessing.Manager() value = manager.Value('i', 0) value.get_lock() the result is AttributeError: 'ValueProxy' object has no attribute 'get_lock' ---------- assignee: docs@python components: Documentation, Library (Lib), Windows messages: 334070 nosy: Lorenzo Persichetti, docs@python, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: get_lock() method is not present for Values created using multiprocessing.Manager() versions: Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue35786> _______________________________________

1 month

[issue26205] Inconsistency concerning nested scopes

by Roscoe R.Higgins

New submission from Roscoe R.Higgins: In chapter 9. Classes of the Python3.5 documentation it says: "At any time during execution, there are at least three nested scopes whose namespaces are directly accessible:", followed by a list containing 4 items. Further down a middle scope is mentioned (although mentioned by name). This was confusing for a while. ---------- assignee: docs@python components: Documentation messages: 258941 nosy: Roscoe R. Higgins, docs@python priority: normal severity: normal status: open title: Inconsistency concerning nested scopes type: behavior versions: Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26205> _______________________________________

1 month

[issue28681] About function renaming in the tutorial

by Xue Fuqiao

New submission from Xue Fuqiao: In https://hg.python.org/cpython/file/6fbb7c9d77c6/Doc/tutorial/controlflow.rs… : A function definition introduces the function name in the current symbol table. The value of the function name has a type that is recognized by the interpreter as a user-defined function. This value can be assigned to another name which can then also be used as a function. This serves as a general renaming mechanism Maybe "aliasing" is a better term than "renaming" here, since the original function name can still be used after the "renaming". ---------- assignee: docs@python components: Documentation files: renaming.patch keywords: patch messages: 280683 nosy: docs@python, xfq priority: normal severity: normal status: open title: About function renaming in the tutorial type: enhancement versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45468/renaming.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue28681> _______________________________________

1 month

[issue17576] PyNumber_Index() is not int-subclass friendly

by Barry A. Warsaw

New submission from Barry A. Warsaw: operator.index() is just a thin wrapper around PyNumber_Index(). The documentation for operator.index() claims that it is equivalent to calling obj.__index__() but for subclasses of int, this is not true. In fact, PyNumber_Index() first does (e.g. in Python 3.3) a PyLong_Check() and if that succeeds, the original object is returned *without* doing the moral equivalent in C of calling obj.__index__(). An example: class myint(int): def __index__(self): return int(self) + 1 >>> x = myint(7) >>> x.__index__() 8 >>> from operator import index >>> index(x) 7 The C API documents PyNumber_Index() as: "Returns the o converted to a Python int on success or NULL with a TypeError exception raised on failure." Because this has been the behavior of PyNumber_Index() since at least 2.7 (I didn't check farther back), this probably cannot be classified as a bug deserving to be fixed in the code for older Pythons. It might be worth fixing for Python 3.4, i.e. by moving the index check before the type check. In the meantime, this is probably a documentation bug. The C API implies, but should be clearer that if o is an int subtype (int and long in Python 2), it is returned unchanged. The operator.index() documentation should be amended to describe this behavior for int/long subclasses. A different alternative would be to leave PyNumber_Index() unchanged, but with the doco fix, and to augment operator.index() to do the PyIndex_Check() first, before calling PyNumber_Index(). That's a little more redundant, but would provide the documented behavior without changing the C API. ---------- assignee: docs@python components: Documentation messages: 185522 nosy: barry, docs@python priority: normal severity: normal status: open title: PyNumber_Index() is not int-subclass friendly type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17576> _______________________________________

1 month

[issue31305] 'pydoc -w import' report "no Python documentation found for 'import'"

by Karthikeyan Singaravelan

New submission from Karthikeyan Singaravelan <tir.karthi(a)gmail.com>: > Run "pydoc -w <name>" to write out the HTML documentation for a module to a file named "<name>.html". As mentioned in the help this works only for modules and since import is a keyword it throws an error. Maybe this could be added as an enhancement? Thanks ---------- nosy: +xtreak _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue31305> _______________________________________

1 month

[issue21333] Document recommended exception for objects that shouldn't be pickled

by Stefan Schwarzer

New submission from Stefan Schwarzer: I recently was confused whether to raise a `PicklingError` or `TypeError` in `__getstate__` if objects of my class can't and shouldn't be pickled. [1] Terry Reedy advised I should use `TypeError`. [2] I wonder if the `pickle` module documention should explicitly recommend using `TypeError` if a class wants to say that its objects can't be pickled. What do you think? [1] https://mail.python.org/pipermail/python-list/2014-April/670987.html [2] https://mail.python.org/pipermail/python-list/2014-April/671002.html ---------- assignee: docs@python components: Documentation messages: 217054 nosy: docs@python, sschwarzer priority: normal severity: normal status: open title: Document recommended exception for objects that shouldn't be pickled type: enhancement versions: Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue21333> _______________________________________

1 month

Jump to page:

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

docs July 2019