Mailman 3 May 2019 - docs

[issue37105] Add deprecated-remove information on stream doc
by Emmanuel Arias Oct. 20, 2020

Oct. 20, 2020

New submission from Emmanuel Arias <emmanuelarias30(a)gmail.com>: According to the code on streams.py the functions: open_connection(), start_server(), open_unix_connection(), start_unix_server() are deprecated. I inform that on documentation. ---------- assignee: docs@python components: Documentation messages: 344015 nosy: docs@python, eamanu priority: normal severity: normal status: open title: Add deprecated-remove information on stream doc type: enhancement versions: Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue37105> _______________________________________

4 8

[issue30612] Unusual Windows registry path syntax
by Christian Ullrich Oct. 20, 2020

Oct. 20, 2020

New submission from Christian Ullrich: In 3.6.1, the manual, section 3.1.3, has this to say: "Your administrator will need to activate the “Enable Win32 long paths” group policy, or set the registry value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem@LongPathsEnabled to 1." Separating a value name from the key path with an @-sign, which is what the above is doing, is something I have never before seen anywhere. I suggest changing it by either: - replacing the instructions for the manual change with a link to <https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).…> or a more suitable reference (I could not find a KB article when I looked) - rewording it as, e.g., ... in the registry key HKEY_...FileSystem, set the REG_DWORD value LongPathsEnabled to 1 The value type could be left out; the value is predefined on all platforms where it will be effective. ---------- assignee: docs@python components: Documentation messages: 295505 nosy: Christian.Ullrich, docs@python priority: normal severity: normal status: open title: Unusual Windows registry path syntax type: enhancement versions: Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue30612> _______________________________________

6 12

[issue33592] Document contextvars C API
by Elvis Pranskevichus Oct. 20, 2020

Oct. 20, 2020

New submission from Elvis Pranskevichus <elvis(a)magic.io>: The C API for PEP 567 is currently missing. ---------- assignee: docs@python components: Documentation messages: 317244 nosy: Elvis.Pranskevichus, docs@python, yselivanov priority: normal severity: normal status: open title: Document contextvars C API type: enhancement versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue33592> _______________________________________

5 7

[issue29986] Documentation recommends raising TypeError from tp_richcompare
by Devin Jeanpierre Oct. 20, 2020

Oct. 20, 2020

New submission from Devin Jeanpierre: am not sure when TypeError is the right choice. Definitely, most of the time I've seen it done, it causes trouble, and NotImplemented usually does something better. For example, see the work in https://bugs.python.org/issue8743 to get set to interoperate correctly with other set-like classes --- a problem caused by the use of TypeError instead of returning NotImplemented (e.g. https://hg.python.org/cpython/rev/3615cdb3b86d). This advice seems to conflict with the usual and expected behavior of objects from Python: e.g. object().__lt__(1) returns NotImplemented rather than raising TypeError, despite < not "making sense" for object. Similarly for file objects and other uncomparable classes. Even complex numbers only return NotImplemented! >>> 1j.__lt__(1j) NotImplemented If this note should be kept, this section could use a decent explanation of the difference between "undefined" (should return NotImplemented) and "nonsensical" (should apparently raise TypeError). Perhaps a reference to an example from the stdlib. ---------- assignee: docs@python components: Documentation messages: 291144 nosy: Devin Jeanpierre, docs@python priority: normal pull_requests: 1167 severity: normal status: open title: Documentation recommends raising TypeError from tp_richcompare _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29986> _______________________________________

6 10

[issue36568] Typo in socket.CAN_RAW_FD_FRAMES library documentation
by Carl Cerecke Oct. 20, 2020

Oct. 20, 2020

New submission from Carl Cerecke <carl(a)free.org.nz>: https://docs.python.org/3/library/socket.html#socket.CAN_RAW_FD_FRAMES The wording "...however, you one must accept..." doesn't make sense. I think the "you one" should be "your application", but I'm not sure. ---------- assignee: docs@python components: Documentation messages: 339691 nosy: Carl Cerecke, docs@python priority: normal severity: normal status: open title: Typo in socket.CAN_RAW_FD_FRAMES library documentation versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36568> _______________________________________

3 4

[issue35525] Incorrect keyword name in NNTP.starttls() documentation
by Colin McPhail Oct. 16, 2020

Oct. 16, 2020

