Mailman 3 September 2018 - docs

[issue29986] Documentation recommends raising TypeError from tp_richcompare
by Devin Jeanpierre 20 Oct '20

20 Oct '20

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

[issue27635] pickle documentation says that unpickling may not call __new__
by July Tikhonov 11 Oct '20

11 Oct '20

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 11 Oct '20

11 Oct '20

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 08 Oct '20

08 Oct '20

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

[issue34552] Clarify built-in types comparisons
by Windson Yang 08 Oct '20

08 Oct '20

New submission from Windson Yang <wiwindson(a)gmail.com>: In https://docs.python.org/3.5/library/stdtypes.html#comparisons "some types (for example, function objects) support only a degenerate notion of comparison where any two objects of that type are unequal." We had some discussion at zulipchat already: "more seriously: I think we can just delete that sentence. The next sentence makes clear that < and friends arne't always defined, and the sentence after that notes that == defaults to is if there's nothing better." - by Nathaniel J. Smith IMO, I think we should also clarify the relationship between "==", "is" and "__eq__". ---------- assignee: docs@python components: Documentation messages: 324403 nosy: Windson Yang, docs@python, gvanrossum, njs, zach.ware priority: normal severity: normal status: open title: Clarify built-in types comparisons type: enhancement versions: Python 2.7, 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/issue34552> _______________________________________

4 4

[issue30578] Misleading example in sys.set_coroutine_wrapper docs
by Nick Coghlan 05 Oct '20

05 Oct '20

New submission from Nick Coghlan: In issue 24342, the invocation of coroutine wrappers specified via sys.set_coroutine_wrapper was fixed to catch and report the case of infinite recursion, where the wrapper attempts to instantiate a nested coroutine (which would call the wrapper, which would attempt to instantiate the coroutine, etc, etc) The docs for sys.set_coroutine_wrapper include an example of this failure case: https://docs.python.org/3/library/sys.html#sys.set_coroutine_wrapper However, if you're not reading carefully, it looks like an example of how to *use* sys.set_coroutine_wrapper, rather than an example of a case that won't work. It would be better to include an example that either doesn't wrap the coroutine at all, or else uses one of the non-native coroutine emulations to avoid the infinite recursion problem: ``` import asyncio, sys def wrapper(coro): @asyncio.coroutine def wrap(coro): print("Coroutine started") result = yield from coro print("Coroutine finished") return result return wrap(coro) sys.set_coroutine_wrapper(wrapper) async def foo(): print("Coroutine running") return "Coroutine result" import asyncio asyncio.get_event_loop().run_until_complete(foo()) ``` Also related: I discovered in writing this that "sys.set_coroutine_wrapper(None)" doesn't actually turn off coroutine wrapping. Instead, you still get this exception when attempting to recursively define an unwrapped one: RuntimeError: coroutine wrapper <NULL> attempted to recursively wrap <code object wrap at 0x7eff31fbde40, file "<stdin>", line 2>) That error was produced as follows: ``` import sys, contextlib @contextlib.contextmanager def disable_coroutine_wrapping(): wrapper = sys.get_coroutine_wrapper() sys.set_coroutine_wrapper(None) try: yield finally: sys.set_coroutine_wrapper(wrapper) def wrapper(coro): async def wrap(coro): print("Coroutine started") result = await coro print("Coroutine finished") return result with disable_coroutine_wrapping(): return wrap(coro) sys.set_coroutine_wrapper(wrapper) async def foo(): print("Coroutine running") return "Coroutine result" import asyncio asyncio.get_event_loop().run_until_complete(foo()) ``` ---------- assignee: docs@python components: Documentation messages: 295231 nosy: docs@python, giampaolo.rodola, haypo, ncoghlan, yselivanov priority: normal severity: normal stage: needs patch status: open title: Misleading example in sys.set_coroutine_wrapper docs type: enhancement versions: Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue30578> _______________________________________

3 2

[issue33235] Better help text for dict.setdefault
by Paddy McCarthy 03 Oct '20

03 Oct '20

New submission from Paddy McCarthy <paddy3118(a)gmail.com>: Hi, I was answering some question and used dict.setdefault as part of the solution and posted the help() on it as part of my answer. The help was this: In [15]: help(mapper.setdefault) Help on built-in function setdefault: setdefault(...) method of builtins.dict instance D.setdefault(k[,d]) -> D.get(k,d), also set D[k]=d if k not in D This seems the wrong way around. Is it not better expressed as D.setdefault(k[,d]) -> set D[k]=d if k not in D and then D.get(k,d) ---------- assignee: docs@python components: Documentation messages: 315015 nosy: Paddy McCarthy, docs@python priority: normal severity: normal status: open title: Better help text for dict.setdefault type: enhancement versions: Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue33235> _______________________________________

5 5

[issue29127] Incorrect reference names in asyncio.subprocess documentation
by Eric Ahn 02 Oct '20

02 Oct '20

New submission from Eric Ahn: On this page of the documentation https://docs.python.org/3/library/asyncio-subprocess.html it seems that some of the reference names are incorrect. Namely, asyncio.subprocess.PIPE is referred to as asyncio.asyncio.subprocess.PIPE (along with STDOUT and DEVNULL), plus asyncio.subprocess.Process is referred to as asyncio.asyncio.subprocess.Process. This is reflected in the permalinks as well as when one tries to reference these via intersphinx (which is how I discovered it; I was trying to link to this page and was failing). ---------- assignee: docs@python components: Documentation messages: 284418 nosy: Eric Ahn, docs@python priority: normal severity: normal status: open title: Incorrect reference names in asyncio.subprocess documentation versions: Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29127> _______________________________________

3 2

[issue24757] Installing Py on Windows: Need to restart or logout for path to be added
by John Palermo 24 Sep '20

24 Sep '20

New submission from John Palermo: Something I suppose many new users could stumble over: After installing Python and trying out "pip" or "python" on the command line nothing is found. You have to re-start Windows or re-log into your account. I suggest adding this information to the documentation here https://docs.python.org/2/using/windows.html#installing-python and also adding it to the Windows installer description for the "add Python to your path" option. ---------- assignee: docs@python components: Documentation messages: 247688 nosy: John Palermo, docs@python priority: normal severity: normal status: open title: Installing Py on Windows: Need to restart or logout for path to be added type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue24757> _______________________________________

6 6

[issue18280] Documentation is too personalized
by Serhiy Storchaka 19 Sep '20

19 Sep '20

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> _______________________________________

11 17