docs February 2017

docs@python.org

23 participants
589 discussions

[issue29329] Incorrect documentation for custom `hex()` support on Python 2

by Mariatta Wijaya

Mariatta Wijaya added the comment: Thanks, Pekka, Eryk, Ammar, and Zachary :) ---------- status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29329> _______________________________________

4 years, 7 months

[issue29329] Incorrect documentation for custom `hex()` support on Python 2

by Roundup Robot

Roundup Robot added the comment: New changeset d7804789368a by Mariatta Wijaya in branch '2.7': Issue #29329: Improve documentation for hex(). Patch by Ammar Askar https://hg.python.org/cpython/rev/d7804789368a ---------- nosy: +python-dev _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29329> _______________________________________

4 years, 7 months

[issue29329] Incorrect documentation for custom `hex()` support on Python 2

by Zachary Ware

Zachary Ware added the comment: LGTM. ---------- assignee: docs@python -> Mariatta nosy: +Mariatta, zach.ware stage: needs patch -> commit review _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29329> _______________________________________

4 years, 7 months

[issue29381] Tutorial documentation contains undefined reference

by Jim Fasarakis-Hilliard

New submission from Jim Fasarakis-Hilliard: After moving a certain chunk of the 'interpreter.rst' contents to 'appendix.rst' in issue16827 the reference to #! in the section '2.2.3. Source Code Encoding' is currently confusing for new readers. Attached patches reword the sentence to remove that reference for 3.4+ and 2.7. ---------- assignee: docs@python components: Documentation files: interpreter_tut.patch keywords: patch messages: 286378 nosy: Jim Fasarakis-Hilliard, docs@python priority: normal severity: normal status: open title: Tutorial documentation contains undefined reference versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46438/interpreter_tut.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29381> _______________________________________

4 years, 7 months

[issue29344] sock_recv not detected a coroutine

by Yury Selivanov

Yury Selivanov added the comment: > Maybe we should switch all these to "awaitable"? I like this! Would it be OK to add a new sphinx declaration? So that: .. coroutinemethod:: AbstractEventLoop.shutdown_asyncgens() would become: .. awaitable:: AbstractEventLoop.shutdown_asyncgens() ? > Also note that in proactor_events.py, sock_connect() is *not* a coroutine. Yeah, those small incompatibilities are inevitable for asyncio programs/frameworks -- something that returns a Future may occasionally become a coroutine. Your idea to document API methods as "awaitables" seems to be the right way to go. > In fact I'm not sure what it is -- it calls self._proactor.connect() which appears to return None from the code in windows_events.py. That's presumably a separate bug. It looks like it returns the result of "IocpProactor.connect()" call, which returns an _OverlappedFuture instance (I don't really know Windows part of asyncio code, so I might be missing something). ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29344> _______________________________________

4 years, 7 months

[issue29344] sock_recv not detected a coroutine

by Guido van Rossum

Guido van Rossum added the comment: The word coroutine has a more specific meaning though (and we have iscoroutine*() inspection functions to check for it). Maybe we should switch all these to "awaitable"? Also note that in proactor_events.py, sock_connect() is *not* a coroutine. In fact I'm not sure what it is -- it calls self._proactor.connect() which appears to return None from the code in windows_events.py. That's presumably a separate bug. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29344> _______________________________________

4 years, 7 months

[issue29344] sock_recv not detected a coroutine

by Yury Selivanov

Yury Selivanov added the comment: I think the original idea was to document that all methods of the loop are coroutines, so that: 1. if a user needs a Future object they call ensure_future: fut = asyncio.ensure_future(loop.method()) 2. it gives us ability to refactor things. For instance, sock_connect was a method that returned Futures, but at one point of 3.5 we changed it to be coroutine. Because the method was documented as a coroutine, it wasn't strictly a backwards incompatible way. In general, I think it would be safer for us to simple make all loop methods coroutines. Or, less radical, just keeping the status quo: document everything as a coroutine. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29344> _______________________________________

4 years, 7 months

[issue29407] Remove redundant ensure_future() calls in factorial example

by Berker Peksag

New submission from Berker Peksag: Unless I'm missing something, ensure_future() calls at https://docs.python.org/3.6/library/asyncio-task.html#example-parallel-exec… are redundant and can be removed. Off-topic: Can we use the async/await keywords in asyncio docs now? ---------- assignee: docs@python components: Documentation, asyncio files: ensure_future.diff keywords: patch messages: 286576 nosy: berker.peksag, docs@python, gvanrossum, yselivanov priority: normal severity: normal stage: patch review status: open title: Remove redundant ensure_future() calls in factorial example type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46471/ensure_future.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29407> _______________________________________

4 years, 7 months

[issue29344] sock_recv not detected a coroutine

by Berker Peksag

Berker Peksag added the comment: Here's a patch. sock_connect() wrapped by @coroutine in Lib/asyncio/selector_events.py so I left it as-is. Let me know if it still needs to be updated: @coroutine def sock_connect(self, sock, address): """Connect to a remote socket at address. This method is a coroutine. """ ... return (yield from fut) ---------- assignee: -> docs@python components: +Documentation keywords: +patch nosy: +docs@python stage: -> patch review Added file: http://bugs.python.org/file46483/issue29344.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29344> _______________________________________

4 years, 7 months

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

docs February 2017