docs

docs@python.org

10 participants
15344 discussions

[issue42996] hashlib documentation references an obsolete RFC 2898

by Illia Volochii

New submission from Illia Volochii <illia.volochii(a)gmail.com>: RFC 2898 mentioned in the "See also" section of hashlib documentation was superseded by RFC 8018. https://docs.python.org/3/library/hashlib.html https://www.ietf.org/rfc/rfc8018.txt ---------- assignee: docs@python components: Documentation messages: 385457 nosy: docs@python, illia-v priority: normal severity: normal status: open title: hashlib documentation references an obsolete RFC 2898 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42996> _______________________________________

4 hours, 48 minutes

[issue42982] Update suggested number of iterations for pbkdf2_hmac()

by Illia Volochii

New submission from Illia Volochii <illia.volochii(a)gmail.com>: Documentation [1] suggests using at least 100,000 iterations of SHA-256 as of 2013. Currently, it is 2021, and it is common to use much more iterations. For example, Django will use 260,000 by default in the next 3.2 LTS release and 320,000 in 4.0 [2][3]. I suggest suggesting at least 250,000 iterations that is a somewhat round number close to the one used by modern libraries. [1] https://docs.python.org/3/library/hashlib.html#hashlib.pbkdf2_hmac [2] https://github.com/django/django/commit/f2187a227f7a3c80282658e699ae9b04023… [3] https://github.com/django/django/commit/a948d9df394aafded78d72b1daa785a0abf… ---------- assignee: docs@python components: Documentation messages: 385365 nosy: docs@python, illia-v priority: normal severity: normal status: open title: Update suggested number of iterations for pbkdf2_hmac() _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42982> _______________________________________

5 hours, 41 minutes

[issue42993] doc xml.etree.ElementTree.ElementTree.write does not mention attribute order

by Christian Buhtz

New submission from Christian Buhtz <c.buhtz(a)posteo.jp>: The docs for 'xml.etree.ElementTree.ElementTree.write' in Python 3.7 (and possible earlier) does not say a word about the ordering of the attributes. This makes unittesting hard. But looking in the code tells me that the attributes are ordered lexically. Important to know. So please upgrade the docu about that. In Python 3.8 the ordering behavior changed again but is mentioned in the docu. So no need to change in 3.8 or later. ---------- assignee: docs@python components: Documentation messages: 385448 nosy: buhtz, docs@python priority: normal severity: normal status: open title: doc xml.etree.ElementTree.ElementTree.write does not mention attribute order type: enhancement versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42993> _______________________________________

7 hours, 7 minutes

[issue36769] doc Document that fnmatch.filter supports any kind of iterable not just lists

by Andrés Delfino

New submission from Andrés Delfino <adelfino(a)gmail.com>: Documentation on fnmatch.filter says: Return the subset of the list of names that match pattern. It is the same as [n for n in names if fnmatch(n, pattern)], but implemented more efficiently. But the function actual accepts any kind of iterable. I think it should be documented. ---------- assignee: docs@python components: Documentation messages: 341198 nosy: adelfino, docs@python priority: normal severity: normal status: open title: doc Document that fnmatch.filter supports any kind of iterable not just lists type: enhancement versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36769> _______________________________________

1 day, 12 hours

[issue14191] argparse doesn't allow optionals within positionals

by Tadek Kijkowski

Change by Tadek Kijkowski <tkijkowski(a)gmail.com>: ---------- nosy: +monkeyman79 nosy_count: 9.0 -> 10.0 pull_requests: +23084 pull_request: https://github.com/python/cpython/pull/24259 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue14191> _______________________________________

2 days, 5 hours

asyncio doc bug

by Bas Terwijn

Hello, Here: https://docs.python.org/dev/library/asyncio-task.html It says: task1 = asyncio.create_task( say_after(1, 'hello')) task2 = asyncio.create_task( say_after(2, 'world')) but I think it should be (flipped arguments): task1 = asyncio.create_task( say_after('hello', 1 )) task2 = asyncio.create_task( say_after('world', 2 )) Thanks for the docs. Regards, Bas Terwijn

2 days, 9 hours

[issue42948] bytearray.copy is undocumented

by wim glenn

New submission from wim glenn <wim.glenn(a)gmail.com>: bytearray type has a copy method which seems to be undocumented https://docs.python.org/3/library/stdtypes.html#bytes-and-bytearray-operati… ---------- assignee: docs@python components: Documentation messages: 385164 nosy: docs@python, wim.glenn priority: normal severity: normal status: open title: bytearray.copy is undocumented type: enhancement versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42948> _______________________________________

4 days, 8 hours

[issue42705] Intercepting thread lock objects not working under context managers

by Mohamad Kanj

New submission from Mohamad Kanj <mhmd.kanj(a)gmail.com>: The interception of Python and C functions is achieved through the `sys` module - however, when using thread locks from `threading` module for instance under context managers, the calls on the lock to `acquire()` and `release()` cannot be witnessed. If these methods were to be called explicitly then this is no problem. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42705> _______________________________________

4 days, 15 hours

[issue42945] weakref.finalize documentation contradicts itself RE: finalizer callback or args referencing object

by Ryan Heisler

New submission from Ryan Heisler <ryan.a.heisler(a)gmail.com>: In the documentation for `weakref.finalize` (https://docs.python.org/3.9/library/weakref.html#weakref.finalize), it says: "Note It is important to ensure that func, args and kwargs do not own any references to obj, either directly or indirectly, since otherwise obj will never be garbage collected. In particular, func should not be a bound method of obj." However, at the bottom of the document, in the section called "Comparing finalizers with __del__() methods" (https://docs.python.org/3.8/library/weakref.html#comparing-finalizers-with-…), the following code is part of an example of how to use `weakref.finalize`: class TempDir: def __init__(self): self.name = tempfile.mkdtemp() self._finalizer = weakref.finalize(self, shutil.rmtree, self.name) I believe this code violates the rule that func, args, and kwargs should not have a reference to obj. In the example, obj is the instance of TempDir, and one of the arguments to finalize's callback is an attribute of the same instance of TempDir. I do not know how to fix this example code. I found it while trying to figure out how to use `weakref.finalize`. ---------- assignee: docs@python components: Documentation messages: 385155 nosy: docs@python, ryan.a.heisler priority: normal severity: normal status: open title: weakref.finalize documentation contradicts itself RE: finalizer callback or args referencing object versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42945> _______________________________________

4 days, 23 hours

Bug?

by Mrigank Shekhar

As per 4.7.7. Documentation Strings: Here are some conventions about the content and formatting of documentation strings. The first line should always be a short, concise summary of the object’s purpose. For brevity, it should not explicitly state the object’s name or type, since these are available by other means (except if the name happens to be a verb describing a function’s operation). This line should begin with a capital letter and *end with a period*. The below code is missing *end with a period *in the docstring. Bug? URL: https://docs.python.org/3/tutorial/classes.html#class-objects class MyClass: """A simple example class""" i = 12345 def f(self): return 'hello world'

6 days, 11 hours

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

docs