New submission from Colin McPhail <colin.mcphail(a)mac.com>: The library documentation for nntplib.NNTP.starttls() says that it takes a keyword parameter called ssl_context. The source code referenced via the link at the top of the nntplib documentation shows the keyword is actually called context. The result is a TypeError if the documented name is used: TypeError: starttls() got an unexpected keyword argument 'ssl_context' ---------- assignee: docs@python components: Documentation messages: 332066 nosy: cmcp22, docs@python priority: normal severity: normal status: open title: Incorrect keyword name in NNTP.starttls() documentation versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue35525> _______________________________________

6 20

[issue35155] Clarify Protocol Handlers in urllib.request Docs
by Denton Liu Oct. 12, 2020

Oct. 12, 2020

New submission from Denton Liu <liu.denton(a)gmail.com>: The urllib.request documentation that they can add their own protocol handlers, however they are unclear on how they should be named. We should replace instances of things like protocol_request with <protocol>_request to make it clear that we are literally replacing "protocol" with the literal protocol. I am creating this issue because I had to actually read the urllib.request source code in order to figure out how to use the protocol handler APIs. ---------- assignee: docs@python components: Documentation messages: 329210 nosy: Denton-L, docs@python priority: normal severity: normal status: open title: Clarify Protocol Handlers in urllib.request Docs type: enhancement 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/issue35155> _______________________________________

7 20

[issue27635] pickle documentation says that unpickling may not call __new__
by July Tikhonov Oct. 11, 2020

Oct. 11, 2020

New submission from July Tikhonov: A note just below object.__setstate__() documentation https://docs.python.org/3.6/library/pickle.html#object.__setstate__ says that """ … the type should implement __getnewargs__() or __getnewargs_ex__() to establish such an invariant; otherwise, neither __new__() nor __init__() will be called. """ I believe that note about not calling __new__() was relevant in python2. I could not find case in python3 in which __new__() would not be called. And __init__() is not called anyway, as far as I understand (unless explicitly by __setstate__() or something). Python 3.6.0a3+ (default:da9898e7e90d, Jul 27 2016, 19:51:12) [GCC 4.9.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> class C: ... def __getstate__(self): return {'foo' : self.foo} ... def __setstate__(self, state): self.foo = state['foo'] ... def __new__(cls): ... print('__new__ is called'); return super().__new__(cls) ... def __init__(self): ... print('__init__ is called'); self.foo = None; super().__init__() ... >>> c = C(); c.foo = 'bar' __new__ is called __init__ is called >>> import pickle >>> c2 = pickle.loads(pickle.dumps(c)) __new__ is called >>> c2.foo 'bar' ---------- assignee: docs@python components: Documentation messages: 271465 nosy: docs@python, july priority: normal severity: normal status: open title: pickle documentation says that unpickling may not call __new__ versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue27635> _______________________________________

6 11

[issue26964] Incorrect documentation for `-u`-flag
by Olav Morken Oct. 11, 2020

Oct. 11, 2020

New submission from Olav Morken: The documentation for the `-u`-flag (https://docs.python.org/3/using/cmdline.html#cmdoption-u) contains: > The text I/O layer will still be line-buffered if writing to the console, or block-buffered if redirected to a non-interactive file. This does not appear to be the case -- instead it is always line-buffered: https://hg.python.org/cpython/file/v3.5.1/Python/pylifecycle.c#l1041 Attached is a trivial patch that simply removes everything after "line-buffered". ---------- assignee: docs@python components: Documentation files: fix-doc-unbuffered.patch keywords: patch messages: 264910 nosy: docs@python, olavmrk priority: normal severity: normal status: open title: Incorrect documentation for `-u`-flag Added file: http://bugs.python.org/file42736/fix-doc-unbuffered.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26964> _______________________________________

4 3

[issue23984] Documentation error: Descriptors
by bjonnh Oct. 8, 2020

Oct. 8, 2020

New submission from bjonnh: in https://docs.python.org/3.5/howto/descriptor.html#static-methods-and-class-… (same problem in all python 3.x documentations) There is this example where the return of f function is printed and there is already a print in the function: """ >>> class E(object): def f(x): print(x) f = staticmethod(f) >>> print(E.f(3)) 3 >>> print(E().f(3)) 3 """ It should probably be: """ def f(x): return(x) """ or """ >> E.f(3) 3 >> E().f(3) """ ---------- assignee: docs@python components: Documentation messages: 241312 nosy: bjonnh, docs@python priority: normal severity: normal status: open title: Documentation error: Descriptors type: enhancement versions: 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/issue23984> _______________________________________

8 13