From report at bugs.python.org Sat Jul 1 06:17:19 2017 From: report at bugs.python.org (Manvi B) Date: Sat, 01 Jul 2017 10:17:19 +0000 Subject: [docs] [issue26506] [EASY] hex() documentation: mention "%x" % int In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za> Message-ID: <1498904239.64.0.637607066912.issue26506@psf.upfronthosting.co.za> Changes by Manvi B : ---------- pull_requests: +2590 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 1 19:44:27 2017 From: report at bugs.python.org (R. David Murray) Date: Sat, 01 Jul 2017 23:44:27 +0000 Subject: [docs] [issue30798] Document that subprocess.Popen does not set PWD In-Reply-To: <1498703554.38.0.302571639781.issue30798@psf.upfronthosting.co.za> Message-ID: <1498952667.77.0.193311813661.issue30798@psf.upfronthosting.co.za> R. David Murray added the comment: If you pass shell=True, PWD gests set, because it is a shell variable and the shell sets it. If you don't, it doesn't, just like all the other shell-maintained variables. I'm not sure it is worth calling out specifically in the Popen docs, myself; it is one consequence among *many* of calling a program directly rather than through a shell. (Note that if a shell is involved at any point, PWD gets set, so it is only binary programs that require that they be called from a shell that are at issue.) Furthermore, it is not obvious that even all shells set PWD, although I believe that most do. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 1 20:38:27 2017 From: report at bugs.python.org (James Lin) Date: Sun, 02 Jul 2017 00:38:27 +0000 Subject: [docs] [issue30798] Document that subprocess.Popen does not set PWD In-Reply-To: <1498703554.38.0.302571639781.issue30798@psf.upfronthosting.co.za> Message-ID: <1498955907.78.0.0872902512041.issue30798@psf.upfronthosting.co.za> James Lin added the comment: Yes, but the Python docs have scary-looking warnings about using shell=True, so people (rightly) should avoid using shell=True if they don't think that they need it. And in this case, people might not even know that they're invoking some binary that expects PWD from the shell. In my experience, it's not that uncommon for people to rewrite sh/bash shell scripts in Python. Something starts off as a sh/bash script, evolves to a point where it's cumbersome to maintain, and it gets rewritten in Python. But after it's rewritten, some invoked binaries might not behave as before, and it's unclear why. When I encountered this problem myself, the first thing I tried was to explicitly set the `cwd` argument. Some mention of the PWD environment variable would have saved me a lot of time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 1 22:41:13 2017 From: report at bugs.python.org (Kojo Idrissa) Date: Sun, 02 Jul 2017 02:41:13 +0000 Subject: [docs] [issue29933] asyncio: set_write_buffer_limits() doc doesn't specify unit of the parameters In-Reply-To: <1490707139.27.0.838851028066.issue29933@psf.upfronthosting.co.za> Message-ID: <1498963273.26.0.0941818261145.issue29933@psf.upfronthosting.co.za> Changes by Kojo Idrissa : ---------- pull_requests: +2599 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 1 22:41:20 2017 From: report at bugs.python.org (Kojo Idrissa) Date: Sun, 02 Jul 2017 02:41:20 +0000 Subject: [docs] [issue29933] asyncio: set_write_buffer_limits() doc doesn't specify unit of the parameters In-Reply-To: <1490707139.27.0.838851028066.issue29933@psf.upfronthosting.co.za> Message-ID: <1498963280.09.0.731772497995.issue29933@psf.upfronthosting.co.za> Changes by Kojo Idrissa : ---------- pull_requests: +2600 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 1 22:47:59 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 02 Jul 2017 02:47:59 +0000 Subject: [docs] [issue29933] asyncio: set_write_buffer_limits() doc doesn't specify unit of the parameters In-Reply-To: <1490707139.27.0.838851028066.issue29933@psf.upfronthosting.co.za> Message-ID: <1498963678.88.0.513639975524.issue29933@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: New changeset 4685e56596f9f332e402c79c913a73b19f4411e1 by Mariatta (Kojo Idrissa) in branch '3.5': [3.5] bpo-29933: Improve set_write_buffer_limits description (GH-2262) (GH-2533) https://github.com/python/cpython/commit/4685e56596f9f332e402c79c913a73b19f4411e1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 1 22:48:10 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sun, 02 Jul 2017 02:48:10 +0000 Subject: [docs] [issue29933] asyncio: set_write_buffer_limits() doc doesn't specify unit of the parameters In-Reply-To: <1490707139.27.0.838851028066.issue29933@psf.upfronthosting.co.za> Message-ID: <1498963690.1.0.0219314243914.issue29933@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: New changeset 03af4282423b1c287a194664f90496cfc9cf20c7 by Mariatta (Kojo Idrissa) in branch '3.6': [3.6] bpo-29933: Improve set_write_buffer_limits description (GH-2262) (GH-2532) https://github.com/python/cpython/commit/03af4282423b1c287a194664f90496cfc9cf20c7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 2 00:19:59 2017 From: report at bugs.python.org (Anmol Gupta) Date: Sun, 02 Jul 2017 04:19:59 +0000 Subject: [docs] [issue30826] More details in reference 'Looping through a list in Python and modifying it' Message-ID: <1498969199.1.0.0858584839532.issue30826@psf.upfronthosting.co.za> Changes by Anmol Gupta : ---------- assignee: docs at python components: Documentation nosy: Anmol Gupta, docs at python priority: normal severity: normal status: open title: More details in reference 'Looping through a list in Python and modifying it' type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 2 00:22:08 2017 From: report at bugs.python.org (Anmol Gupta) Date: Sun, 02 Jul 2017 04:22:08 +0000 Subject: [docs] [issue30826] More details in reference 'Looping through a list in Python and modifying it' Message-ID: <1498969328.51.0.74139016573.issue30826@psf.upfronthosting.co.za> New submission from Anmol Gupta: Documentation section: https://docs.python.org/3/reference/compound_stmts.html#for The documentation does not explain at all why is there an infinite loop when not using a copy of the list. It leaves the reader in a confused state. Even there are questions concerning the same on stackoverlflow: https://stackoverflow.com/questions/44633798/loop-through-a-list-in-python-and-modify-it ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 2 02:29:34 2017 From: report at bugs.python.org (Anmol Gupta) Date: Sun, 02 Jul 2017 06:29:34 +0000 Subject: [docs] [issue30826] More details in reference 'Looping through a list in Python and modifying it' In-Reply-To: <1498969328.51.0.74139016573.issue30826@psf.upfronthosting.co.za> Message-ID: <1498976974.79.0.347830468334.issue30826@psf.upfronthosting.co.za> Anmol Gupta added the comment: Wrong documentaion section linked. Correct seciton: Section 4.2 on https://docs.python.org/3/tutorial/controlflow.html The last line needs more explanation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 2 05:50:54 2017 From: report at bugs.python.org (Sarge Borsch) Date: Sun, 02 Jul 2017 09:50:54 +0000 Subject: [docs] [issue30827] Tweak order of links in https://www.python.org/downloads/source/ Message-ID: <1498989054.7.0.635942220914.issue30827@psf.upfronthosting.co.za> New submission from Sarge Borsch: Right now, there are these links in https://www.python.org/downloads/source/: Latest Python 2 Release - Python 2.7.13 Latest Python 3 Release - Python 3.6.1 Python 3 should be the first, because it's the real Python now, and Python 2 is deprecated and legacy. ---------- assignee: docs at python components: Documentation, Installation messages: 297510 nosy: Sarge Borsch, docs at python priority: normal severity: normal status: open title: Tweak order of links in https://www.python.org/downloads/source/ type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 2 05:54:35 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 02 Jul 2017 09:54:35 +0000 Subject: [docs] [issue30827] Tweak order of links in https://www.python.org/downloads/source/ In-Reply-To: <1498989054.7.0.635942220914.issue30827@psf.upfronthosting.co.za> Message-ID: <1498989274.98.0.194199049064.issue30827@psf.upfronthosting.co.za> Berker Peksag added the comment: Thank you for the report, Sarge. This is already reported to python.org issue tracker at https://github.com/python/pythondotorg/issues/1079 Closing this as 'third party'. ---------- nosy: +berker.peksag resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 2 08:37:06 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 02 Jul 2017 12:37:06 +0000 Subject: [docs] [issue30826] More details in reference 'Looping through a list in Python and modifying it' In-Reply-To: <1498969328.51.0.74139016573.issue30826@psf.upfronthosting.co.za> Message-ID: <1498999026.49.0.428501505011.issue30826@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The example would be more clear if we replaced the opaque idiom "words[:]" with the more explicit alternative "words.copy()". ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 3 04:13:39 2017 From: report at bugs.python.org (Daisuke Miyakawa) Date: Mon, 03 Jul 2017 08:13:39 +0000 Subject: [docs] [issue30831] Inconsistent or wrong documentation around Asynchronous Context Manager Message-ID: <1499069619.82.0.462830851571.issue30831@psf.upfronthosting.co.za> New submission from Daisuke Miyakawa: I was reading the following doc and got confused. https://docs.python.org/3.7/reference/datamodel.html#object.__aenter__ According to the API doc itself (and original PEP 492), __aenter__() "is semantically similar to the __enter__(), with only difference that it must return an awaitable." __aexit__() has similar sentence that confuses me too. PEP 492 also implies the (awaitable) object returned from obj.__aenter__() will be awaited immediately. In same manner, the (awaitable) object returned from obj.__aexit__() will be awaited too. (From PEP 492) > async with EXPR as VAR: > BLOCK > > which is semantically equivalent to: > > mgr = (EXPR) > aexit = type(mgr).__aexit__ > aenter = type(mgr).__aenter__(mgr) > exc = True > > VAR = await aenter > try: > BLOCK > except: > if not await aexit(mgr, *sys.exc_info()): > raise > else: > await aexit(mgr, None, None, None) On the other hand, actual CPython implementation won't do that; it won't await the returned objects. Moreover, the example shown in the API doc (AsyncContextManager) does NOT return awaitable as the doc itself suggests, but just await inside __aenter__() (and __aexit__()). > class AsyncContextManager: > async def __aenter__(self): > await log('entering context') > > async def __aexit__(self, exc_type, exc, tb): > await log('exiting context') I'm not sure which is true; the doc saying "__aenter__() must return awaitable" is just incorrect, or CPython implementation has a bug. Actual source implies former. _ContextManagerMixin in asyncio.locks does not return awaitable at all, for example. Anyway, I believe there are inconsistencies around here. ---------- assignee: docs at python components: Documentation messages: 297542 nosy: dmiyakawa, docs at python priority: normal severity: normal status: open title: Inconsistent or wrong documentation around Asynchronous Context Manager versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From tritium at sdamon.com Sun Jul 2 08:54:31 2017 From: tritium at sdamon.com (Alex Walters) Date: Sun, 2 Jul 2017 08:54:31 -0400 Subject: [docs] FXpy is referenced in the docs... Message-ID: <0fad01d2f332$594febd0$0befc370$@sdamon.com> FXPy Is referenced in the docs, but is not usable in any recent python, even by centos standards. FXPy is only, as far as I can get it working, for 1.5.2 through 2.2. There is no python 3 port, so it shouldn't be in the 3.x docs at all. Should... probably... remove that from the docs. https://docs.python.org/3/faq/gui.html#fox From berker.peksag at gmail.com Mon Jul 3 06:32:21 2017 From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=) Date: Mon, 3 Jul 2017 13:32:21 +0300 Subject: [docs] FXpy is referenced in the docs... In-Reply-To: <0fad01d2f332$594febd0$0befc370$@sdamon.com> References: <0fad01d2f332$594febd0$0befc370$@sdamon.com> Message-ID: On Sun, Jul 2, 2017 at 3:54 PM, Alex Walters wrote: > FXPy Is referenced in the docs, but is not usable in any recent python, even > by centos standards. FXPy is only, as far as I can get it working, for > 1.5.2 through 2.2. There is no python 3 port, so it shouldn't be in the 3.x > docs at all. Should... probably... remove that from the docs. > > https://docs.python.org/3/faq/gui.html#fox Thank your for the report. I've opened https://github.com/python/cpython/pull/2538 to remove the outdated entry. --Berker From report at bugs.python.org Mon Jul 3 06:44:14 2017 From: report at bugs.python.org (Anmol Gupta) Date: Mon, 03 Jul 2017 10:44:14 +0000 Subject: [docs] [issue30826] More details in reference 'Looping through a list in Python and modifying it' In-Reply-To: <1498969328.51.0.74139016573.issue30826@psf.upfronthosting.co.za> Message-ID: <1499078654.86.0.69464299894.issue30826@psf.upfronthosting.co.za> Anmol Gupta added the comment: And also a small explanation for why there would be an infinite loop without creating a copy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 3 18:55:50 2017 From: report at bugs.python.org (Jakub Stasiak) Date: Mon, 03 Jul 2017 22:55:50 +0000 Subject: [docs] [issue20692] Tutorial and FAQ: how to call a method on an int In-Reply-To: <1392850224.09.0.571764135364.issue20692@psf.upfronthosting.co.za> Message-ID: <1499122550.14.0.0985322179436.issue20692@psf.upfronthosting.co.za> Changes by Jakub Stasiak : ---------- nosy: +jstasiak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 3 19:14:27 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Mon, 03 Jul 2017 23:14:27 +0000 Subject: [docs] [issue20692] Tutorial and FAQ: how to call a method on an int In-Reply-To: <1392850224.09.0.571764135364.issue20692@psf.upfronthosting.co.za> Message-ID: <1499123667.36.0.132734506921.issue20692@psf.upfronthosting.co.za> Cheryl Sabella added the comment: Sreepriya Chalakkal, Would you be able to prepare a pull request on GitHub for your patch? Thanks! ---------- nosy: +csabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 5 23:27:49 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 06 Jul 2017 03:27:49 +0000 Subject: [docs] [issue30840] Contrary to documentation, relative imports cannot pass through the top level In-Reply-To: <1499109292.04.0.970471813466.issue30840@psf.upfronthosting.co.za> Message-ID: <1499311669.56.0.195416741603.issue30840@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- assignee: -> docs at python components: +Documentation nosy: +brett.cannon, docs at python, eric.snow, ncoghlan versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 5 23:58:09 2017 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 06 Jul 2017 03:58:09 +0000 Subject: [docs] [issue30840] Contrary to documentation, relative imports cannot pass through the top level In-Reply-To: <1499109292.04.0.970471813466.issue30840@psf.upfronthosting.co.za> Message-ID: <1499313489.24.0.268319834386.issue30840@psf.upfronthosting.co.za> Nick Coghlan added the comment: That part of the PEP was never implemented - relative imports have never been allowed to cross package boundaries in practice (which is also why "from . import sys" doesn't work as an equivalent to "import sys" at the interactive prompt or in a top level module). Rather than amending the PEP, my inclination is to drop that cross-reference from the documentation, and instead add a new subsection to https://docs.python.org/3/reference/import.html covering "Package relative imports" The key section that needs to be extracted is https://www.python.org/dev/peps/pep-0328/#guido-s-decision (minus the part about cross-package relative imports being permitted). The following section about __name__ is also worth including but needs to be updated to account for __package__ (added by PEP 366), and __spec__ (added by PEP 451). ---------- _______________________________________ Python tracker _______________________________________ From carol at thebestvpn.org Tue Jul 4 09:14:39 2017 From: carol at thebestvpn.org (Carol Brown) Date: Tue, 4 Jul 2017 21:14:39 +0800 Subject: [docs] Found a broken link.... Message-ID: Hi, Hope you're doing well. I just wanted to give you heads up about a broken link I found on your page here: https://docs.python.org/2.6/library/sha.html You've mentioned Cryptographic Toolkit (csrc.nist.gov/CryptoToolkit/) which is unfortunately no longer available. It used to be such a helpful website... If you're looking to replace the broken link, we recently put together a comprehensive introduction/guide on cryptography here: https://thebestvpn.com/cryptography/ It's pretty in-depth and we've put to lot of work on it. Cheers and let me know if it's worth mentioning on your page :) Carol B. From msvc_test at outlook.com Wed Jul 5 04:28:36 2017 From: msvc_test at outlook.com (Eric Lindblad) Date: Wed, 5 Jul 2017 08:28:36 +0000 Subject: [docs] python361.chm file doesn't render properly Message-ID: To Whom it May Concern, System: Microsoft Windows 10 Home Edition CPUs: Intel(R) Celeron(R) CPU N3060 @1.60GHz 64-bit Operating System, x64-based processor Deps: vs_community__1560150700.1495339730.exe, Python-3.6.1.tar.xz http://nurmi-labs.blogspot.com/2017/06/vim-notebook.html I don't know if people use them (.chm files) much anymore. The index appears to work but none of the pages seem to render in the main pane. https://www.python.org/ftp/python/3.6.1/ python361.chm https://docs.python.org/3/download.html You might point out the file format as follows. Plain Text (UNIX format) Download (ca. 2 MB) Download (ca. 1.5 MB) Sincerely, Eric Lindblad P.S. Here are the web pages for a February event in text format. https://github.com/bsbf2018/doc -------------- next part -------------- An HTML attachment was scrubbed... URL: From hallo at julianfilter.de Thu Jul 6 05:50:21 2017 From: hallo at julianfilter.de (Julian Filter) Date: Thu, 6 Jul 2017 11:50:21 +0200 Subject: [docs] spelling error in socket documentation Message-ID: Hello, in the current version (3.6.2rc1) of the documentation of the socket module, the description of socket.setsockopt says: |socket.||setsockopt|(/level/, /optname/, /value: int/) |socket.||setsockopt|(/level/, /optname/, /value: buffer/) |socket.||setsockopt|(/level/, /optname/, /None/, /optlen: int/) Set the value of the given socket option (see the Unix manual page /setsockopt(2)/). The needed symbolic constants are defined in the |socket| module (|SO_*| etc.). The value can be an integer, |None| or a bytes-like object representing a buffer. In the *later* case it is up to the caller to ensure that the bytestring contains the proper bits (see the optional built-in module |struct| for a way to encode C structures as bytestrings). When value is set to |None|, optlen argument is required. It?s equivalent to call setsockopt C function with optval=NULL and optlen=optlen. Changed in version 3.5: Writable bytes-like object is now accepted. Changed in version 3.6: setsockopt(level, optname, None, optlen: int) form added. In my opinion, the fourth sentence should start with 'In the *latter* case..' not with 'In the later case'. With kind regards Julian -------------- next part -------------- An HTML attachment was scrubbed... URL: From report at bugs.python.org Thu Jul 6 15:31:00 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Thu, 06 Jul 2017 19:31:00 +0000 Subject: [docs] [issue26506] [EASY] hex() documentation: mention "%x" % int In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za> Message-ID: <1499369460.59.0.286198158113.issue26506@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: New changeset 67ba4fa467ffff825d6a0c0a21cc54ff1df2ed1b by Mariatta (Manvisha Kodali) in branch 'master': bpo-26506: hex() documentation: mention %x % int (GH-2525) https://github.com/python/cpython/commit/67ba4fa467ffff825d6a0c0a21cc54ff1df2ed1b ---------- _______________________________________ Python tracker _______________________________________ From msvc_test at outlook.com Thu Jul 6 07:38:51 2017 From: msvc_test at outlook.com (Eric Lindblad) Date: Thu, 6 Jul 2017 11:38:51 +0000 Subject: [docs] .chm file Message-ID: To Whom it May Concern, cf: "python361.chm file doesn't render properly" Apparently, at least on that MS version number, i.e., Win10, one has to 'Unblock' the .chm file. Sincerely, Eric Lindblad http://nurmi-labs.blogspot.com/2017/06/vim-notebook.html https://docs.python.org/3/download.html python361.chm Download the above "Windows help file", right click on the .chm file, and from the appearing context menu click "Properties", then enter a mark ? in the box next to the word Unblock and click the "Apply" button, close the "python361 Properties" window, and relocate the file. -------------- next part -------------- An HTML attachment was scrubbed... URL: From report at bugs.python.org Fri Jul 7 11:14:13 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 07 Jul 2017 15:14:13 +0000 Subject: [docs] [issue30872] Update curses docs to Python 3 Message-ID: <1499440453.75.0.308646182968.issue30872@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: The curses libraries works with strings and characters. But what are strings? In different functions this means different: Unicode strings, byte strings or any. Proposed PR explains this. It also unifies the documentation of boolean arguments, and fixes some references and formatting. ---------- assignee: docs at python components: Documentation messages: 297892 nosy: docs at python, r.david.murray, serhiy.storchaka, twouters priority: normal severity: normal stage: patch review status: open title: Update curses docs to Python 3 type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 7 11:15:46 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 07 Jul 2017 15:15:46 +0000 Subject: [docs] [issue30872] Update curses docs to Python 3 In-Reply-To: <1499440453.75.0.308646182968.issue30872@psf.upfronthosting.co.za> Message-ID: <1499440546.47.0.126373673911.issue30872@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- pull_requests: +2686 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 7 22:47:20 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 08 Jul 2017 02:47:20 +0000 Subject: [docs] [issue30826] More details in reference 'Looping through a list in Python and modifying it' In-Reply-To: <1498969328.51.0.74139016573.issue30826@psf.upfronthosting.co.za> Message-ID: <1499482040.41.0.573478796257.issue30826@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Are you looking for something like: Let it = iter(words). When next(it) returns 'defenestrate', insertion at the beginning moves the original 'defenestrate' over so that next(words) returns 'defenestrate' again. ? ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 8 03:48:19 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 08 Jul 2017 07:48:19 +0000 Subject: [docs] [issue10438] list an example for calling static methods from WITHIN classes In-Reply-To: <1289939012.34.0.0666500494472.issue10438@psf.upfronthosting.co.za> Message-ID: <1499500099.72.0.718573910943.issue10438@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 8 23:13:57 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 09 Jul 2017 03:13:57 +0000 Subject: [docs] [issue10438] list an example for calling static methods from WITHIN classes In-Reply-To: <1289939012.34.0.0666500494472.issue10438@psf.upfronthosting.co.za> Message-ID: <1499570037.31.0.715683773748.issue10438@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I also don't think this is worth it. The extra wording will likely cause more confusion that it clears up. Also, calling a staticmethod from within a class isn't a common thing to do. The principal use case for Python's static methods is to attach a function to a class for the sole purpose of making it findable by someone using that class. ---------- nosy: +rhettinger status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 9 07:30:10 2017 From: report at bugs.python.org (Ian) Date: Sun, 09 Jul 2017 11:30:10 +0000 Subject: [docs] [issue10438] list an example for calling static methods from WITHIN classes In-Reply-To: <1289939012.34.0.0666500494472.issue10438@psf.upfronthosting.co.za> Message-ID: <1499599810.19.0.966876201836.issue10438@psf.upfronthosting.co.za> Ian added the comment: I agree that the use case is probably rare. I agree that to someone intimately familiar with the "self-consistent rules" of Python, the correctness of the C.f() approach is probably obvious. However, your documentation says: Static methods in Python are similar to those found in Java or C++. I feel that it's a mistake to purposefully avoid saying where that similarity ends. In those languages (and in many others), fully qualified function calls from within the same class are redundant and border on "code smell". We agree that this aspect of Python is not mentioned in the documentation, and we disagree on whether it should be. For myself, even in the 7 years and thousands of lines of Python since I opened this issue, I still don't find it intuitive or obvious that a method would need to know the name of the class that contains it. That doesn't make the language "wrong" in any way; it makes the documentation incomplete for not addressing it. The __class__.f() usage in Python 3 seems excellent. If that's the preferred way to do it, then that might be a way to approach the documentation. "To call one static method from another within the same class, as of Python 3 you may use __class__.f() instead of C.f(). For Python 2.x, you must still use the name of the class itself, C.f(), as if you were calling from outside the class." (My wording is still less than ideal, but you get the idea.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 9 13:53:28 2017 From: report at bugs.python.org (Christoph Deil) Date: Sun, 09 Jul 2017 17:53:28 +0000 Subject: [docs] [issue30882] Built-in list disappeared from Python 2.7 intersphinx inventory Message-ID: <1499622808.04.0.381858845257.issue30882@psf.upfronthosting.co.za> New submission from Christoph Deil: We have a project where we sub-class `list`. Since recently our docs build is failing because the intersphinx inventory entry for `list` on Python 2.7 doesn't exist any more. I think this is a regression, because Python 2.7 is supposed to be stable and other functions and classes here are still there, just "list" is missing: https://docs.python.org/2.7/library/functions.html#func-list Just in case someone else sees this issue, the Sphinx warning looks like this: ``` docs/api/pyregion.ShapeList.rst:7: WARNING: py:class reference target not found: list ``` if you have something like ``` class ShapeList(list): """My list sub-class""" ``` ---------- assignee: docs at python components: Documentation messages: 297993 nosy: Christoph.Deil, docs at python priority: normal severity: normal status: open title: Built-in list disappeared from Python 2.7 intersphinx inventory versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 10 02:22:58 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 10 Jul 2017 06:22:58 +0000 Subject: [docs] [issue30882] Built-in list disappeared from Python 2.7 intersphinx inventory In-Reply-To: <1499622808.04.0.381858845257.issue30882@psf.upfronthosting.co.za> Message-ID: <1499667778.63.0.34152852876.issue30882@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is caused by backporting some changes from 3.x. In 3.x the list class is described in two places, in functions.rst and in stdtypes.rst, and these changes fixed the ambiguity by excluding the reference in functions.rst from the index. But in 2.7 this is the only description of the list class. We need either revert changes that exclude the reference to the list class description in functions.rst from the index, or add a description in stdtypes.rst. ---------- nosy: +serhiy.storchaka type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 10 09:54:38 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Mon, 10 Jul 2017 13:54:38 +0000 Subject: [docs] [issue30882] Built-in list disappeared from Python 2.7 intersphinx inventory In-Reply-To: <1499622808.04.0.381858845257.issue30882@psf.upfronthosting.co.za> Message-ID: <1499694878.96.0.0194173431439.issue30882@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- assignee: docs at python -> Mariatta nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 10 22:03:21 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 11 Jul 2017 02:03:21 +0000 Subject: [docs] [issue30803] Truth value of sets not properly documented In-Reply-To: <1498743378.1.0.0570911503542.issue30803@psf.upfronthosting.co.za> Message-ID: <1499738600.99.0.800176443434.issue30803@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Responding here to Peter's PR comment. Peter opened this issue with the claim that the doc failed a specific test case-- document the truth value of set(). Since mappings are (or can be viewed as) a specialized type of set, I always considered that the empty mapping line implicitly covered sets. But I acknowledge that this is not clear for everyone. The simplest fix to make the test pass would be: "any unordered collection, for example, set(), {}". This should also cover frozenset and a possible frozendict. Raymond noted that 'user-defined' in the last bullet point is wrong (it implies that built-in functions are different) and should be deleted. He then combined the corrected rule for false with the default rule in the next sentence to produce a succinct statement of the actual rule. (In CPython, 'default' is literally true. Class 'object' has neither __bool__ nor __len__; ditto for all subclasses that do not add one.) With a minor change, I like this statement and agree that it should be moved above the examples. But I think the bullet points should be reduced to just 3, rewritten, and single spaced, but not smashed into running text. I suggest replacing everything between the first sentence (ending with 'below.') and the last two (beginning with 'Operations') with: "By default, an object is considered true unless its class defines either a __bool__ method that returns False or __len__ method that returns zero, when called with the object. Here are most of the built-in objects considered false. * constants defined to be false: None and False. * numeric 0 of any type: 0, 0.0, Decimal(0), Fractions(0, 1) * empty sequences and collections: '', (), [], {}, set(), range(0) " Before writing the above, I checked that an instance attribute __bool__ = lambda: False is not consulted by bool(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 11 03:23:15 2017 From: report at bugs.python.org (Alexander Kamyanskiy) Date: Tue, 11 Jul 2017 07:23:15 +0000 Subject: [docs] [issue30901] "503 HTTP ERROR" on attempt to access some points of python library documentation Message-ID: <1499757795.27.0.716846714623.issue30901@psf.upfronthosting.co.za> New submission from Alexander Kamyanskiy: I found that some points in Python Library reference documentation are not accessible, I got 503 http error. The problem starts from this link and some points below the 29.14 point of doc list: https://docs.python.org/3/library/fpectl.html Also now I got 503: https://docs.python.org/3/library/custominterp.html https://docs.python.org/3/library/zipimport.html https://docs.python.org/3/library/pkgutil.html https://docs.python.org/3/library/symbol.html https://docs.python.org/3/library/token.html ... In fact I can't say for example that "31. Importing Modules" all inaccessible - I can't access 31.3. modulefinder ? Find modules used by a script 31.4. runpy ? Locating and executing Python modules 31.5. importlib ? The implementation of import but cannot (I got 503 http response): 31.1. zipimport ? Import modules from Zip archives 31.2. pkgutil ? Package extension utility P.S. I've tried to access documentation from absolutely another place and I'm sure it's not my local settings in browser or local firewall or smth like this. ---------- assignee: docs at python components: Documentation messages: 298139 nosy: Alexander Kamyanskiy, docs at python priority: normal severity: normal status: open title: "503 HTTP ERROR" on attempt to access some points of python library documentation type: resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 11 03:28:28 2017 From: report at bugs.python.org (Louie Lu) Date: Tue, 11 Jul 2017 07:28:28 +0000 Subject: [docs] [issue30901] "503 HTTP ERROR" on attempt to access some points of python library documentation In-Reply-To: <1499757795.27.0.716846714623.issue30901@psf.upfronthosting.co.za> Message-ID: <1499758108.86.0.983360232279.issue30901@psf.upfronthosting.co.za> Louie Lu added the comment: Can reproduce this problem in Chromium 59.0.3071, it seems affect every selectable version in docs.python.org. Also, devguide has some page down, too. * devguide: https://docs.python.org/devguide/triaging.html ---------- nosy: +louielu type: resource usage -> _______________________________________ Python tracker _______________________________________ From darnell.gawdin at gmail.com Sat Jul 8 22:48:23 2017 From: darnell.gawdin at gmail.com (Darnell Gawdin) Date: Sat, 8 Jul 2017 19:48:23 -0700 Subject: [docs] Doc not found Message-ID: <59619975.58c0620a.fd6ea.1ada@mx.google.com> I tried to download files from Download Python 3.6.2rc2 Documentation got 404 Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ea.panta at gmail.com Sun Jul 9 20:03:08 2017 From: ea.panta at gmail.com (Ethy Attir) Date: Mon, 10 Jul 2017 03:03:08 +0300 Subject: [docs] There are no PDF, Epub doc files for 3.6 Message-ID: ________________________________ Ethy Attir, Tel (Mobile): +972-54-6625042 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjlemire at gmail.com Sat Jul 8 16:59:13 2017 From: jjlemire at gmail.com (JJ Lemire) Date: Sat, 8 Jul 2017 16:59:13 -0400 Subject: [docs] The current documentation is missing from the site Message-ID: Hi, The current documentation ( Sat 207-July-08) is missing for the site for downloads. nginx is reporting a problem. Please update Thanks -- Jacques -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukain1337 at gmail.com Sun Jul 9 07:18:04 2017 From: lukain1337 at gmail.com (NewLuca) Date: Sun, 9 Jul 2017 20:18:04 +0900 Subject: [docs] Downloading Python documentation. Message-ID: <0B080EEB-B1F2-4BD2-8664-B5A49E00363D@gmail.com> Hi, I am getting a ?404 Not Found? error when trying to download the Python documentation. From khandorraj at gmail.com Sun Jul 9 11:17:14 2017 From: khandorraj at gmail.com (Raj Khandor) Date: Sun, 9 Jul 2017 20:47:14 +0530 Subject: [docs] Error in downloading documentation Message-ID: [image: Inline image 1] I am not able to download python 3.6.2rc2 documentation since it showing me an error ( in the image above ) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 60755 bytes Desc: not available URL: From pawak.dubey at accenture.com Sat Jul 8 03:48:05 2017 From: pawak.dubey at accenture.com (Dubey, Pawak) Date: Sat, 8 Jul 2017 07:48:05 +0000 Subject: [docs] Unable to download pdf file Message-ID: I am unable to download pdf file. Website throws 404 error. ________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. ______________________________________________________________________________________ www.accenture.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From salestrading at aliyun.com Tue Jul 11 05:58:08 2017 From: salestrading at aliyun.com (MR-OU) Date: Tue, 11 Jul 2017 17:58:08 +0800 Subject: [docs] docs@python.org Message-ID: <201707111758081934555@mail.ovzc.net> An HTML attachment was scrubbed... URL: From vishal85.gupta at gmail.com Sun Jul 9 12:51:53 2017 From: vishal85.gupta at gmail.com (Vishal Gupta) Date: Sun, 9 Jul 2017 22:21:53 +0530 Subject: [docs] Download Python 3.6.2rc2 Documentation Message-ID: Hi , When i trying to download documentation getting 404 error. [image: Inline image 1] -- --With Thanks & Regards--- Vishal Gupta +91-9650137601 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 18295 bytes Desc: not available URL: From yanjia.jiao at nyu.edu Sat Jul 8 02:11:44 2017 From: yanjia.jiao at nyu.edu (Yanjia Jiao) Date: Sat, 8 Jul 2017 14:11:44 +0800 Subject: [docs] Python 3.6.2rc2 Documentation Message-ID: Dear Sir or Madam, I am writing to you regarding the Python 3.6.2rc2 Documentation. When I was trying to download it (I want PDF, but I tried all format) from the link https://docs.python.org/3.6/download.html, it took me to a page saying "404 not found". I tried other versions, eg 3.5 and 2.7, they were fine. Could you please let me know the correct way to download? Thank you! Best regards, Yanjia -------------- next part -------------- An HTML attachment was scrubbed... URL: From report at bugs.python.org Tue Jul 11 08:39:42 2017 From: report at bugs.python.org (Abhijit Mamarde) Date: Tue, 11 Jul 2017 12:39:42 +0000 Subject: [docs] [issue30903] IPv4Network's hostmask attribute doesn't returns string value as mentioned in Documentation. Message-ID: <1499776782.68.0.13911603646.issue30903@psf.upfronthosting.co.za> New submission from Abhijit Mamarde: documentation mentions hostmask attribute of IPv4Network class returns a `string`, but in actual it is returning the object of class IPv4Address URL to official doc: https://docs.python.org/3/library/ipaddress.html#ipaddress.IPv4Network.hostmask PFA program file to show the actual issue. ---------- assignee: docs at python components: Documentation files: ipaddress_doc_bug.py messages: 298153 nosy: Abhijit Mamarde, docs at python priority: normal severity: normal status: open title: IPv4Network's hostmask attribute doesn't returns string value as mentioned in Documentation. type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file47007/ipaddress_doc_bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 11 12:03:17 2017 From: report at bugs.python.org (Brett Cannon) Date: Tue, 11 Jul 2017 16:03:17 +0000 Subject: [docs] [issue30901] "503 HTTP ERROR" on attempt to access some points of python library documentation In-Reply-To: <1499757795.27.0.716846714623.issue30901@psf.upfronthosting.co.za> Message-ID: <1499788997.0.0.237791488422.issue30901@psf.upfronthosting.co.za> Brett Cannon added the comment: Those pages all work for me. May have been transient. ---------- nosy: +brett.cannon resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 11 12:17:25 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 11 Jul 2017 16:17:25 +0000 Subject: [docs] [issue30901] "503 HTTP ERROR" on attempt to access some points of python library documentation In-Reply-To: <1499757795.27.0.716846714623.issue30901@psf.upfronthosting.co.za> Message-ID: <1499789845.28.0.743601783172.issue30901@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: There was partial outage. See post mortem report: https://status.python.org/incidents/cc622spyl26l ---------- nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 11 13:44:29 2017 From: report at bugs.python.org (R. David Murray) Date: Tue, 11 Jul 2017 17:44:29 +0000 Subject: [docs] [issue10438] list an example for calling static methods from WITHIN classes In-Reply-To: <1289939012.34.0.0666500494472.issue10438@psf.upfronthosting.co.za> Message-ID: <1499795069.7.0.0147743855031.issue10438@psf.upfronthosting.co.za> R. David Murray added the comment: Given a choice between catering for Python programmers and catering for Java/C++ programmers, the Python docs obviously ought to chose to cater to Python programmers. To a python programmer, calling C.f() is intuitive. I would myself definitely *not* encourage the __class__.f() idiom. Maybe we should just drop the reference to Java and C++ static methods. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 11 14:02:54 2017 From: report at bugs.python.org (Ian) Date: Tue, 11 Jul 2017 18:02:54 +0000 Subject: [docs] [issue10438] list an example for calling static methods from WITHIN classes In-Reply-To: <1289939012.34.0.0666500494472.issue10438@psf.upfronthosting.co.za> Message-ID: <1499796174.62.0.35816132248.issue10438@psf.upfronthosting.co.za> Ian added the comment: I would hope that the docs would cater to people who aren't sure how the language works (and who want to confirm that they are using proper patterns). If people already know how the language works, they won't need the docs. Whether or not you refer to Java and C++, you should state the best practices for both internal and external calling of static methods in Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 11 14:36:42 2017 From: report at bugs.python.org (R. David Murray) Date: Tue, 11 Jul 2017 18:36:42 +0000 Subject: [docs] [issue10438] list an example for calling static methods from WITHIN classes In-Reply-To: <1289939012.34.0.0666500494472.issue10438@psf.upfronthosting.co.za> Message-ID: <1499798202.69.0.46060735981.issue10438@psf.upfronthosting.co.za> R. David Murray added the comment: I'm not sure there's a "best practice" choice between the two calling forms that are documented. Although obviously when you don't have an instance you can't use the instance calling form. I think it is *common* practice to use the instance form when you can, but I'm not sure it is either superior or inferior to using the class form. It partly depends on how you have structured your code and why you are using static methods in the first place. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 12 00:09:53 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 12 Jul 2017 04:09:53 +0000 Subject: [docs] [issue10438] list an example for calling static methods from WITHIN classes In-Reply-To: <1289939012.34.0.0666500494472.issue10438@psf.upfronthosting.co.za> Message-ID: <1499832593.48.0.760981508394.issue10438@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Ian, the docs mostly serve to tell what a tool does. Best practices then emerge from actual practices and are determined by users. I don't see any bug here that needs to be solved and think it is time to close this tracker item. It has been consuming developer clock cycles without addressing any real, known issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 12 09:20:33 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 12 Jul 2017 13:20:33 +0000 Subject: [docs] [issue30826] More details in reference 'Looping through a list in Python and modifying it' In-Reply-To: <1498969328.51.0.74139016573.issue30826@psf.upfronthosting.co.za> Message-ID: <1499865633.66.0.00727172991005.issue30826@psf.upfronthosting.co.za> R. David Murray added the comment: I don't think that helps. The issue here is that *sequences* are iterated over by incrementing an integer index. If you change the size of the list, you are potentially changing which value any given index points to. Presumably the tutorial writer thought this was intuitive, and indeed after years of Python programming I find it so. I can see how a beginner might not, though :) What if we replaced: If you need to modify the sequence you are iterating over while inside the loop (for example to duplicate selected items), it is recommended that you first make a copy. Iterating over a sequence does not implicitly make a copy. The slice notation makes this especially convenient: With: Sequence iteration is preformed by incrementing an implicit integer index until there are no more items in the sequence. The sequence is *not* copied before iteration, so if you modify the sequence during iteration the value that is affected by the next iteration of the loop may not be the one you are expecting. You can avoid this problem by iterating over a copy of the sequence, and the slice notation makes this especially convenient: However, this section has a deeper problem. It is introducing the 'for' statement, but explains what the for statement does in terms of sequences, when in fact the for statement now operates on any iterable, not just sequences. (Many Python programmers probably do not remember the time before the iteration protocol was added to the language :) Fixing that problem not only requires rewriting the section, but also figuring out the best place to introduce the concept of the iteration protocol (which *might* be in this section, but it's been so long since I've looked over the tutorial that I can't say). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 12 11:48:48 2017 From: report at bugs.python.org (Ian) Date: Wed, 12 Jul 2017 15:48:48 +0000 Subject: [docs] [issue10438] list an example for calling static methods from WITHIN classes In-Reply-To: <1289939012.34.0.0666500494472.issue10438@psf.upfronthosting.co.za> Message-ID: <1499874528.95.0.917712644147.issue10438@psf.upfronthosting.co.za> Ian added the comment: As indicated earlier, I would prefer to see clear instructions on how to call a class's static method from another static method within the same class. Currently, it's only clear how to call from outside the class. If that's not going to happen, then I agree that this issue should be closed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 12 13:03:29 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 12 Jul 2017 17:03:29 +0000 Subject: [docs] [issue10438] list an example for calling static methods from WITHIN classes In-Reply-To: <1289939012.34.0.0666500494472.issue10438@psf.upfronthosting.co.za> Message-ID: <1499879009.7.0.983535488754.issue10438@psf.upfronthosting.co.za> R. David Murray added the comment: It is documented how to call a static method when you don't have an instance. So when you don't (for example, inside a static method on the same class) you use that form (call the method on the class name). I realize you don't find this clear, but as Raymond says it is time to stop arguing about it; our rule is that the status quo wins when agreement is not reached for a change. Closing. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 12 22:30:41 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Thu, 13 Jul 2017 02:30:41 +0000 Subject: [docs] [issue30466] Tutorial doesn't explain the use of classes In-Reply-To: <1495666720.41.0.650692797283.issue30466@psf.upfronthosting.co.za> Message-ID: <1499913040.86.0.341957279959.issue30466@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: New changeset 3fbd70018f835edd33250de2f79b7a7ef45f8359 by Mariatta (Trey Hunner) in branch 'master': bpo-30466: Add brief explanation of classes to tutorial (GH-1804) https://github.com/python/cpython/commit/3fbd70018f835edd33250de2f79b7a7ef45f8359 ---------- nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 12 22:32:14 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Thu, 13 Jul 2017 02:32:14 +0000 Subject: [docs] [issue30466] Tutorial doesn't explain the use of classes In-Reply-To: <1495666720.41.0.650692797283.issue30466@psf.upfronthosting.co.za> Message-ID: <1499913134.17.0.526071958118.issue30466@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- stage: patch review -> backport needed _______________________________________ Python tracker _______________________________________ From gdsuibe at outlook.com Mon Jul 10 03:45:27 2017 From: gdsuibe at outlook.com (ge Devon) Date: Mon, 10 Jul 2017 07:45:27 +0000 Subject: [docs] bug: failed to download Python 3.6.2rc2 Documentation Message-ID: In this page, https://docs.python.org/3/download.html, when I try to download the latest docs (format: ePub), I get a ?404 Not found? response. Then I try other formats, all failed ??? Windows 10 ????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From report at bugs.python.org Thu Jul 13 16:41:40 2017 From: report at bugs.python.org (Trey Hunner) Date: Thu, 13 Jul 2017 20:41:40 +0000 Subject: [docs] [issue30466] Tutorial doesn't explain the use of classes In-Reply-To: <1495666720.41.0.650692797283.issue30466@psf.upfronthosting.co.za> Message-ID: <1499978500.74.0.453667077356.issue30466@psf.upfronthosting.co.za> Changes by Trey Hunner : ---------- pull_requests: +2766 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 13 19:10:20 2017 From: report at bugs.python.org (Malcolm Smith) Date: Thu, 13 Jul 2017 23:10:20 +0000 Subject: [docs] [issue15360] Behavior of assigning to __dict__ is not documented In-Reply-To: <1342373106.65.0.0254375505566.issue15360@psf.upfronthosting.co.za> Message-ID: <1499987420.76.0.110952508535.issue15360@psf.upfronthosting.co.za> Changes by Malcolm Smith : ---------- nosy: +Malcolm Smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 13 21:13:23 2017 From: report at bugs.python.org (Peter Thomassen) Date: Fri, 14 Jul 2017 01:13:23 +0000 Subject: [docs] [issue30803] Truth value of sets not properly documented In-Reply-To: <1498743378.1.0.0570911503542.issue30803@psf.upfronthosting.co.za> Message-ID: <1499994803.54.0.0990102743358.issue30803@psf.upfronthosting.co.za> Peter Thomassen added the comment: I like your most recent suggestion, and updated the PR after fixing a typo ('Fractions') and making it more complete (complex numbers). Let me know if anything else is needed. (A mapping is not a specialized set, at least as far as typing is concerned: `isinstance({}, set)` is false. Semantically, they may be related, but the question here is whether the types are actually related.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 14 00:13:39 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 14 Jul 2017 04:13:39 +0000 Subject: [docs] [issue30803] Truth value of sets not properly documented In-Reply-To: <1498743378.1.0.0570911503542.issue30803@psf.upfronthosting.co.za> Message-ID: <1500005619.52.0.053360334223.issue30803@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Raymond, if you either unassign yourself or approve the current PR, I will merge and backport to 3.6 (but not 3.5). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 14 13:53:05 2017 From: report at bugs.python.org (Malcolm Smith) Date: Fri, 14 Jul 2017 17:53:05 +0000 Subject: [docs] [issue23674] super() documentation isn't very clear In-Reply-To: <1426448451.56.0.492486239807.issue23674@psf.upfronthosting.co.za> Message-ID: <1500054785.5.0.118273225768.issue23674@psf.upfronthosting.co.za> Malcolm Smith added the comment: I agree that the first two paragraphs are confusing. It's clearly not true to say "The search order is same as that used by getattr() except that the type itself is skipped", because as noted above, everything *earlier* than the type in the MRO is also skipped. The second paragraph then goes on to imply that super() uses the MRO of its first argument, which contradicts the first paragraph, and apparently isn't true either. Raymond explained the actual behavior quite clearly in his comment of 2015-03-15 21:34, and that's what the documentation should do as well. ---------- nosy: +Malcolm Smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 14 22:03:41 2017 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 15 Jul 2017 02:03:41 +0000 Subject: [docs] [issue30935] document the new behavior of get_event_loop() Python 3.6 Message-ID: <1500084221.73.0.556830879215.issue30935@psf.upfronthosting.co.za> New submission from Chris Jerdonek: Currently, the Python asyncio.get_event_loop() docs don't say that get_event_loop() returns the currently running event loop when it is called from a coroutine: https://docs.python.org/3/library/asyncio-eventloops.html#asyncio.get_event_loop https://docs.python.org/3/library/asyncio-eventloops.html#asyncio.AbstractEventLoopPolicy.get_event_loop This is new behavior that was introduced in Python 3.6 in this issue: https://github.com/python/asyncio/pull/452 Without this, the docs make it seem like get_event_loop() should return the loop that was last passed to set_event_loop(). This could be added with a "Changed in version 3.6" note. ---------- assignee: docs at python components: Documentation messages: 298380 nosy: chris.jerdonek, docs at python priority: normal severity: normal status: open title: document the new behavior of get_event_loop() Python 3.6 versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 14 22:10:34 2017 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 15 Jul 2017 02:10:34 +0000 Subject: [docs] [issue30935] document the new behavior of get_event_loop() in Python 3.6 In-Reply-To: <1500084221.73.0.556830879215.issue30935@psf.upfronthosting.co.za> Message-ID: <1500084634.93.0.354784495455.issue30935@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- title: document the new behavior of get_event_loop() Python 3.6 -> document the new behavior of get_event_loop() in Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 14 22:11:44 2017 From: report at bugs.python.org (Chris Jerdonek) Date: Sat, 15 Jul 2017 02:11:44 +0000 Subject: [docs] [issue30935] document the new behavior of get_event_loop() in Python 3.6 In-Reply-To: <1500084221.73.0.556830879215.issue30935@psf.upfronthosting.co.za> Message-ID: <1500084704.04.0.598463125592.issue30935@psf.upfronthosting.co.za> Changes by Chris Jerdonek : ---------- components: +asyncio nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 15 00:45:55 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Sat, 15 Jul 2017 04:45:55 +0000 Subject: [docs] [issue30935] document the new behavior of get_event_loop() in Python 3.6 In-Reply-To: <1500084221.73.0.556830879215.issue30935@psf.upfronthosting.co.za> Message-ID: <1500093955.46.0.241562829357.issue30935@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- stage: -> needs patch versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 15 10:48:05 2017 From: report at bugs.python.org (Pavel) Date: Sat, 15 Jul 2017 14:48:05 +0000 Subject: [docs] [issue30937] csv module examples miss newline='' when opening files Message-ID: <1500130085.47.0.354601054193.issue30937@psf.upfronthosting.co.za> New submission from Pavel: At the very beginning the csv module documentation (https://docs.python.org/3.7/library/csv.html) advises to open files passing newline='' parameter though three examples don't include it: Here are the examples: 1: >>> import csv >>> with open('names.csv') as csvfile: ... reader = csv.DictReader(csvfile) ... for row in reader: ... print(row['first_name'], row['last_name']) ... Eric Idle John Cleese >>> print(row) OrderedDict([('first_name', 'John'), ('last_name', 'Cleese')]) 2: import csv with open('names.csv', 'w') as csvfile: fieldnames = ['first_name', 'last_name'] writer = csv.DictWriter(csvfile, fieldnames=fieldnames) writer.writeheader() writer.writerow({'first_name': 'Baked', 'last_name': 'Beans'}) writer.writerow({'first_name': 'Lovely', 'last_name': 'Spam'}) writer.writerow({'first_name': 'Wonderful', 'last_name': 'Spam'}) 3: with open('example.csv') as csvfile: dialect = csv.Sniffer().sniff(csvfile.read(1024)) csvfile.seek(0) reader = csv.reader(csvfile, dialect) # ... process CSV file contents here ... ---------- assignee: docs at python components: Documentation messages: 298397 nosy: Pavel, docs at python priority: normal severity: normal status: open title: csv module examples miss newline='' when opening files versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 15 15:19:13 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 15 Jul 2017 19:19:13 +0000 Subject: [docs] [issue30939] Sphinx 1.6.3 deprecation warning for sphinx.util.compat.Directive in docs builds Message-ID: <1500146353.65.0.778877813503.issue30939@psf.upfronthosting.co.za> New submission from Ned Deily: [..]/sphinx/util/compat.py:40: RemovedInSphinx17Warning: sphinx.util.compat.Directive is deprecated and will be removed in Sphinx 1.7, please use docutils' instead. RemovedInSphinx17Warning) The solution is to import Directive directly from docutils. PR to follow for master, needs to be cherrypicked to all maintenance branches and, ideally, all current security-only branches. ---------- assignee: docs at python components: Documentation messages: 298401 nosy: brett.cannon, docs at python, larry, ned.deily priority: normal severity: normal stage: patch review status: open title: Sphinx 1.6.3 deprecation warning for sphinx.util.compat.Directive in docs builds versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 15 15:22:43 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 15 Jul 2017 19:22:43 +0000 Subject: [docs] [issue30939] Sphinx 1.6.3 deprecation warning for sphinx.util.compat.Directive in docs builds In-Reply-To: <1500146353.65.0.778877813503.issue30939@psf.upfronthosting.co.za> Message-ID: <1500146563.29.0.865111452458.issue30939@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- pull_requests: +2780 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 15 15:25:59 2017 From: report at bugs.python.org (Larry Hastings) Date: Sat, 15 Jul 2017 19:25:59 +0000 Subject: [docs] [issue30939] Sphinx 1.6.3 deprecation warning for sphinx.util.compat.Directive in docs builds In-Reply-To: <1500146353.65.0.778877813503.issue30939@psf.upfronthosting.co.za> Message-ID: <1500146759.53.0.966979821004.issue30939@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- pull_requests: +2781 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 15 15:28:04 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 15 Jul 2017 19:28:04 +0000 Subject: [docs] [issue30939] Sphinx 1.6.3 deprecation warning for sphinx.util.compat.Directive in docs builds In-Reply-To: <1500146353.65.0.778877813503.issue30939@psf.upfronthosting.co.za> Message-ID: <1500146884.1.0.139602551593.issue30939@psf.upfronthosting.co.za> Ned Deily added the comment: New changeset 50f58163a69abe2f35e91044d1df165ee7bdbb42 by Ned Deily in branch 'master': bpo-30939: Avoid Sphinx deprecation warning in docs build. (#2721) https://github.com/python/cpython/commit/50f58163a69abe2f35e91044d1df165ee7bdbb42 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 15 16:51:11 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 15 Jul 2017 20:51:11 +0000 Subject: [docs] [issue30939] Sphinx 1.6.3 deprecation warning for sphinx.util.compat.Directive in docs builds In-Reply-To: <1500146353.65.0.778877813503.issue30939@psf.upfronthosting.co.za> Message-ID: <1500151871.75.0.999061941991.issue30939@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- pull_requests: +2782 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 15 16:56:15 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 15 Jul 2017 20:56:15 +0000 Subject: [docs] [issue30939] Sphinx 1.6.3 deprecation warning for sphinx.util.compat.Directive in docs builds In-Reply-To: <1500146353.65.0.778877813503.issue30939@psf.upfronthosting.co.za> Message-ID: <1500152175.79.0.869050445201.issue30939@psf.upfronthosting.co.za> Ned Deily added the comment: New changeset bbd0f423d2a19c6a4a9cda6914fc60b87e17250b by Ned Deily in branch '3.6': bpo-30939: Avoid Sphinx deprecation warning in docs build. (#2721) (#2722) https://github.com/python/cpython/commit/bbd0f423d2a19c6a4a9cda6914fc60b87e17250b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 15 16:57:59 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 15 Jul 2017 20:57:59 +0000 Subject: [docs] [issue30939] Sphinx 1.6.3 deprecation warning for sphinx.util.compat.Directive in docs builds In-Reply-To: <1500146353.65.0.778877813503.issue30939@psf.upfronthosting.co.za> Message-ID: <1500152279.2.0.501701422632.issue30939@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- pull_requests: +2783 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 15 17:01:58 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 15 Jul 2017 21:01:58 +0000 Subject: [docs] [issue30939] Sphinx 1.6.3 deprecation warning for sphinx.util.compat.Directive in docs builds In-Reply-To: <1500146353.65.0.778877813503.issue30939@psf.upfronthosting.co.za> Message-ID: <1500152518.37.0.538196209244.issue30939@psf.upfronthosting.co.za> Ned Deily added the comment: New changeset ada3f31365d0634d0cd8eeacfacd98291e34a8cc by Ned Deily in branch '3.5': bpo-30939: Avoid Sphinx deprecation warning in docs build. (#2721) (#2723) https://github.com/python/cpython/commit/ada3f31365d0634d0cd8eeacfacd98291e34a8cc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 15 17:10:10 2017 From: report at bugs.python.org (Ned Deily) Date: Sat, 15 Jul 2017 21:10:10 +0000 Subject: [docs] [issue30939] Sphinx 1.6.3 deprecation warning for sphinx.util.compat.Directive in docs builds In-Reply-To: <1500146353.65.0.778877813503.issue30939@psf.upfronthosting.co.za> Message-ID: <1500153010.11.0.42266572044.issue30939@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- pull_requests: +2784 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 15 23:04:09 2017 From: report at bugs.python.org (Ned Deily) Date: Sun, 16 Jul 2017 03:04:09 +0000 Subject: [docs] [issue30939] Sphinx 1.6.3 deprecation warning for sphinx.util.compat.Directive in docs builds In-Reply-To: <1500146353.65.0.778877813503.issue30939@psf.upfronthosting.co.za> Message-ID: <1500174249.89.0.880353534986.issue30939@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- pull_requests: +2785 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 15 23:06:59 2017 From: report at bugs.python.org (Ned Deily) Date: Sun, 16 Jul 2017 03:06:59 +0000 Subject: [docs] [issue30939] Sphinx 1.6.3 deprecation warning for sphinx.util.compat.Directive in docs builds In-Reply-To: <1500146353.65.0.778877813503.issue30939@psf.upfronthosting.co.za> Message-ID: <1500174419.66.0.106700563875.issue30939@psf.upfronthosting.co.za> Ned Deily added the comment: New changeset 64a9f3d961084819335ea011063eb8cb41733882 by Ned Deily in branch '2.7': bpo-30939: Avoid Sphinx deprecation warning in docs build. (#2721) (#2725) https://github.com/python/cpython/commit/64a9f3d961084819335ea011063eb8cb41733882 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 16 01:49:40 2017 From: report at bugs.python.org (Ammar Askar) Date: Sun, 16 Jul 2017 05:49:40 +0000 Subject: [docs] [issue30937] csv module examples miss newline='' when opening files In-Reply-To: <1500130085.47.0.354601054193.issue30937@psf.upfronthosting.co.za> Message-ID: <1500184180.79.0.720858394084.issue30937@psf.upfronthosting.co.za> Changes by Ammar Askar : ---------- pull_requests: +2790 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 16 01:50:47 2017 From: report at bugs.python.org (Ammar Askar) Date: Sun, 16 Jul 2017 05:50:47 +0000 Subject: [docs] [issue30937] csv module examples miss newline='' when opening files In-Reply-To: <1500130085.47.0.354601054193.issue30937@psf.upfronthosting.co.za> Message-ID: <1500184247.89.0.955732369064.issue30937@psf.upfronthosting.co.za> Changes by Ammar Askar : ---------- keywords: +easy, patch stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 16 03:15:01 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 16 Jul 2017 07:15:01 +0000 Subject: [docs] [issue30466] Tutorial doesn't explain the use of classes In-Reply-To: <1495666720.41.0.650692797283.issue30466@psf.upfronthosting.co.za> Message-ID: <1500189301.41.0.694500704499.issue30466@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Apparently this was committed without my review. ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 16 03:49:04 2017 From: report at bugs.python.org (Mandeep Singh) Date: Sun, 16 Jul 2017 07:49:04 +0000 Subject: [docs] [issue30935] document the new behavior of get_event_loop() in Python 3.6 In-Reply-To: <1500084221.73.0.556830879215.issue30935@psf.upfronthosting.co.za> Message-ID: <1500191344.59.0.248027494322.issue30935@psf.upfronthosting.co.za> Changes by Mandeep Singh : ---------- pull_requests: +2791 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 16 12:51:58 2017 From: report at bugs.python.org (George K) Date: Sun, 16 Jul 2017 16:51:58 +0000 Subject: [docs] [issue30940] Documentation for round() is incorrect. Message-ID: <1500223918.38.0.72996478594.issue30940@psf.upfronthosting.co.za> New submission from George K: The documentation for round states "The return value is an integer if called with one argument, otherwise of the same type as number." This is not the case if the second argument is None. ---------- assignee: docs at python components: Documentation messages: 298442 nosy: George K, docs at python priority: normal severity: normal status: open title: Documentation for round() is incorrect. versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 16 13:16:36 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 16 Jul 2017 17:16:36 +0000 Subject: [docs] [issue30940] Documentation for round() is incorrect. In-Reply-To: <1500223918.38.0.72996478594.issue30940@psf.upfronthosting.co.za> Message-ID: <1500225396.87.0.892603389852.issue30940@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In 3.4 round() doesn't accept None as ndigits argument. The behavior was changed by issue19933 and issue27936. Wasn't this change a mistake? Seems Mark opposed to it. ---------- nosy: +mark.dickinson, rhettinger, serhiy.storchaka, steve.dower versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 16 14:24:33 2017 From: report at bugs.python.org (=?utf-8?q?Luc_Boug=C3=A9?=) Date: Sun, 16 Jul 2017 18:24:33 +0000 Subject: [docs] [issue30941] Missing line in example program Message-ID: <1500229473.42.0.394287716986.issue30941@psf.upfronthosting.co.za> New submission from Luc Boug?: On page , the following program is listed. It raises a syntactic error. An empty line is missing after "... n += val" to close the loop body. >>> # iteration >>> n = 0 >>> for val in values: ... n += val >>> print(n) 504 ---------- assignee: docs at python components: Documentation messages: 298445 nosy: docs at python, lucbouge priority: normal severity: normal status: open title: Missing line in example program type: resource usage versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 16 15:33:16 2017 From: report at bugs.python.org (R. David Murray) Date: Sun, 16 Jul 2017 19:33:16 +0000 Subject: [docs] [issue30941] Missing line in example program In-Reply-To: <1500229473.42.0.394287716986.issue30941@psf.upfronthosting.co.za> Message-ID: <1500233596.59.0.226457226159.issue30941@psf.upfronthosting.co.za> R. David Murray added the comment: This is the standard way that we write examples. Sprinkling in extra blank lines everywhere would make the examples less readable. One you've learned how the command interpreter works, the examples are clear, so you each beginner only has to learn this once (and I believe it is explained in the tutorial, though I haven't checked). ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed type: resource usage -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 16 17:23:52 2017 From: report at bugs.python.org (Brett Cannon) Date: Sun, 16 Jul 2017 21:23:52 +0000 Subject: [docs] [issue30939] Sphinx 1.6.3 deprecation warning for sphinx.util.compat.Directive in docs builds In-Reply-To: <1500146353.65.0.778877813503.issue30939@psf.upfronthosting.co.za> Message-ID: Brett Cannon added the comment: I wonder if we should pin sphinx directly instead of the approximate pin we have now to prevent this sort of thing in the future? I had figured they wouldn't introduce a new warning in a bugfix release but I was wrong in that assumption. On Sat, Jul 15, 2017, 12:19 Ned Deily, wrote: > > New submission from Ned Deily: > > [..]/sphinx/util/compat.py:40: RemovedInSphinx17Warning: > sphinx.util.compat.Directive is deprecated and will be removed in Sphinx > 1.7, please use docutils' instead. > RemovedInSphinx17Warning) > > The solution is to import Directive directly from docutils. PR to follow > for master, needs to be cherrypicked to all maintenance branches and, > ideally, all current security-only branches. > > ---------- > assignee: docs at python > components: Documentation > messages: 298401 > nosy: brett.cannon, docs at python, larry, ned.deily > priority: normal > severity: normal > stage: patch review > status: open > title: Sphinx 1.6.3 deprecation warning for sphinx.util.compat.Directive > in docs builds > versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, > Python 3.7 > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 17 01:55:01 2017 From: report at bugs.python.org (Ned Deily) Date: Mon, 17 Jul 2017 05:55:01 +0000 Subject: [docs] [issue30939] Sphinx 1.6.3 deprecation warning for sphinx.util.compat.Directive in docs builds In-Reply-To: <1500146353.65.0.778877813503.issue30939@psf.upfronthosting.co.za> Message-ID: <1500270901.55.0.428336159058.issue30939@psf.upfronthosting.co.za> Ned Deily added the comment: > I wonder if we should pin sphinx directly instead of the approximate pin we > have now to prevent this sort of thing in the future? Perhaps. OTOH, we will find out about Sphinx incompatibilities pretty quickly that way, rather than having doc builds potentially silently fail or only finding out about the problem at release time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 17 03:17:00 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 17 Jul 2017 07:17:00 +0000 Subject: [docs] [issue30940] Documentation for round() is incorrect. In-Reply-To: <1500223918.38.0.72996478594.issue30940@psf.upfronthosting.co.za> Message-ID: <1500275820.45.0.328303262358.issue30940@psf.upfronthosting.co.za> Mark Dickinson added the comment: [Serhiy] > Wasn't this change a mistake? Seems Mark opposed to it. Shrug. It seemed unnecessary to me to explicitly support `None` as a second argument, but it's done now; reverting the change at this point would do more harm than good. So indeed there's a minor inaccuracy in the docs here. I'd suggest replacing the sentence identified with: "The return value is an integer if *ndigits* is omitted or *None*. Otherwise the return value has the same type as *number*." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 17 04:19:55 2017 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Mon, 17 Jul 2017 08:19:55 +0000 Subject: [docs] [issue18558] Iterable glossary entry needs clarification In-Reply-To: <1374796651.89.0.668716719647.issue18558@psf.upfronthosting.co.za> Message-ID: <1500279595.27.0.106413871167.issue18558@psf.upfronthosting.co.za> Vedran ?a?i? added the comment: I think this is backwards. "Refusing the temptation to guess" in this case can mean returning True for is_iterable. After all, we can always have something like class Deceptive: def __iter__(self): raise TypeError("I'm not really iterable") and it's not the business of instancecheck to actually iterate (either via __iter__, or __getitem__). Its task is to check whether it has a corresponding attribute (not set to None, per the new convention of explicitly disabling protocols). It could be different if the "old __getitem__ iteration" was deprecated, or at least scheduled to be deprecated, but as far as I can tell, it isn't. (It really should be documented if it were so.) _At least_, the documentation of https://docs.python.org/3/library/collections.abc.html#collections.abc.Iterable should be more precise in saying (instead of just "See also the definition of iterable.") something like "Note that the definition of iterable in the glossary is more general than what this method checks, by design / omission / backward compatibility / apathy / whatever." (Ok, the last part might be too much. But it's essential to point out the things are different, and whether it's meant to stay that way.) ---------- nosy: +veky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 17 08:51:48 2017 From: report at bugs.python.org (R. David Murray) Date: Mon, 17 Jul 2017 12:51:48 +0000 Subject: [docs] [issue18558] Iterable glossary entry needs clarification In-Reply-To: <1374796651.89.0.668716719647.issue18558@psf.upfronthosting.co.za> Message-ID: <1500295908.3.0.045037365791.issue18558@psf.upfronthosting.co.za> R. David Murray added the comment: No, refusing to guess in this case is to believe the class's declaration that it is an iterable if (and only if) it defines __iter__, which is the modern definition of iterable. If that doesn't work when the object is iterated, that's a bug in the class claiming to be an iterable when it isn't. The confusion here is the existence of the older iteration protocol. As you say, the documentation can use some improvement. Eventually someone will submit a proposal in the form of a PR and we can hammer out the exact wording. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 17 09:05:27 2017 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Mon, 17 Jul 2017 13:05:27 +0000 Subject: [docs] [issue18558] Iterable glossary entry needs clarification In-Reply-To: <1374796651.89.0.668716719647.issue18558@psf.upfronthosting.co.za> Message-ID: <1500296727.07.0.961781079469.issue18558@psf.upfronthosting.co.za> Vedran ?a?i? added the comment: Of course. The Deceptive class was just reductio ad absurdum. I'm all for believing the class through what attributes does it expose. We agree there. Where we don't agree, is _what_ attributes constitute the iteration protocol. You, the source code and the documentation of the collections.abc.Iterable say one thing (__iter__), while I, the current version of Python (at least CPython, but I think other implementations do the same) and the glossary say another thing (__iter__ or __getitem__). [It's not the only protocol consisting of two attributes... e.g. bool protocol also consists of two attributes, __bool__ and __len__ (though it is not optional, so we don't have collections.abc.Boolable).] You seem to say that only the glossary needs fixing. But then we'll be in an even more weird position, where we must say some objects can be iterated, but are not iterables. I'm pretty sure you don't want that. The whole point of "Xable" words (e.g. "callable", as opposed to "function") is that it encompasses everything that can be Xed, not only the first thing that comes to mind (e.g. classes can also be called). Or are you saying that after the glossary is fixed, then we should fix Python by (at least deprecating, if not) forbidding __getitem__ iteration? I'm not sure that this is the consensus. Are you? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 17 10:30:24 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 17 Jul 2017 14:30:24 +0000 Subject: [docs] [issue18558] Iterable glossary entry needs clarification In-Reply-To: <1374796651.89.0.668716719647.issue18558@psf.upfronthosting.co.za> Message-ID: <1500301824.6.0.704360364517.issue18558@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The wold "iterable" just means "can be looped over". There are many ways to implement this capability (two-arg form of iter(), the __iter__ method, generators, __getitem__ with integer indexing, etc). collections.abc.Iterable is more limited and that is okay. There is nothing that compels us to break an API has been around and successful for 26+ years. That clearly wasn't Guido's intention when he added collections.abc.Iterable which is just a building block for more complex ABCs. I recommend closing this. We're not going to kill a useful API and break tons of code because of an overly pedantic reading of what is allowed to be iterable. However we can make a minor amendment to the glossary entry to mention that there are multiple ways of becoming iterable. Stephen, the try/except is a reasonable way to recognize an iterable. The ABCs are intended to recognize only things that implement a particular implementation or that are registered. It is not more encompassing or normative than that. ---------- assignee: docs at python -> rhettinger nosy: +rhettinger versions: +Python 3.7 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 17 10:35:03 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 17 Jul 2017 14:35:03 +0000 Subject: [docs] [issue30940] Documentation for round() is incorrect. In-Reply-To: <1500223918.38.0.72996478594.issue30940@psf.upfronthosting.co.za> Message-ID: <1500302103.26.0.544235218569.issue30940@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Wasn't this change a mistake? Now that it is deployed, it should probably be left alone (it is has to take back an API change), but this should be a cautionary note for arg-clinic enthusiasts to not change existing APIs. When Argument Clinic is too limited to express what Python does for an exiting API, that particular function needs to be skipped. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 17 10:40:33 2017 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Mon, 17 Jul 2017 14:40:33 +0000 Subject: [docs] [issue18558] Iterable glossary entry needs clarification In-Reply-To: <1374796651.89.0.668716719647.issue18558@psf.upfronthosting.co.za> Message-ID: <1500302433.17.0.736481836028.issue18558@psf.upfronthosting.co.za> Vedran ?a?i? added the comment: Raymond, I think you didn't understand the issue. Glossary already _has_ the ammendment you mention (at least for the __getitem__ - I'm not sure any of other examples you mention are counterexamples to that interpretation: callable_iterators and generators _do_ have an __iter__ attribute, and they are correctly detected as instances of collections.abc.Iterable). I wanted to push in the _opposite_ direction, to fully bless __getitem__ as a way to declare iterability, so it could be recognized by Iterable's instancecheck. Because it seems to me that whoever wrote that instancecheck, didn't have the _intention_ to exclude __getitem__ iteration. Or at least, if we cannot do that because of backward compatibility:-(, to explicitly document that Iterable ABC _does not_ fully encompass what we mean by "being iterable". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 17 11:05:53 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 17 Jul 2017 15:05:53 +0000 Subject: [docs] [issue18558] Iterable glossary entry needs clarification In-Reply-To: <1374796651.89.0.668716719647.issue18558@psf.upfronthosting.co.za> Message-ID: <1500303953.75.0.399739379585.issue18558@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Or at least, if we cannot do that because of backward > compatibility:-(, to explicitly document that Iterable ABC > _does not_ fully encompass what we mean by "being iterable". That would be a reasonable amendment to collections.abc.Iterable docs. I don't think it is either desirable or possible for collections.abc.Iterable to recognize iterables with __getitem__. We cannot know it advance whether __getitem__ is a mapping or a sequence. IIRC, that particular problem was the motivation for creating the ABCs. Without a user registering a class as Iterable or without inheriting from Iterable, there is really no way to know. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 17 11:33:17 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 17 Jul 2017 15:33:17 +0000 Subject: [docs] [issue30940] Documentation for round() is incorrect. In-Reply-To: <1500223918.38.0.72996478594.issue30940@psf.upfronthosting.co.za> Message-ID: <1500305597.92.0.736641395842.issue30940@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: round() was not converted to Argument Clinic. There is a special comment about this: /* AC: cannot convert yet, as needs PEP 457 group support in inspect * or a semantic change to accept None for "ndigits" */ *Now* round() can be converted to Argument Clinic. I prepared a patch for this but wanted to make sure this is a desirable behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 17 11:39:44 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 17 Jul 2017 15:39:44 +0000 Subject: [docs] [issue30940] Documentation for round() is incorrect. In-Reply-To: <1500223918.38.0.72996478594.issue30940@psf.upfronthosting.co.za> Message-ID: <1500305984.5.0.550065986219.issue30940@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > I prepared a patch for this but wanted to make sure this is a desirable behavior. That seems reasonable to me. Mark, what do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 17 11:47:49 2017 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Mon, 17 Jul 2017 15:47:49 +0000 Subject: [docs] [issue18558] Iterable glossary entry needs clarification In-Reply-To: <1374796651.89.0.668716719647.issue18558@psf.upfronthosting.co.za> Message-ID: <1500306469.28.0.0276437456661.issue18558@psf.upfronthosting.co.za> Vedran ?a?i? added the comment: Yes, the mapping/sequence distinction was (at least declaratively) the reason the ABCs were introduced, but that isn't an obstacle here: whether a mapping or a sequence, it _is_ iterable, right? --- In case anybody is interested, here's how I came to this problem: at a programming competition, I set a problem where contestants had to write some function, and I declared that "the function must work for arbitrary iterable (with some properties that currently don't matter)". Then a big discussion ensued, with a big group of people thinking that classes with __getitem__ but no __iter__ don't quality (giving collections.abc.Iterable as an argument), and another big group of people thinking they do (giving EAFP as an argument: "look, I tried iterating, and succeeded"). Of course, it's an incredibly technical detail, but I don't like such gray areas. To me, things with __getitem__ are clearly iterable - the glossary says so:-). Iterable's instancecheck is simply buggy ("incomplete", if you want). There might be valid reasons for keeping it buggy, but they should be documented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 17 13:11:19 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 17 Jul 2017 17:11:19 +0000 Subject: [docs] [issue30940] Documentation for round() is incorrect. In-Reply-To: <1500223918.38.0.72996478594.issue30940@psf.upfronthosting.co.za> Message-ID: <1500311479.55.0.878274864572.issue30940@psf.upfronthosting.co.za> Mark Dickinson added the comment: Sure, fine with me to add AC support for round. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 17 13:26:34 2017 From: report at bugs.python.org (R. David Murray) Date: Mon, 17 Jul 2017 17:26:34 +0000 Subject: [docs] [issue18558] Iterable glossary entry needs clarification In-Reply-To: <1374796651.89.0.668716719647.issue18558@psf.upfronthosting.co.za> Message-ID: <1500312394.58.0.852729177454.issue18558@psf.upfronthosting.co.za> R. David Murray added the comment: "things with __getitem__ are clearly iterable" This is false. IMO it should be fixed in the glossary. It should say "or __getitem__ method implementing sequence semantics". That plus the addition to the Iterable docs will close this issue. ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 17 13:29:35 2017 From: report at bugs.python.org (Alex Vig) Date: Mon, 17 Jul 2017 17:29:35 +0000 Subject: [docs] [issue30951] Documentation error in inspect module Message-ID: <1500312575.69.0.52467451771.issue30951@psf.upfronthosting.co.za> New submission from Alex Vig: The documentation for co_names in the inspect module is: "tuple of names of local variables" Local variable names are however in co_varnames while co_names contains global variable names. This description should read: "tuple of names of global variables" Relevant StackOverflow post here: https://stackoverflow.com/q/45147260/1953800 ---------- assignee: docs at python components: Documentation messages: 298545 nosy: Alex Vig, docs at python priority: normal severity: normal status: open title: Documentation error in inspect module versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 17 15:01:45 2017 From: report at bugs.python.org (Alex) Date: Mon, 17 Jul 2017 19:01:45 +0000 Subject: [docs] [issue30951] Documentation error in inspect module In-Reply-To: <1500312575.69.0.52467451771.issue30951@psf.upfronthosting.co.za> Message-ID: <1500318105.16.0.189212571572.issue30951@psf.upfronthosting.co.za> Changes by Alex : ---------- pull_requests: +2802 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 17 15:38:27 2017 From: report at bugs.python.org (Alex) Date: Mon, 17 Jul 2017 19:38:27 +0000 Subject: [docs] [issue30951] Documentation error in inspect module In-Reply-To: <1500312575.69.0.52467451771.issue30951@psf.upfronthosting.co.za> Message-ID: <1500320307.65.0.414491745012.issue30951@psf.upfronthosting.co.za> Changes by Alex : ---------- pull_requests: +2803 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 17 15:43:02 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 17 Jul 2017 19:43:02 +0000 Subject: [docs] [issue18558] Iterable glossary entry needs clarification In-Reply-To: <1374796651.89.0.668716719647.issue18558@psf.upfronthosting.co.za> Message-ID: <1500320582.74.0.673160767114.issue18558@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The problem with the Iterable ABC is that 'iterable' and 'iterator' are *dynamically* defined, with a possibly infinite time required to possibly destructively check either definition. In general, an algorithmic *static* check can only guess whether an object is iterable, though humans analyzing enough code can potentially get it right. Therefore, using isinstance(ob, Iterable) is not 100% reliable, and in my opinion *should not be used* as the definition of lower-case 'iterable'. Definition: Object ob is iterable if 'iter(ob)' returns an iterator. For the reasons given above, iter may return a non-iterator, but it will if ob implements either the old or new iterator protocol. If ob has .__iter__, iter returns ob.__iter__(). If ob has .__getitem__, iter returns iterator(ob), where iterator is a hidden internal class that embodies the old iterator protocol by defining a .__next__ method that calls .__getitem__. In both cases, iter does the best it can by assuming that the methods are correctly written as per one of the two protocols. Loose definition: Object 'it' is iterable if it can be looped over. Python definition: Object 'it' is iterable if repeated 'next(it)' calls either return an object or raise StopIteration. This means that try: while True: next(it) except StopIteration: pass runs, possibly forever, without raising. As Raymond noted, an iterator can be created multiple ways: IteratorClass(), iter(ob), iter(func, sentinal), generator_func(). --- Iterable versus iter with respect to classes with __getitem__: Iter was added in 2.2. Built-in iterables were only gradually converted from old to new protocol, by adding a new .__iter__. So even ignoring user classes, iter *had* to respect .__getitem__. Even today, though only a small fraction of classes with .__getitem__ are iterable, people do not generally call iter() on random objects. Iterable (added 2.6) is documented as the "ABC for classes that provide the __iter__() method." In other words, isinstance(ob, Iterable) replaces hasattr(ob, '__iter__'). Except that the former is more than that. The magic word 'register' does not appear in the collections.ABC doc, and I think that this is the omission to be remedied. "ABC for classes that provide the __iter__() method, or that provide a __getitem__ method that implements the old iterator protocol and register themselves as Iterable." An example could be given using a patched version of IsIterable. If one adds two lines of code from collections.abc import Iterable ... Iterable.register(IsIterable) then isinstance(IsIterable(3), Iterable) is True, except that this is a lie in the other direction. Traceback (most recent call last): File "F:\Python\mypy\tem.py", line 17, in for i in it2: File "F:\Python\mypy\tem.py", line 7, in __getitem__ return self.data[key] TypeError: 'int' object is not subscriptable Either IsIterable.__init__ must check that data itself has .__getitem__ or IsIterable.__next__ must capture exceptions and raise IndexError instead. def __getitem__(self, key): try: return self.data[key] except Exception: raise IndexError ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 18 09:47:28 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 18 Jul 2017 13:47:28 +0000 Subject: [docs] [issue30940] Documentation for round() is incorrect. In-Reply-To: <1500223918.38.0.72996478594.issue30940@psf.upfronthosting.co.za> Message-ID: <1500385648.18.0.649123288341.issue30940@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please make a PR for your suggestion Mark? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 18 11:21:12 2017 From: report at bugs.python.org (R. David Murray) Date: Tue, 18 Jul 2017 15:21:12 +0000 Subject: [docs] [issue30940] Documentation for round() is incorrect. In-Reply-To: <1500223918.38.0.72996478594.issue30940@psf.upfronthosting.co.za> Message-ID: <1500391272.72.0.68279400082.issue30940@psf.upfronthosting.co.za> R. David Murray added the comment: We don't need to burden Mark with doing a PR for this (unless he wants to). This is a good new contributer practice issue :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 18 11:24:54 2017 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 18 Jul 2017 15:24:54 +0000 Subject: [docs] [issue30940] Documentation for round() is incorrect. In-Reply-To: <1500223918.38.0.72996478594.issue30940@psf.upfronthosting.co.za> Message-ID: <1500391494.41.0.776702426936.issue30940@psf.upfronthosting.co.za> Mark Dickinson added the comment: Serhiy: I thought your GitHub PR (https://github.com/python/cpython/pull/2740) already included the new wording? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 18 11:25:50 2017 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 18 Jul 2017 15:25:50 +0000 Subject: [docs] [issue30940] Documentation for round() is incorrect. In-Reply-To: <1500223918.38.0.72996478594.issue30940@psf.upfronthosting.co.za> Message-ID: <1500391550.43.0.545289901577.issue30940@psf.upfronthosting.co.za> Mark Dickinson added the comment: Ah, sorry; I see. That was just for the docstring, not for the docs. My bad. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 18 20:48:01 2017 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 19 Jul 2017 00:48:01 +0000 Subject: [docs] [issue30964] Mention ensurepip in package installation docs Message-ID: <1500425281.82.0.79058660024.issue30964@psf.upfronthosting.co.za> New submission from Nick Coghlan: The package installation docs at https://github.com/python/cpython/blob/master/Doc/installing/index.rst have a section on "Common Installation Issues": https://docs.python.org/3/installing/#common-installation-issues A new entry should be added to this section to cover the case where pip isn't installed by default (e.g. because it was deselected when running the installer), and to suggest trying "python -m ensurepip --default-pip" as a potential remedy. ---------- assignee: docs at python components: Documentation keywords: easy messages: 298622 nosy: docs at python, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Mention ensurepip in package installation docs type: enhancement versions: Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 19 01:20:50 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 19 Jul 2017 05:20:50 +0000 Subject: [docs] [issue11230] "Full unicode import system" not in 3.2 In-Reply-To: <1297926635.95.0.756299771372.issue11230@psf.upfronthosting.co.za> Message-ID: <1500441650.36.0.117693471287.issue11230@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Python 3.2 is out of maintenance. Full Unicode path support was added in Python 3.3 by issue3080. ---------- nosy: +serhiy.storchaka resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 19 04:49:57 2017 From: report at bugs.python.org (Marco Buttu) Date: Wed, 19 Jul 2017 08:49:57 +0000 Subject: [docs] [issue30951] Documentation error in inspect module In-Reply-To: <1500312575.69.0.52467451771.issue30951@psf.upfronthosting.co.za> Message-ID: <1500454197.58.0.941187427013.issue30951@psf.upfronthosting.co.za> Marco Buttu added the comment: Or maybe: "tuple of names of global variables used in the bytecode" ---------- nosy: +marco.buttu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 19 07:55:53 2017 From: report at bugs.python.org (Antti Haapala) Date: Wed, 19 Jul 2017 11:55:53 +0000 Subject: [docs] [issue30969] Docs should say that `x is z or x == z` is used for `x in y` in containers that do not implement `__contains__` Message-ID: <1500465353.64.0.619810995706.issue30969@psf.upfronthosting.co.za> New submission from Antti Haapala: The doc reference/expressions.srt says that > For user-defined classes which do not define __contains__() but do > define __iter__(), x in y is True if some value z with x == z is > produced while iterating over y. If an exception is raised during the > iteration, it is as if in raised that exception. and > Lastly, the old-style iteration protocol is tried: if a class defines > __getitem__(), x in y is True if and only if there is a non-negative > integer index i such that x == y[i], and all lower integer indices do > not raise IndexError exception. (If any other exception is raised, it > is as if in raised that exception). The documentation doesn't match the implementation, which clearly does `x is y or x == y` to check if `x` is the element `y` from a container. Both the `__iter__` and the index-iteration method test the elements using `is` first. While the document says that `x is x` means that `x == x` should be true, it is not true for example in the case of `nan`: ---------- assignee: docs at python components: Documentation messages: 298671 nosy: docs at python, ztane priority: normal severity: normal status: open title: Docs should say that `x is z or x == z` is used for `x in y` in containers that do not implement `__contains__` type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 19 07:57:57 2017 From: report at bugs.python.org (Antti Haapala) Date: Wed, 19 Jul 2017 11:57:57 +0000 Subject: [docs] [issue30969] Docs should say that `x is z or x == z` is used for `x in y` in containers that do not implement `__contains__` In-Reply-To: <1500465353.64.0.619810995706.issue30969@psf.upfronthosting.co.za> Message-ID: <1500465477.88.0.472782705383.issue30969@psf.upfronthosting.co.za> Changes by Antti Haapala : ---------- pull_requests: +2820 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 19 10:07:31 2017 From: report at bugs.python.org (R. David Murray) Date: Wed, 19 Jul 2017 14:07:31 +0000 Subject: [docs] [issue30969] Docs should say that `x is z or x == z` is used for `x in y` in containers that do not implement `__contains__` In-Reply-To: <1500465353.64.0.619810995706.issue30969@psf.upfronthosting.co.za> Message-ID: <1500473251.12.0.106904820094.issue30969@psf.upfronthosting.co.za> R. David Murray added the comment: I think you change is appropriate given that the "equivalent to" for the built in iterators contains the 'is' expression. However, I also think we should drop that second whole paragraph, and in the previous paragraph say "...but are :term:`iterable`...". Because conceptually what we do is iterate whatever we're given if iter doesn't return a TypeError, and it is iter that handles the fallback to the older __getitem__ protocol. I don't see why we should re-explain the iteration protocol in the docs for 'in'. (I haven't looked at how this is actually implemented, but the implementation ought to be equivalent to that or we will eventually run into bugs.) I don't think this would result in any loss of precision or understandability, and in fact I think it would make it easier to understand. See also issue 27605, which also wants to edit this section slightly. ---------- nosy: +r.david.murray, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 19 15:14:25 2017 From: report at bugs.python.org (Joshua Jay Herman) Date: Wed, 19 Jul 2017 19:14:25 +0000 Subject: [docs] [issue24459] Mention PYTHONFAULTHANDLER in the man page In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za> Message-ID: <1500491665.67.0.311340446429.issue24459@psf.upfronthosting.co.za> Joshua Jay Herman added the comment: Was this ever merged? I'm not sure whats happening. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 20 00:24:39 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 20 Jul 2017 04:24:39 +0000 Subject: [docs] [issue30940] Documentation for round() is incorrect. In-Reply-To: <1500223918.38.0.72996478594.issue30940@psf.upfronthosting.co.za> Message-ID: <1500524679.01.0.205400549756.issue30940@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The documentation should be updated before converting round() to Argument Clinic, because this update should be backported to 3.6 and 3.5, while the conversion can be made only in 3.7. ---------- keywords: +easy stage: -> needs patch _______________________________________ Python tracker _______________________________________ From bogdansrc at gmail.com Mon Jul 17 15:41:14 2017 From: bogdansrc at gmail.com (Bogdan Popescu) Date: Mon, 17 Jul 2017 22:41:14 +0300 Subject: [docs] Python 3.6.2 download links broken Message-ID: <22607707-8206-485D-A33F-86296D6CC933@gmail.com> Hi, The links for the HTML docs download at https://docs.python.org/3/download.html end up in a 404. Regards, Bogdan -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidhulsmannl at gmail.com Mon Jul 17 08:33:59 2017 From: davidhulsmannl at gmail.com (David) Date: Mon, 17 Jul 2017 14:33:59 +0200 Subject: [docs] Python 3.6 docs download broke Message-ID: All links on https://docs.python.org/3.6/download.html (for python 3.6.2) give me a 404 page. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcorner1953 at gmail.com Mon Jul 17 13:48:30 2017 From: dcorner1953 at gmail.com (Dave C.) Date: Mon, 17 Jul 2017 12:48:30 -0500 Subject: [docs] Can't download 3.6.2 docs -- all links go 404! Message-ID: Please let me know when this is rectified. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From jyjz2008 at alumni.sjtu.edu.cn Wed Jul 19 09:33:40 2017 From: jyjz2008 at alumni.sjtu.edu.cn (=?utf-8?B?6Z2z6Ziz?=) Date: Wed, 19 Jul 2017 21:33:40 +0800 (CST) Subject: [docs] I found a typo on page https://docs.python.org/3/library/turtle.html Message-ID: <796212364.1087992.1500471220818.JavaMail.zimbra@alumni.sjtu.edu.cn> Dear all, I found a typo on page https://docs.python.org/3/library/turtle.html It should be yinyang instead of yingyang The typo appears in section " 24.1.7. turtledemo ? Demo scripts " To prove it is a typo, I run two commands as shown in the following picture. The first one throws one error, (The first command is python3 -m turtledemo.yingyang ) the second one works well. (The second command is python3 -m turtledemo.yinyang ) Best regards, from ?? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 261579.52500000005 Type: image/png Size: 199855 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 355256.49500000005 Type: image/png Size: 132483 bytes Desc: not available URL: From wj2016 at gmail.com Mon Jul 17 04:12:58 2017 From: wj2016 at gmail.com (jia wang) Date: Mon, 17 Jul 2017 10:12:58 +0200 Subject: [docs] 3.6.2 pdf doc missing Message-ID: Hi, Seems the link https://docs.python.org/3.6/archives/python-3.6.2-docs-pdf-a4.zip is missing, it just returns a 404 page. Doc 3.5 works fine. BR, Jia -------------- next part -------------- An HTML attachment was scrubbed... URL: From report at bugs.python.org Thu Jul 20 11:47:15 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 20 Jul 2017 15:47:15 +0000 Subject: [docs] [issue30974] Update os.samefile docstring to match documentation In-Reply-To: <1500538030.77.0.17785692497.issue30974@psf.upfronthosting.co.za> Message-ID: <1500565635.12.0.436640091079.issue30974@psf.upfronthosting.co.za> R. David Murray added the comment: I would take "actual file" as meaning the file the symlink points to, so I'd say the documentation matches the implementation according to your description of the two. The current docs actually say "refer to the same file or directory", and mention os.stat explicitly, so again I'd say the docs and implementation match. It sounds like what you want is to open a feature request for a samefile equivalent that does not follow symlinks. lsamefile? We could use this issue for making the docstring match the docs, though. I think the sentence in the docs is short enough to just get copied into the docstring. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, r.david.murray title: os.samefile / shutil._samefile: following symlinks -> Update os.samefile docstring to match documentation versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 20 12:33:26 2017 From: report at bugs.python.org (John Taylor) Date: Thu, 20 Jul 2017 16:33:26 +0000 Subject: [docs] [issue29284] Include thread_name_prefix in the concurrent.futures.ThreadPoolExecutor example 17.4.2.1 In-Reply-To: <1484584964.59.0.239435362381.issue29284@psf.upfronthosting.co.za> Message-ID: <1500568406.74.0.240949969655.issue29284@psf.upfronthosting.co.za> John Taylor added the comment: Bump ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 20 13:56:51 2017 From: report at bugs.python.org (Nicholas P Kobald) Date: Thu, 20 Jul 2017 17:56:51 +0000 Subject: [docs] [issue30964] Mention ensurepip in package installation docs In-Reply-To: <1500425281.82.0.79058660024.issue30964@psf.upfronthosting.co.za> Message-ID: <1500573411.02.0.620503135176.issue30964@psf.upfronthosting.co.za> Nicholas P Kobald added the comment: Should this section refer to https://packaging.python.org/tutorials/installing-packages/#install-pip-setuptools-and-wheel as well? ---------- nosy: +Nickk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 20 15:13:41 2017 From: report at bugs.python.org (nicholas kobald) Date: Thu, 20 Jul 2017 19:13:41 +0000 Subject: [docs] [issue30964] Mention ensurepip in package installation docs In-Reply-To: <1500425281.82.0.79058660024.issue30964@psf.upfronthosting.co.za> Message-ID: <1500578021.34.0.429739729643.issue30964@psf.upfronthosting.co.za> Changes by nicholas kobald : ---------- pull_requests: +2836 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 20 16:22:26 2017 From: report at bugs.python.org (Cheryl Sabella) Date: Thu, 20 Jul 2017 20:22:26 +0000 Subject: [docs] [issue29284] Include thread_name_prefix in the concurrent.futures.ThreadPoolExecutor example 17.4.2.1 In-Reply-To: <1484584964.59.0.239435362381.issue29284@psf.upfronthosting.co.za> Message-ID: <1500582146.72.0.136118715409.issue29284@psf.upfronthosting.co.za> Cheryl Sabella added the comment: Hi John, Would you be able to make a GitHub pull request for your change? Since CPython development has moved to GitHub, you may have a better chance of a review with a PR. ---------- nosy: +csabella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 20 23:10:59 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Fri, 21 Jul 2017 03:10:59 +0000 Subject: [docs] [issue30466] Tutorial doesn't explain the use of classes In-Reply-To: <1495666720.41.0.650692797283.issue30466@psf.upfronthosting.co.za> Message-ID: <1500606659.0.0.495724190566.issue30466@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: New changeset ef4231adb7aa6b323c94e854ac3dc3bebc841115 by Mariatta (Trey Hunner) in branch '3.6': bpo-30466: Add brief explanation of classes to tutorial (GH-1804) (GH-2700) https://github.com/python/cpython/commit/ef4231adb7aa6b323c94e854ac3dc3bebc841115 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 20 23:11:50 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Fri, 21 Jul 2017 03:11:50 +0000 Subject: [docs] [issue30466] Tutorial doesn't explain the use of classes In-Reply-To: <1495666720.41.0.650692797283.issue30466@psf.upfronthosting.co.za> Message-ID: <1500606710.81.0.696036930726.issue30466@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- resolution: -> fixed stage: backport needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 20 23:51:57 2017 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 21 Jul 2017 03:51:57 +0000 Subject: [docs] [issue30964] Mention ensurepip in package installation docs In-Reply-To: <1500425281.82.0.79058660024.issue30964@psf.upfronthosting.co.za> Message-ID: <1500609117.67.0.764608374186.issue30964@psf.upfronthosting.co.za> Nick Coghlan added the comment: New changeset b3527bfefd7a0188d43a2d7515ac6addd97a8202 by Nick Coghlan (Nicholas) in branch 'master': bpo-30964: Mention ensurepip in package installation docs (GH-2786) https://github.com/python/cpython/commit/b3527bfefd7a0188d43a2d7515ac6addd97a8202 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 20 23:56:57 2017 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 21 Jul 2017 03:56:57 +0000 Subject: [docs] [issue30964] Mention ensurepip in package installation docs In-Reply-To: <1500425281.82.0.79058660024.issue30964@psf.upfronthosting.co.za> Message-ID: <1500609417.74.0.419362762633.issue30964@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- stage: needs patch -> backport needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 21 01:19:36 2017 From: report at bugs.python.org (nicholas kobald) Date: Fri, 21 Jul 2017 05:19:36 +0000 Subject: [docs] [issue30964] Mention ensurepip in package installation docs In-Reply-To: <1500425281.82.0.79058660024.issue30964@psf.upfronthosting.co.za> Message-ID: <1500614376.01.0.774240184014.issue30964@psf.upfronthosting.co.za> Changes by nicholas kobald : ---------- pull_requests: +2842 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 21 01:21:48 2017 From: report at bugs.python.org (nicholas kobald) Date: Fri, 21 Jul 2017 05:21:48 +0000 Subject: [docs] [issue30964] Mention ensurepip in package installation docs In-Reply-To: <1500425281.82.0.79058660024.issue30964@psf.upfronthosting.co.za> Message-ID: <1500614508.34.0.986674636144.issue30964@psf.upfronthosting.co.za> Changes by nicholas kobald : ---------- pull_requests: +2843 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 21 02:18:43 2017 From: report at bugs.python.org (nicholas kobald) Date: Fri, 21 Jul 2017 06:18:43 +0000 Subject: [docs] [issue30964] Mention ensurepip in package installation docs In-Reply-To: <1500425281.82.0.79058660024.issue30964@psf.upfronthosting.co.za> Message-ID: <1500617923.04.0.800922827307.issue30964@psf.upfronthosting.co.za> Changes by nicholas kobald : ---------- pull_requests: +2845 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 21 02:29:46 2017 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 21 Jul 2017 06:29:46 +0000 Subject: [docs] [issue30964] Mention ensurepip in package installation docs In-Reply-To: <1500425281.82.0.79058660024.issue30964@psf.upfronthosting.co.za> Message-ID: <1500618586.49.0.23548386953.issue30964@psf.upfronthosting.co.za> Nick Coghlan added the comment: New changeset 82a77d38d6dc7df740e7b01b66aeff433730e9ca by Nick Coghlan (Nicholas) in branch '2.7': [2.7] bpo-30964: Mention ensurepip in package installation docs (GH-2795) https://github.com/python/cpython/commit/82a77d38d6dc7df740e7b01b66aeff433730e9ca ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 21 02:37:35 2017 From: report at bugs.python.org (nicholas kobald) Date: Fri, 21 Jul 2017 06:37:35 +0000 Subject: [docs] [issue30964] Mention ensurepip in package installation docs In-Reply-To: <1500425281.82.0.79058660024.issue30964@psf.upfronthosting.co.za> Message-ID: <1500619055.31.0.31338580331.issue30964@psf.upfronthosting.co.za> Changes by nicholas kobald : ---------- pull_requests: +2847 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 21 02:44:45 2017 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 21 Jul 2017 06:44:45 +0000 Subject: [docs] [issue30964] Mention ensurepip in package installation docs In-Reply-To: <1500425281.82.0.79058660024.issue30964@psf.upfronthosting.co.za> Message-ID: <1500619485.38.0.933416776385.issue30964@psf.upfronthosting.co.za> Nick Coghlan added the comment: New changeset df5837b5a916aac645087ae02c44e88ff77024ef by Nick Coghlan (Nicholas) in branch '3.6': [3.6] bpo-30964: Mention ensurepip in package installation docs (GH-2797) https://github.com/python/cpython/commit/df5837b5a916aac645087ae02c44e88ff77024ef ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 21 02:45:33 2017 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 21 Jul 2017 06:45:33 +0000 Subject: [docs] [issue30964] Mention ensurepip in package installation docs In-Reply-To: <1500425281.82.0.79058660024.issue30964@psf.upfronthosting.co.za> Message-ID: <1500619533.39.0.769909095846.issue30964@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thanks for the contribution & backports! ---------- stage: backport needed -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 21 03:25:47 2017 From: report at bugs.python.org (nicholas kobald) Date: Fri, 21 Jul 2017 07:25:47 +0000 Subject: [docs] [issue30964] Mention ensurepip in package installation docs In-Reply-To: <1500425281.82.0.79058660024.issue30964@psf.upfronthosting.co.za> Message-ID: <1500621947.2.0.697064730913.issue30964@psf.upfronthosting.co.za> nicholas kobald added the comment: No problem! thanks for the help. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 21 05:20:23 2017 From: report at bugs.python.org (STINNER Victor) Date: Fri, 21 Jul 2017 09:20:23 +0000 Subject: [docs] [issue24459] Mention PYTHONFAULTHANDLER in the man page In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za> Message-ID: <1500628823.72.0.888171120555.issue24459@psf.upfronthosting.co.za> STINNER Victor added the comment: > Was this ever merged? No. > I'm not sure whats happening. Hum, nothing is happening. In december, Berker wrote "Thanks for the updated patch, Joshua. I will review and commit it this week." and then it seems like he found issues, since he proposed a new patch. And then, nothing new happened. Nobody reviewed latest Berker's patch and Berker maybe forgot to push it. Can someone pick a recent patch and convert it to a GitHub PR? Berker, the author of the most recent patch, maybe? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 21 11:24:03 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 21 Jul 2017 15:24:03 +0000 Subject: [docs] [issue30803] Truth value of sets not properly documented In-Reply-To: <1498743378.1.0.0570911503542.issue30803@psf.upfronthosting.co.za> Message-ID: <1500650643.5.0.868089664038.issue30803@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 21 11:32:50 2017 From: report at bugs.python.org (Jelle Zijlstra) Date: Fri, 21 Jul 2017 15:32:50 +0000 Subject: [docs] [issue30984] traceback.print_exc return value documentation Message-ID: <1500651170.07.0.787106480078.issue30984@psf.upfronthosting.co.za> New submission from Jelle Zijlstra: The documentation for traceback.format_tb says "Return a list of ?pre-processed? stack trace entries extracted from the traceback object tb. It is useful for alternate formatting of stack traces. The optional limit argument has the same meaning as for print_tb(). A ?pre-processed? stack trace entry is a 4-tuple (filename, line number, function name, text) representing the information that is usually printed for a stack trace." However, as of 3.5 it actually returns a StackSummary object, which is a subclass of list and contains FrameSummary objects. FrameSummary objects are not tuples. The documentation is accurate for 3.4 and earlier. I'm surprised this change was made because it seems like a compatibility break, but it's too late to do something about that now. The documentation should be changed to correct the return value and add a "versionchanged: 3.5" note. ---------- assignee: docs at python components: Documentation messages: 298807 nosy: Jelle Zijlstra, docs at python priority: normal severity: normal status: open title: traceback.print_exc return value documentation versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 22 15:18:47 2017 From: report at bugs.python.org (Larry Hastings) Date: Sat, 22 Jul 2017 19:18:47 +0000 Subject: [docs] [issue30939] Sphinx 1.6.3 deprecation warning for sphinx.util.compat.Directive in docs builds In-Reply-To: <1500146353.65.0.778877813503.issue30939@psf.upfronthosting.co.za> Message-ID: <1500751127.13.0.581540372541.issue30939@psf.upfronthosting.co.za> Larry Hastings added the comment: New changeset 3b3a5a5b70dc468dcfacb17a3d6b342820b480ff by larryhastings (Ned Deily) in branch '3.4': bpo-30939: Avoid Sphinx deprecation warning in docs build. (#2721) (#2724) https://github.com/python/cpython/commit/3b3a5a5b70dc468dcfacb17a3d6b342820b480ff ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 22 18:03:43 2017 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 22 Jul 2017 22:03:43 +0000 Subject: [docs] [issue17140] Document multiprocessing.pool.ThreadPool In-Reply-To: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za> Message-ID: <1500761023.87.0.526839156249.issue17140@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- assignee: -> docs at python components: +Documentation -Library (Lib) nosy: +docs at python versions: +Python 3.6, Python 3.7 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 23 08:54:41 2017 From: report at bugs.python.org (Mandeep Singh) Date: Sun, 23 Jul 2017 12:54:41 +0000 Subject: [docs] [issue30940] Documentation for round() is incorrect. In-Reply-To: <1500223918.38.0.72996478594.issue30940@psf.upfronthosting.co.za> Message-ID: <1500814481.71.0.906966320115.issue30940@psf.upfronthosting.co.za> Changes by Mandeep Singh : ---------- pull_requests: +2876 _______________________________________ Python tracker _______________________________________ From jpinsky at northwell.edu Fri Jul 21 08:37:48 2017 From: jpinsky at northwell.edu (Pinsky, Jacob) Date: Fri, 21 Jul 2017 08:37:48 -0400 Subject: [docs] Small Improvement to argparse tutorial Message-ID: https://docs.python.org/2/howto/argparse.html#id1 Just a small improvement, unless I am missing it... It's left to the reader of the tutorial to figure out how you tell argparse that an argument is optional, vs. positional. The documentation should clearly state that optional arguments should be indicated as such when calling the .add_argument() method by preceding the name of the argument with two dashes. _______________________ Jacob J. Pinsky Project Manager, IT Radiation Department of Radiation Medcine Center for Advanced Medicine 450 Lakeville Rd Lake Success, NY 11042 Tel: (516) 321-3006 Email: jpinsky at northwell.edu Northwell Health Visit us at Northwell.edu The information contained in this electronic e-mail transmission and any attachments are intended only for the use of the individual or entity to whom or to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this communication is not the intended recipient, or the employee or agent responsible for delivering this communication to the intended recipient, you are hereby notified that any dissemination, distribution, copying or disclosure of this communication and any attachment is strictly prohibited. If you have received this transmission in error, please notify the sender immediately by telephone and electronic mail, and delete the original communication and any attachment from any computer, server or other electronic recording or storage device or medium. Receipt by anyone other than the intended recipient is not a waiver of any attorney-client, physician-patient or other privilege. -------------- next part -------------- An HTML attachment was scrubbed... URL: From report at bugs.python.org Sun Jul 23 19:56:36 2017 From: report at bugs.python.org (Berker Peksag) Date: Sun, 23 Jul 2017 23:56:36 +0000 Subject: [docs] [issue30274] Make importlib.abc.ExtensionFileLoader.__init__() documentation match code In-Reply-To: <1493936689.45.0.0881901800669.issue30274@psf.upfronthosting.co.za> Message-ID: <1500854196.84.0.336088772961.issue30274@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> patch review type: -> enhancement versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 23 20:39:11 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 24 Jul 2017 00:39:11 +0000 Subject: [docs] [issue30456] 2to3 docs: example of fix for duplicates in second argument of isinstance has superfluous parentheses In-Reply-To: <1495629480.46.0.852726762555.issue30456@psf.upfronthosting.co.za> Message-ID: <1500856750.98.0.903136752035.issue30456@psf.upfronthosting.co.za> Berker Peksag added the comment: New changeset 26248ef58dcf49619930ffa2e050ffa687a88601 by Berker Peksag (Eli Boyarski) in branch 'master': bpo-30456: Clarify example for duplicates in second argument of isinstance (GH-1699) https://github.com/python/cpython/commit/26248ef58dcf49619930ffa2e050ffa687a88601 ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 23 20:39:49 2017 From: report at bugs.python.org (Berker Peksag) Date: Mon, 24 Jul 2017 00:39:49 +0000 Subject: [docs] [issue30456] 2to3 docs: example of fix for duplicates in second argument of isinstance has superfluous parentheses In-Reply-To: <1495629480.46.0.852726762555.issue30456@psf.upfronthosting.co.za> Message-ID: <1500856789.45.0.0305618427411.issue30456@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> backport needed type: -> behavior versions: +Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 24 05:02:21 2017 From: report at bugs.python.org (Ned Deily) Date: Mon, 24 Jul 2017 09:02:21 +0000 Subject: [docs] [issue30939] Sphinx 1.6.3 deprecation warning for sphinx.util.compat.Directive in docs builds In-Reply-To: <1500146353.65.0.778877813503.issue30939@psf.upfronthosting.co.za> Message-ID: <1500886941.18.0.472637476051.issue30939@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 24 08:56:01 2017 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 24 Jul 2017 12:56:01 +0000 Subject: [docs] [issue30516] Documentation for datetime substract operation incorrect? In-Reply-To: <1496179333.45.0.413102703331.issue30516@psf.upfronthosting.co.za> Message-ID: <1500900961.75.0.366923359344.issue30516@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I agree. The documentation can be improved here. The note about x - y not being quite the same as x + (-y) belongs to the timedelta - timedelta operation. It should be removed from both date - timedelta and datetime-timedelta footnotes. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python stage: -> needs patch versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 24 12:32:07 2017 From: report at bugs.python.org (Aditya Hase) Date: Mon, 24 Jul 2017 16:32:07 +0000 Subject: [docs] [issue30304] TestCase.assertMultiLineEqual only registered for Unicode strings in 2.7 In-Reply-To: <1494233409.78.0.688533240712.issue30304@psf.upfronthosting.co.za> Message-ID: <1500913927.25.0.678118494481.issue30304@psf.upfronthosting.co.za> Changes by Aditya Hase : ---------- pull_requests: +2891 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 24 12:36:47 2017 From: report at bugs.python.org (Aditya Hase) Date: Mon, 24 Jul 2017 16:36:47 +0000 Subject: [docs] [issue30304] TestCase.assertMultiLineEqual only registered for Unicode strings in 2.7 In-Reply-To: <1494233409.78.0.688533240712.issue30304@psf.upfronthosting.co.za> Message-ID: <1500914207.9.0.0739523880405.issue30304@psf.upfronthosting.co.za> Aditya Hase added the comment: Hi, I'm new to python development community. I've created a GitHub PR that fixes this issue. ---------- nosy: +adityahase _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 24 12:58:04 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Mon, 24 Jul 2017 16:58:04 +0000 Subject: [docs] [issue30304] TestCase.assertMultiLineEqual only registered for Unicode strings in 2.7 In-Reply-To: <1494233409.78.0.688533240712.issue30304@psf.upfronthosting.co.za> Message-ID: <1500915484.87.0.162803621094.issue30304@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- stage: needs patch -> patch review versions: +Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 24 13:02:12 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 24 Jul 2017 17:02:12 +0000 Subject: [docs] [issue30304] TestCase.assertMultiLineEqual only registered for Unicode strings in 2.7 In-Reply-To: <1494233409.78.0.688533240712.issue30304@psf.upfronthosting.co.za> Message-ID: <1500915732.47.0.695357420405.issue30304@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is related only to 2.7. All correct in 3.x. ---------- nosy: +serhiy.storchaka versions: -Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 24 13:07:21 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Mon, 24 Jul 2017 17:07:21 +0000 Subject: [docs] [issue30304] TestCase.assertMultiLineEqual only registered for Unicode strings in 2.7 In-Reply-To: <1494233409.78.0.688533240712.issue30304@psf.upfronthosting.co.za> Message-ID: <1500916040.95.0.937488062201.issue30304@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks Serhiy. Aditya, your PR was made against the master branch. Can you make the change against the 2.7 branch? Thanks. ---------- nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 24 13:10:02 2017 From: report at bugs.python.org (Aditya Hase) Date: Mon, 24 Jul 2017 17:10:02 +0000 Subject: [docs] [issue30304] TestCase.assertMultiLineEqual only registered for Unicode strings in 2.7 In-Reply-To: <1494233409.78.0.688533240712.issue30304@psf.upfronthosting.co.za> Message-ID: <1500916202.71.0.111473745239.issue30304@psf.upfronthosting.co.za> Changes by Aditya Hase : ---------- pull_requests: +2893 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 24 13:16:47 2017 From: report at bugs.python.org (Aditya Hase) Date: Mon, 24 Jul 2017 17:16:47 +0000 Subject: [docs] [issue30304] TestCase.assertMultiLineEqual only registered for Unicode strings in 2.7 In-Reply-To: <1494233409.78.0.688533240712.issue30304@psf.upfronthosting.co.za> Message-ID: <1500916607.43.0.466980239566.issue30304@psf.upfronthosting.co.za> Aditya Hase added the comment: I've fixed that. ---------- versions: +Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 24 13:32:19 2017 From: report at bugs.python.org (Aditya Hase) Date: Mon, 24 Jul 2017 17:32:19 +0000 Subject: [docs] [issue22062] Fix pathlib.Path.(r)glob doc glitches. In-Reply-To: <1406239862.0.0.293742999811.issue22062@psf.upfronthosting.co.za> Message-ID: <1500917539.2.0.0107723786354.issue22062@psf.upfronthosting.co.za> Aditya Hase added the comment: Should I create a Github PR with given patch? If so, how do I give credit to the original author? ---------- nosy: +adityahase _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 24 13:32:23 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 24 Jul 2017 17:32:23 +0000 Subject: [docs] [issue30304] TestCase.assertMultiLineEqual only registered for Unicode strings in 2.7 In-Reply-To: <1494233409.78.0.688533240712.issue30304@psf.upfronthosting.co.za> Message-ID: <1500917543.95.0.690587400607.issue30304@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: -Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 24 13:46:55 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Mon, 24 Jul 2017 17:46:55 +0000 Subject: [docs] [issue22062] Fix pathlib.Path.(r)glob doc glitches. In-Reply-To: <1406239862.0.0.293742999811.issue22062@psf.upfronthosting.co.za> Message-ID: <1500918415.28.0.585621729049.issue22062@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Aditya: The guideline for converting a patch to the PR is documented here: https://devguide.python.org/pullrequest/#converting-an-existing-patch-from-the-b-p-o-to-github ---------- nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 24 13:59:31 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 24 Jul 2017 17:59:31 +0000 Subject: [docs] [issue22062] Fix pathlib.Path.(r)glob doc glitches. In-Reply-To: <1406239862.0.0.293742999811.issue22062@psf.upfronthosting.co.za> Message-ID: <1500919171.11.0.686154576732.issue22062@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Since Mike has not responded in more that a week, please go ahead. Just put "?Original patch by Mike Short." in the commit comments (if you can, otherwise add a separate comment). Please add News blurb (see devguide) if you know how, with at least a title line. Mike has signed the CLA, though it would not matter here since his patch is taken from my message and could be classed as trivial. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 24 17:50:50 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 24 Jul 2017 21:50:50 +0000 Subject: [docs] [issue31021] Clarify programming faq. Message-ID: <1500933050.31.0.733502304217.issue31021@psf.upfronthosting.co.za> New submission from Terry J. Reedy: https://docs.python.org/3/faq/programming.html#why-does-22-10-return-3 "Why does -22 // 10 return -3? It?s primarily driven by the desire that i % j have the same sign as j. If you want that, and also want: i == (i // j) * j + (i % j) then integer division has to return the floor. C also requires that identity to hold, and then compilers that truncate i // j need to make i % j have the same sign as i. There are few real use cases for i % j when j is negative. When j is positive, there are many, and in virtually all of them it?s more useful for i % j to be >= 0. If the clock says 10 now, what did it say 200 hours ago? -190 % 12 == 2 is useful; -190 % 12 == -10 is a bug waiting to bite." A user noticed that '-190 % 12 == -10' is False, but would be True is '-' were inserted before '12', and posted https://github.com/python/cpython/pull/2768 to correct the presumed typo. It is not a typo, and I will close the issue, but the text as is is confusing. I propose replace "-190 % 12 == -10 is" with "if -190 % 12 were the mathematically equivalent -10, it would be" [a bug waiting to bite]. I don't like the 'bug' part because it would not be a bug, exactly, but it would be bug bait. I am not sure how to improve it though. ---------- assignee: docs at python components: Documentation messages: 299023 nosy: docs at python, terry.reedy priority: normal severity: normal stage: patch review status: open title: Clarify programming faq. type: enhancement versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 24 17:53:08 2017 From: report at bugs.python.org (Ashok Bakthavathsalam) Date: Mon, 24 Jul 2017 21:53:08 +0000 Subject: [docs] [issue31021] Clarify programming faq. In-Reply-To: <1500933050.31.0.733502304217.issue31021@psf.upfronthosting.co.za> Message-ID: <1500933188.21.0.817573340101.issue31021@psf.upfronthosting.co.za> Changes by Ashok Bakthavathsalam : ---------- pull_requests: +2904 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 24 22:41:55 2017 From: report at bugs.python.org (svelankar) Date: Tue, 25 Jul 2017 02:41:55 +0000 Subject: [docs] [issue31023] Git Bootcamp and Cheat Sheet - Section 32.10 - Creating a Pull request needs an additional step Message-ID: <1500950515.8.0.297032298923.issue31023@psf.upfronthosting.co.za> New submission from svelankar: Section 32.10 - Creating a Pull Request Step 2 should be changed to Step 3 and so on. And a new step i.e. step 2 as "Press new pull request button" ---------- assignee: docs at python components: Documentation messages: 299039 nosy: docs at python, svelankar priority: normal severity: normal status: open title: Git Bootcamp and Cheat Sheet - Section 32.10 - Creating a Pull request needs an additional step _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 24 22:48:59 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 25 Jul 2017 02:48:59 +0000 Subject: [docs] [issue31023] Git Bootcamp and Cheat Sheet - Section 32.10 - Creating a Pull request needs an additional step In-Reply-To: <1500950515.8.0.297032298923.issue31023@psf.upfronthosting.co.za> Message-ID: <1500950939.12.0.108628872449.issue31023@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Hi, the issue tracker for the Dev guide is at https://github.com/python/DevGuide Can you file this issue there? Thanks. ---------- nosy: +Mariatta resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 25 04:04:43 2017 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 25 Jul 2017 08:04:43 +0000 Subject: [docs] [issue31021] Clarify programming faq. In-Reply-To: <1500933050.31.0.733502304217.issue31021@psf.upfronthosting.co.za> Message-ID: <1500969883.62.0.770326082456.issue31021@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 25 09:47:54 2017 From: report at bugs.python.org (Charles Wohlganger) Date: Tue, 25 Jul 2017 13:47:54 +0000 Subject: [docs] [issue31021] Clarify programming faq. In-Reply-To: <1500933050.31.0.733502304217.issue31021@psf.upfronthosting.co.za> Message-ID: <1500990474.68.0.537392208618.issue31021@psf.upfronthosting.co.za> Charles Wohlganger added the comment: Modulo is defined mathematically as the remainder of Euclidian division. I.E. a positive r where a % b = r is equivalent to a = b * x + r. I think it confuses the issue to say "-190 % 12 were the mathematical equivalent -10", when that is technically incorrect. Computer modulo uses truncated division, which is why -a % b != a % -b. "... compilers that truncate i // j need to make i % j have the same sign as i." i % j has the same sign as j, not i. I believe that is the typo that has caused the confusion. I would replace the last line with : "-190 % 12 == -10 is wrong according to the C definition for computer modulo arithmetic." ---------- nosy: +wohlganger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 25 09:49:19 2017 From: report at bugs.python.org (Jim Ferrara) Date: Tue, 25 Jul 2017 13:49:19 +0000 Subject: [docs] [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <1500990559.42.0.433208086969.issue25910@psf.upfronthosting.co.za> Changes by Jim Ferrara : ---------- pull_requests: +2917 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 25 11:13:38 2017 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Tue, 25 Jul 2017 15:13:38 +0000 Subject: [docs] [issue31035] Document order of firing callbacks added with Future.add_done_callback() Message-ID: <1500995618.96.0.99651815805.issue31035@psf.upfronthosting.co.za> New submission from ???? ?????????: Please document these two things: * Order of callbacks firing is not specified. (Is it True?) * All callbacks are called *BEFORE* await triggered: ==== f = asyncio.Future() f.add_done_callback(xxx) f.add_done_callback(yyy) try: await f except Exception: ... # all callbacks are called BEFORE entering that place (for example) * How exceptions in callbacks are handled ---------- assignee: docs at python components: Documentation, asyncio messages: 299095 nosy: docs at python, socketpair, yselivanov priority: normal severity: normal status: open title: Document order of firing callbacks added with Future.add_done_callback() type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 25 11:15:09 2017 From: report at bugs.python.org (Lisabel Leon) Date: Tue, 25 Jul 2017 15:15:09 +0000 Subject: [docs] [issue31037] Results in section 4.4 break and continue Message-ID: <1500995709.73.0.36567687409.issue31037@psf.upfronthosting.co.za> New submission from Lisabel Leon: The first example of this section shows different results if typed into the Python interpreter. This is the documentation (documentation.png) and these are the results as I type it into my environment (testresults.jpg). ---------- assignee: docs at python components: Documentation files: testresults.PNG messages: 299097 nosy: Lisabel Leon, docs at python priority: normal severity: normal status: open title: Results in section 4.4 break and continue versions: Python 3.6 Added file: http://bugs.python.org/file47040/testresults.PNG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 25 11:16:32 2017 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 25 Jul 2017 15:16:32 +0000 Subject: [docs] [issue31037] Results in section 4.4 break and continue In-Reply-To: <1500995709.73.0.36567687409.issue31037@psf.upfronthosting.co.za> Message-ID: <1500995792.49.0.35303461042.issue31037@psf.upfronthosting.co.za> St?phane Wirtel added the comment: could you be more explicit? which section ? Thank you ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 25 11:56:15 2017 From: report at bugs.python.org (Zachary Ware) Date: Tue, 25 Jul 2017 15:56:15 +0000 Subject: [docs] [issue31037] Results in section 4.4 break and continue In-Reply-To: <1500995709.73.0.36567687409.issue31037@psf.upfronthosting.co.za> Message-ID: <1500998175.37.0.333153972342.issue31037@psf.upfronthosting.co.za> Zachary Ware added the comment: Take a look at the statement immediately following the example: "(Yes, this is the correct code. Look closely: the else clause belongs to the for loop, not the if statement.)" The example is correct, and is introducing the concept of an 'else' clause on a for loop. This is very much not the first report of this that we've had, though; perhaps the 'look closely' admonition should be moved before the example? For future reference, please copy and paste the text of your tests rather than a screenshot; not all participants can see the screenshot. ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 25 12:04:20 2017 From: report at bugs.python.org (Lisabel Leon) Date: Tue, 25 Jul 2017 16:04:20 +0000 Subject: [docs] [issue31037] Results in section 4.4 break and continue In-Reply-To: <1500998175.37.0.333153972342.issue31037@psf.upfronthosting.co.za> Message-ID: Lisabel Leon added the comment: Thank you Zachary for such a speedy response. I'll paste text next time. Rgds! Lisabel On Tue, Jul 25, 2017 at 11:56 AM, Zachary Ware wrote: > > Zachary Ware added the comment: > > Take a look at the statement immediately following the example: > > "(Yes, this is the correct code. Look closely: the else clause belongs to > the for loop, not the if statement.)" > > The example is correct, and is introducing the concept of an 'else' clause > on a for loop. This is very much not the first report of this that we've > had, though; perhaps the 'look closely' admonition should be moved before > the example? > > For future reference, please copy and paste the text of your tests rather > than a screenshot; not all participants can see the screenshot. > > ---------- > nosy: +zach.ware > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 25 13:41:07 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 25 Jul 2017 17:41:07 +0000 Subject: [docs] [issue26506] [EASY] hex() documentation: mention "%x" % int In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za> Message-ID: <1501004467.68.0.516037542896.issue26506@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +2921 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 25 14:04:12 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 25 Jul 2017 18:04:12 +0000 Subject: [docs] [issue26506] [EASY] hex() documentation: mention "%x" % int In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za> Message-ID: <1501005852.47.0.550785312965.issue26506@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: New changeset 59e6ab15e47d496ac4e5f9d53aac0fae0c708da4 by Mariatta in branch '3.6': bpo-26506: hex() documentation: mention %x % int (GH-2525) (GH-2870) https://github.com/python/cpython/commit/59e6ab15e47d496ac4e5f9d53aac0fae0c708da4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 25 14:05:01 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 25 Jul 2017 18:05:01 +0000 Subject: [docs] [issue26506] [EASY] hex() documentation: mention "%x" % int In-Reply-To: <1457372823.56.0.270827849914.issue26506@psf.upfronthosting.co.za> Message-ID: <1501005901.46.0.779290658145.issue26506@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks for the PRs Manvi. ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 25 15:13:07 2017 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 25 Jul 2017 19:13:07 +0000 Subject: [docs] [issue31021] Clarify programming faq. In-Reply-To: <1500933050.31.0.733502304217.issue31021@psf.upfronthosting.co.za> Message-ID: <1501009987.46.0.207110183603.issue31021@psf.upfronthosting.co.za> Mark Dickinson added the comment: Terry: can you clarify which part you think is potentially confusing? I'm having a hard time seeing the text as confusing, but I suspect I'm too close to the subject matter to be able to tell. Charles: I think you're missing the point (which does rather reinforce Terry's suggestion that this FAQ could be improved). You say: > "-190 % 12 == -10 is wrong according to the C definition for computer modulo arithmetic." But that's the point: for C (specifically C99[*]), -10 is the *correct* result from the operation -190 % 12. And that's exactly why this is a FAQ: Python is behaving differently from many other mainstream languages (C, Java, C++, C#, ...) here, so it's useful to understand the justification for this design decision. For C in particular, this behaviour is mandated by section 6.5.5p6 of C99, which reads: > When integers are divided, the result of the / operator is the algebraic > quotient with any fractional part discarded. If the quotient a/b is > representable, the expression (a/b)*b + a%b shall equal a. The first part of this forces -190 / 12 to be -15 (the result of discarding the fractional part of the true quotient -15.833....); the second then forces -190 % 12 to be (-190) - (-15)*12, which is -10. ([*] In C89, the rounding direction of a/b for negative a, and hence the behaviour of a%b, was left implementation defined, but same-sign-as-a appears to have been the dominant behaviour.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 25 15:46:43 2017 From: report at bugs.python.org (R. David Murray) Date: Tue, 25 Jul 2017 19:46:43 +0000 Subject: [docs] [issue31021] Clarify programming faq. In-Reply-To: <1500933050.31.0.733502304217.issue31021@psf.upfronthosting.co.za> Message-ID: <1501012003.06.0.948030349421.issue31021@psf.upfronthosting.co.za> R. David Murray added the comment: I think Terry and his OP are reacting to the fact that "-190 % 12 == -10" looks like it is saying that that expression is True in Python, which it is not (and that's the point). IMO, another issue is that "and then compilers that truncate i // j need to make i % j have the same sign as i." doesn't have enough connection in the naive reader's mind with "-190 % 12 == -10 is a bug waiting to bite" for easy comprehension. A potential fix to both these issues would be to say "if -190 % 12 were equal to -10 in Python (the way it is in most C programs), that would quite often be a bug waiting to happen in code using the % operator." ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 25 17:00:03 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 25 Jul 2017 21:00:03 +0000 Subject: [docs] [issue30304] TestCase.assertMultiLineEqual only registered for Unicode strings in 2.7 In-Reply-To: <1494233409.78.0.688533240712.issue30304@psf.upfronthosting.co.za> Message-ID: <1501016403.27.0.0353388261223.issue30304@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: New changeset 0666d0e50432e3b0109db96b8e48fb6c496bd49c by Mariatta (Aditya Hase) in branch '2.7': bpo-30304: Improve TestCase.assertMultiLineEqual docs (GH-2847) https://github.com/python/cpython/commit/0666d0e50432e3b0109db96b8e48fb6c496bd49c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 25 17:33:05 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 25 Jul 2017 21:33:05 +0000 Subject: [docs] [issue30304] TestCase.assertMultiLineEqual only registered for Unicode strings in 2.7 In-Reply-To: <1494233409.78.0.688533240712.issue30304@psf.upfronthosting.co.za> Message-ID: <1501018385.3.0.304512352924.issue30304@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: Thanks! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 25 19:19:56 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 25 Jul 2017 23:19:56 +0000 Subject: [docs] [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <1501024796.42.0.26783141824.issue25910@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +2924 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 25 23:02:59 2017 From: report at bugs.python.org (Joseph Fox-Rabinovitz) Date: Wed, 26 Jul 2017 03:02:59 +0000 Subject: [docs] [issue31042] Inconsistency in documentation of operator.index Message-ID: <1501038179.61.0.173139487282.issue31042@psf.upfronthosting.co.za> New submission from Joseph Fox-Rabinovitz: The docs for [`operator.index`][1] and `operator.__index__` state that > Return *a* converted to an integer. Equivalent to `a.__index__()`. The first sentence is correct, but the second is not. First of all, we have the data model [docs][2]: > For custom classes, implicit invocations of special methods are only guaranteed to work correctly if defined on an object?s type, not in the object?s instance dictionary. Secondly, we can make a simple counter-example in code: ``` import operator class A: def __index__(self): return 0 a = A() a.__index__ = (lambda self: 1).__get__(a, type(a)) operator.index(a) ``` The result is of course zero and not one. I believe that the docs should read something more like one of the following to avoid being misleading: > Return *a* converted to an integer, if it is already an integral type. > Return *a* converted to an integer. Equivalent to `type(a).__index__(a)`. Or a combination of both: > Return *a* converted to an integer, if it is already an integral type. Equivalent to `type(a).__index__(a)`. [1]: https://docs.python.org/3/library/operator.html#operator.index [2]: https://docs.python.org/3/reference/datamodel.html#special-method-lookup ---------- assignee: docs at python components: Documentation messages: 299195 nosy: docs at python, madphysicist priority: normal severity: normal status: open title: Inconsistency in documentation of operator.index type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 25 23:03:19 2017 From: report at bugs.python.org (Joseph Fox-Rabinovitz) Date: Wed, 26 Jul 2017 03:03:19 +0000 Subject: [docs] [issue31042] Inconsistency in documentation of operator.index In-Reply-To: <1501038179.61.0.173139487282.issue31042@psf.upfronthosting.co.za> Message-ID: <1501038199.22.0.417409187279.issue31042@psf.upfronthosting.co.za> Changes by Joseph Fox-Rabinovitz : ---------- type: behavior -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 25 23:55:37 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Wed, 26 Jul 2017 03:55:37 +0000 Subject: [docs] [issue31040] mimetypes.add_type should complain when you give it an undotted ext In-Reply-To: <1501010741.93.0.952054126016.issue31040@psf.upfronthosting.co.za> Message-ID: <1501041337.85.0.36941882935.issue31040@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 26 02:26:47 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 26 Jul 2017 06:26:47 +0000 Subject: [docs] [issue31037] Results in section 4.4 break and continue In-Reply-To: <1500995709.73.0.36567687409.issue31037@psf.upfronthosting.co.za> Message-ID: <1501050407.3.0.196902707808.issue31037@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From dwightliv at verizon.net Tue Jul 25 21:07:52 2017 From: dwightliv at verizon.net (Dwight Livingston) Date: Tue, 25 Jul 2017 21:07:52 -0400 Subject: [docs] document bug Message-ID: https://docs.python.org/3/glossary.html#glossary [Delete first "either" in following paragraph] struct sequence A tuple with named elements. Struct sequences expose an interface similar to named tuple in that elements can _*either*_ be accessed either by index or as an attribute. However, they do not have any of the named tuple methods like |_make()| or |_asdict()| . Examples of struct sequences include |sys.float_info| and the return value of |os.stat()| . From randalljhenderson at gmail.com Tue Jul 25 18:02:45 2017 From: randalljhenderson at gmail.com (Randy Henderson) Date: Tue, 25 Jul 2017 15:02:45 -0700 Subject: [docs] documentation bug Message-ID: In the Python 3.6.2 tutorial section 6.1.1 "Executing modules as scripts," the code format "python fibo.py " generates the following error in a Windows command shell: "python: can't open file 'fibo.py': [Errno 2] No such file or directory". This error is generated even if the script's path is listed in the user or system PATH environment variable. To get the code to run as is, the user has to first change the working directory to the location of the script (e.g. "cd c:\python36\scripts"). If the user has not changed the working directory, then the user needs to either specify the full path of the script (e.g. "python c:\python36\scripts\fibo.py ") or use the format "python -m fibo ". Thanks, Randy -------------- next part -------------- An HTML attachment was scrubbed... URL: From report at bugs.python.org Wed Jul 26 10:05:11 2017 From: report at bugs.python.org (Marco Buttu) Date: Wed, 26 Jul 2017 14:05:11 +0000 Subject: [docs] [issue31021] Clarify programming faq. In-Reply-To: <1500933050.31.0.733502304217.issue31021@psf.upfronthosting.co.za> Message-ID: <1501077911.49.0.145769909881.issue31021@psf.upfronthosting.co.za> Marco Buttu added the comment: Terry thanks for opening this issue. The title of the FAQ makes me think that the section wants to clarify why -22 // 10 returns -3. I am a bit confused, maybe because -22//10 == -3 does not surprise me, and so I do not understand the point :( This seems to me a section about the module rather than floor division. If the section wants to clarify the floor division behavior in Python, IMHO at the beginning of the section we have to explain why -22//10 == -3 may surprise the reader (it is not clear to me, so maybe it could not surprise other readers too), and then the reasons that justify why to have -22//10 == -3. ---------- nosy: +marco.buttu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 26 11:06:58 2017 From: report at bugs.python.org (Daniel Watkins) Date: Wed, 26 Jul 2017 15:06:58 +0000 Subject: [docs] [issue31040] mimetypes.add_type should complain when you give it an undotted ext In-Reply-To: <1501010741.93.0.952054126016.issue31040@psf.upfronthosting.co.za> Message-ID: <1501081618.49.0.944380130183.issue31040@psf.upfronthosting.co.za> Changes by Daniel Watkins : ---------- pull_requests: +2948 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 26 21:17:36 2017 From: report at bugs.python.org (KINEBUCHI Tomohiko) Date: Thu, 27 Jul 2017 01:17:36 +0000 Subject: [docs] [issue31053] Unnecessary argument in command example Message-ID: <1501118256.7.0.957994269182.issue31053@psf.upfronthosting.co.za> New submission from KINEBUCHI Tomohiko: The command example running venv module for Windows has an unnecessary argument. The following two command examples should be equivalent:: :: c:\>c:\Python35\python -m venv c:\path\to\myenv :: c:\>python -m venv myenv c:\path\to\myenv (from https://docs.python.org/3/library/venv.html#creating-virtual-environments) ---------- assignee: docs at python components: Documentation messages: 299282 nosy: cocoatomo, docs at python priority: normal severity: normal status: open title: Unnecessary argument in command example versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 26 21:20:02 2017 From: report at bugs.python.org (KINEBUCHI Tomohiko) Date: Thu, 27 Jul 2017 01:20:02 +0000 Subject: [docs] [issue31053] Unnecessary argument in command example In-Reply-To: <1501118256.7.0.957994269182.issue31053@psf.upfronthosting.co.za> Message-ID: <1501118402.97.0.184532839521.issue31053@psf.upfronthosting.co.za> Changes by KINEBUCHI Tomohiko : ---------- pull_requests: +2958 _______________________________________ Python tracker _______________________________________ From hendras at yahoo.com Wed Jul 26 19:39:35 2017 From: hendras at yahoo.com (Hendra Soetjahja) Date: Wed, 26 Jul 2017 23:39:35 +0000 (UTC) Subject: [docs] Bugs in Tutorial for Python 3.6.2. Section 4.4 (p. 19) References: <1141009084.155989.1501112375255.ref@mail.yahoo.com> Message-ID: <1141009084.155989.1501112375255@mail.yahoo.com> Hi Python Development Team, There are 3 bugs in Tutorial for Python 3.6.2. Section 4.4 (p. 19). These are tested for both in Python 2.7, 3.5, and 3.6 interpreters, as module and in interactive mode.I also tested it on Ubuntu 16.04 LTS, Windows 7, and Windows 10. The bugs are: (1) I don't know how you could get number 2 printed out as prime number since is when n=2 and x=2 the condition is FALSE for x inrange(2, n):range is always 'less than' not 'less than and equal to'.? So for n=2 and x=2 case (ie. evaluation of number 2), it never enter the for loop to be evaluated.In other words, number 2 never gets evaluated, hence could never be printed either as prime number or not. (2) Even if it does enter into the for loop by changing it the upper limit of range to range (2, n+1), as for x inrange(2, n+1):Number to would be considered as non-prime since 2%2 is 0 the first time it runs and it would never get into the prime number section since it breaks out of the for loop. (3) Python? also claims that 9 to be both prime number when 9%2 and not prime number when 9 % 3 is 0.? for n in range(2, 10):??? for x inrange(2, n):????# equivalent to (2, 1) = FALSE condition, while evaluating number 2 ??????? if n % x== 0:??????????? print(n,'equals', x, '*', n // x)??????????? break??????? else:??????????? #loop fell through without finding a factor??????????? print(n,'is a prime number')? Output claims in the document: 2 is a prime number3 is a prime number4 equals 2 * 25 is a prime number6 equals 2 * 37 is a prime number8 equals 2 * 49 equals 3 * 3??---------------------------------------------------------------------------------- This message with its attachment(s) are confidential, restricted, proprietary, and only for the originally addressed recipient(s). If you are not among the intended recipient(s), you are obligated to destroy this message immediately without using, sharing, disclosing, copying, distributing, or archiving it. Anyone acting otherwise will be responsible for any ramification that may arise from the unauthorized usage or distribution of this message. The sender is not liable for any loss or damage arising in any way from this message or its attachment(s). By messaging with the sender you consent to the aforementioned terms. ---------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From report at bugs.python.org Wed Jul 26 22:53:36 2017 From: report at bugs.python.org (Zachary Ware) Date: Thu, 27 Jul 2017 02:53:36 +0000 Subject: [docs] [issue31037] Results in section 4.4 break and continue In-Reply-To: <1500995709.73.0.36567687409.issue31037@psf.upfronthosting.co.za> Message-ID: <1501124016.56.0.37149095485.issue31037@psf.upfronthosting.co.za> Zachary Ware added the comment: We just received another report about this on docs@: https://mail.python.org/pipermail/docs/2017-July/032314.html ---------- _______________________________________ Python tracker _______________________________________ From zachary.ware+pydocs at gmail.com Wed Jul 26 22:53:29 2017 From: zachary.ware+pydocs at gmail.com (Zachary Ware) Date: Wed, 26 Jul 2017 21:53:29 -0500 Subject: [docs] Bugs in Tutorial for Python 3.6.2. Section 4.4 (p. 19) In-Reply-To: <1141009084.155989.1501112375255@mail.yahoo.com> References: <1141009084.155989.1501112375255.ref@mail.yahoo.com> <1141009084.155989.1501112375255@mail.yahoo.com> Message-ID: Hi Hendra, On Wed, Jul 26, 2017 at 6:39 PM, Hendra Soetjahja via docs wrote: > Hi Python Development Team, > > There are 3 bugs in Tutorial for Python 3.6.2. Section 4.4 (p. 19). > These are tested for both in Python 2.7, 3.5, and 3.6 interpreters, as > module and in interactive mode. > I also tested it on Ubuntu 16.04 LTS, Windows 7, and Windows 10. Fortunately, the bug is in your transcription of the example, not in the docs (nor Python itself). Look at the line immediately following the example: > (Yes, this is the correct code. Look closely: the else clause belongs to the for loop, not the if statement.) Note also that this section is titled "..., and else Clauses on Loops". This was also recently reported on the bug tracker; if you have any suggestions for improving the clarity of that section, please add a comment to http://bugs.python.org/issue31037 Regards, -- Zach From report at bugs.python.org Thu Jul 27 05:34:25 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 27 Jul 2017 09:34:25 +0000 Subject: [docs] [issue30940] Documentation for round() is incorrect. In-Reply-To: <1500223918.38.0.72996478594.issue30940@psf.upfronthosting.co.za> Message-ID: <1501148065.57.0.601622425505.issue30940@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In the documentation: For a general Python object ``number``, ``round(number, ndigits)`` delegates to ``number.__round__(ndigits)``. Mark, is it worth to mention explicitly that round(number) and round(number, None) delegate to number.__round__()? The custom __round__() method should support calling without the argument, but it can not support calling with None. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 27 08:45:26 2017 From: report at bugs.python.org (Paul Hammant) Date: Thu, 27 Jul 2017 12:45:26 +0000 Subject: [docs] [issue31055] All Sphinx generated pages could have a new "Edit This Page" link adjacent to the existing "Show Source" Message-ID: <1501159526.11.0.527058516666.issue31055@psf.upfronthosting.co.za> New submission from Paul Hammant: Show Source links to: https://github.com/python/cpython/blob/path/to/resource.rst Edit This Page would link to https://github.com/python/cpython/edit/path/to/resource.rst And yes, GitHub does the right thing if you're not ordinarily permitted to change python/cpython ---------- assignee: docs at python components: Documentation messages: 299306 nosy: Paul Hammant, docs at python priority: normal severity: normal status: open title: All Sphinx generated pages could have a new "Edit This Page" link adjacent to the existing "Show Source" versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From hendras at yahoo.com Wed Jul 26 23:43:35 2017 From: hendras at yahoo.com (Hendra Soetjahja) Date: Thu, 27 Jul 2017 03:43:35 +0000 (UTC) Subject: [docs] Bugs in Tutorial for Python 3.6.2. Section 4.4 (p. 19) In-Reply-To: References: <1141009084.155989.1501112375255.ref@mail.yahoo.com> <1141009084.155989.1501112375255@mail.yahoo.com> Message-ID: <30610778.291051.1501127015744@mail.yahoo.com> Hi Zachary, Right you are. I need a reading glasses or get more sleep to see the indentation correctly? :)I suppose it's C/C++ programmer cognitive perception/dissonance that else goes with the if, not with for.We just glance it and started running the algo with if-else pairing in our head.It's like sleight of hand magic tricking our cognitive 'expectation' based on C/C++ experience. You probably know it immediately when I copied the code with incorrect indentation in my email. This is the problem with indentation only language as in Python as suppose with curly braces delimiting blocks of code.There is no ambiguity which block the else goes with if the loop is delimited with braces as in C/C++ https://www.tutorialspoint.com/cplusplus/cpp_if_else_statement.htm https://www.tutorialspoint.com/cplusplus/cpp_for_loop.htm Thanks,? Hendra PS: The first time I replied, it only went to docs at python.org, not to your gmail account. ??---------------------------------------------------------------------------------- This message with its attachment(s) are confidential, restricted, proprietary, and only for the originally addressed recipient(s). If you are not among the intended recipient(s), you are obligated to destroy this message immediately without using, sharing, disclosing, copying, distributing, or archiving it. Anyone acting otherwise will be responsible for any ramification that may arise from the unauthorized usage or distribution of this message. The sender is not liable for any loss or damage arising in any way from this message or its attachment(s). By messaging with the sender you consent to the aforementioned terms. ---------------------------------------------------------------------------------- From: Zachary Ware To: "docs at python.org" Cc: Hendra Soetjahja Sent: Wednesday, July 26, 2017 10:53 PM Subject: Re: [docs] Bugs in Tutorial for Python 3.6.2. Section 4.4 (p. 19) Hi Hendra, On Wed, Jul 26, 2017 at 6:39 PM, Hendra Soetjahja via docs wrote: > Hi Python Development Team, > > There are 3 bugs in Tutorial for Python 3.6.2. Section 4.4 (p. 19). > These are tested for both in Python 2.7, 3.5, and 3.6 interpreters, as > module and in interactive mode. > I also tested it on Ubuntu 16.04 LTS, Windows 7, and Windows 10. Fortunately, the bug is in your transcription of the example, not in the docs (nor Python itself).? Look at the line immediately following the example: > (Yes, this is the correct code. Look closely: the else clause belongs to the for loop, not the if statement.) Note also that this section is titled "..., and else Clauses on Loops". This was also recently reported on the bug tracker; if you have any suggestions for improving the clarity of that section, please add a comment to http://bugs.python.org/issue31037 Regards, -- Zach -------------- next part -------------- An HTML attachment was scrubbed... URL: From report at bugs.python.org Thu Jul 27 11:05:53 2017 From: report at bugs.python.org (Thomas Thurman) Date: Thu, 27 Jul 2017 15:05:53 +0000 Subject: [docs] [issue31057] pydoc for tempfile.TemporaryDirectory should say it returns the name Message-ID: <1501167953.07.0.778065697758.issue31057@psf.upfronthosting.co.za> New submission from Thomas Thurman: Currently the pydoc for tempfile.TemporaryDirectory begins "Create and return a temporary directory." It doesn't explain anywhere *what* it returns (in fact, it returns the name of the directory as a string). The return type is further obscured by TemporaryDirectory being a context manager. ---------- assignee: docs at python components: Documentation messages: 299317 nosy: Thomas Thurman, docs at python priority: normal severity: normal status: open title: pydoc for tempfile.TemporaryDirectory should say it returns the name type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 27 11:09:45 2017 From: report at bugs.python.org (Roundup Robot) Date: Thu, 27 Jul 2017 15:09:45 +0000 Subject: [docs] [issue31057] pydoc for tempfile.TemporaryDirectory should say it returns the name In-Reply-To: <1501167953.07.0.778065697758.issue31057@psf.upfronthosting.co.za> Message-ID: <1501168185.43.0.646919662368.issue31057@psf.upfronthosting.co.za> Changes by Roundup Robot : ---------- pull_requests: +2968 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 27 13:03:21 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Thu, 27 Jul 2017 17:03:21 +0000 Subject: [docs] [issue31055] All Sphinx generated pages could have a new "Edit This Page" link adjacent to the existing "Show Source" In-Reply-To: <1501159526.11.0.527058516666.issue31055@psf.upfronthosting.co.za> Message-ID: <1501175001.75.0.253826202483.issue31055@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: I don't think we should add this link. When we make edits to the docs, even simple typo fixes, it should first be done in the master branch, instead of the maintenance branches (e.g. 2.7, 3.5 or 3.6). If "Edit This Page" link takes you to edit the documentation in branches other than "master", that's not desirable workflow. If "Edit This Page" link takes you to edit the master branch, it can be confusing to the contributor since the content on "master" might be different. ---------- nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 27 13:08:47 2017 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 27 Jul 2017 17:08:47 +0000 Subject: [docs] [issue30940] Documentation for round() is incorrect. In-Reply-To: <1500223918.38.0.72996478594.issue30940@psf.upfronthosting.co.za> Message-ID: <1501175327.11.0.429124196613.issue30940@psf.upfronthosting.co.za> Mark Dickinson added the comment: [Serhiy] > is it worth to mention explicitly that round(number) and round(number, None) > delegate to number.__round__()? Yes, if we can find a non-clunky wording that does that. The current wording does seem to misleadingly suggest that the delegation to `__round__` only happens for the two-argument version of round. How about just: > For a general Python object ``number``, ``round`` delegates to > ``number.__round__``. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 27 13:22:57 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 27 Jul 2017 17:22:57 +0000 Subject: [docs] [issue31057] pydoc for tempfile.TemporaryDirectory should say it returns the name In-Reply-To: <1501167953.07.0.778065697758.issue31057@psf.upfronthosting.co.za> Message-ID: <1501176177.35.0.425309176807.issue31057@psf.upfronthosting.co.za> R. David Murray added the comment: It actually returns the path, since "name" often means the last component of the path. Just saying "path" might be confused with pathlib, though. So I guess we'd have to say "returning its path as a string", which sounds awkward. The original wording is in fact accurate, since most people will understand "the directory" as the directory path as a string. I'm not sure this change would be an improvement. I'm not saying no, though. I guess you'd say I'm -0 on changing it. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From fred at fdrake.net Thu Jul 27 15:01:35 2017 From: fred at fdrake.net (Fred Drake) Date: Thu, 27 Jul 2017 15:01:35 -0400 Subject: [docs] [issue31055] All Sphinx generated pages could have a new "Edit This Page" link adjacent to the existing "Show Source" In-Reply-To: <1501175001.75.0.253826202483.issue31055@psf.upfronthosting.co.za> References: <1501159526.11.0.527058516666.issue31055@psf.upfronthosting.co.za> <1501175001.75.0.253826202483.issue31055@psf.upfronthosting.co.za> Message-ID: On Thu, Jul 27, 2017 at 1:03 PM, Mariatta Wijaya wrote: > I don't think we should add this link. > > When we make edits to the docs, even simple typo fixes, it should first be done > in the master branch, instead of the maintenance branches (e.g. 2.7, 3.5 or 3.6). > > If "Edit This Page" link takes you to edit the documentation in branches other > than "master", that's not desirable workflow. > > If "Edit This Page" link takes you to edit the master branch, it can be confusing > to the contributor since the content on "master" might be different. I wonder if a better solution lies somewhere between the original suggestion and just not including such a link. If the link went to an edit form with the version of the content the user was reading, and includes an explanation of the multiple-versions issue, it might prove reasonable to try applying the diff between the modified and original text to the HEADs of each maintenance branch. If the diff doesn't apply, the (possibly new) contributor can be offered a chance to deal with edits to each version (which might be a bit much). At any rate, the diff could be used to construct a temporary branch, b.p.o issue, and PR. This would allow us to provide the contributor with a way to see that their suggested changes are being considered, and we're less likely to lose them in a wall of email. There'd be a bit of work to make all this play out, though. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein From report at bugs.python.org Thu Jul 27 15:04:23 2017 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Thu, 27 Jul 2017 19:04:23 +0000 Subject: [docs] [issue31055] All Sphinx generated pages could have a new "Edit This Page" link adjacent to the existing "Show Source" In-Reply-To: Message-ID: Fred L. Drake, Jr. added the comment: On Thu, Jul 27, 2017 at 3:01 PM, Fred L. Drake, Jr. wrote: > If the link went to an edit form with the version of the content the > user was reading, > and includes an explanation of the multiple-versions issue, it might > prove reasonable Egads, look at that formatting! Somedays I miss my VT-100 terminals and sane line handling. -Fred ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 27 15:34:27 2017 From: report at bugs.python.org (Paul Hammant) Date: Thu, 27 Jul 2017 19:34:27 +0000 Subject: [docs] [issue31055] All Sphinx generated pages could have a new "Edit This Page" link adjacent to the existing "Show Source" In-Reply-To: <1501159526.11.0.527058516666.issue31055@psf.upfronthosting.co.za> Message-ID: <1501184067.23.0.531150312881.issue31055@psf.upfronthosting.co.za> Paul Hammant added the comment: Hi folks, I'm not explaining Github's non-commiter contribution process very well. Click this link everyone - https://github.com/BuildRadiator/BuildRadiator/edit/master/README.md - pretend to make a contribution to one of my projects :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 27 15:44:13 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 27 Jul 2017 19:44:13 +0000 Subject: [docs] [issue31042] Inconsistency in documentation of operator.index In-Reply-To: <1501038179.61.0.173139487282.issue31042@psf.upfronthosting.co.za> Message-ID: <1501184653.06.0.83925182062.issue31042@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This seems like a generic issue for magic methods and is already covered by "for custom classes, implicit invocations of special methods are only guaranteed to work correctly if defined on an object?s type, not in the object?s instance dictionary." While you're technically correct with suggesting "Equivalent to `type(a).__index__(a)`", I don't think this is an improvement. It makes the docs safe against overly pedantic readings, but it also reduces the intelligibility for everyday users. The usual approach in the docs is to say "a[b] <==> a.__getitem__(b)" rather than "a[b] <==> type(a).__getitem__(a, b)". The latter is more correct but it is also less helpful. For the most part, this style of presentation has worked well for a lot of people for a long time. I recommend closing this or not doing any more than changing "Equivalent to:" to "Roughly equivalent to:". ---------- nosy: +rhettinger priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 27 15:56:23 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 27 Jul 2017 19:56:23 +0000 Subject: [docs] [issue31055] All Sphinx generated pages could have a new "Edit This Page" link adjacent to the existing "Show Source" In-Reply-To: <1501159526.11.0.527058516666.issue31055@psf.upfronthosting.co.za> Message-ID: <1501185383.81.0.287532055472.issue31055@psf.upfronthosting.co.za> R. David Murray added the comment: No, we understand the process, the problem is that except for the 'dev' docs, the link would be to a branch other than master. That's the problem that we're discussing. Maybe instead of an edit link on non-dev docs we could have a message saying that if you want to propose a change you can use the edit link on the 'dev' version of the docs? Maybe with a link or button that would take them to the dev version of the page? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 27 16:04:34 2017 From: report at bugs.python.org (R. David Murray) Date: Thu, 27 Jul 2017 20:04:34 +0000 Subject: [docs] [issue31042] Inconsistency in documentation of operator.index In-Reply-To: <1501038179.61.0.173139487282.issue31042@psf.upfronthosting.co.za> Message-ID: <1501185874.04.0.828360482221.issue31042@psf.upfronthosting.co.za> R. David Murray added the comment: I agree with Raymond. I'm not sure that adding roughly is going to decrease the possibility of confusion, but I won't object to it. In a way, it's too bad we didn't make the attribute lookup machinery look up all dunder methods on the class, so that a.__index__ would call the class method. I think backward compatibility prevented that. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 27 16:09:18 2017 From: report at bugs.python.org (Joseph Fox-Rabinovitz) Date: Thu, 27 Jul 2017 20:09:18 +0000 Subject: [docs] [issue31042] Inconsistency in documentation of operator.index In-Reply-To: <1501185874.04.0.828360482221.issue31042@psf.upfronthosting.co.za> Message-ID: Joseph Fox-Rabinovitz added the comment: I brought up the issue because it was really a point of confusion for me. Could we make the change to "Roughly equivalent" and make that a link to https://docs.python.org/3/reference/datamodel.html#special-method-lookup? That would make it clear how the lookup is actually done. While I agree that making the docs unnecessarily pedantic is probably a bad thing, I am going to guess that I am not the only person that looks to them for technical accuracy. Regards, -Joe On Thu, Jul 27, 2017 at 4:04 PM, R. David Murray wrote: > > R. David Murray added the comment: > > I agree with Raymond. I'm not sure that adding roughly is going to > decrease the possibility of confusion, but I won't object to it. > > In a way, it's too bad we didn't make the attribute lookup machinery look > up all dunder methods on the class, so that a.__index__ would call the > class method. I think backward compatibility prevented that. > > ---------- > nosy: +r.david.murray > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 28 06:30:57 2017 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 28 Jul 2017 10:30:57 +0000 Subject: [docs] [issue31065] Documentation for Popen.poll is unclear Message-ID: <1501237857.05.0.15004204926.issue31065@psf.upfronthosting.co.za> New submission from Mark Dickinson: The documentation for Popen.poll says: > Check if child process has terminated. Set and return returncode attribute. This requires the reader to guess that if the child process has not terminated, the call returns immediately, with a return value of ``None``. It would be good to be explicit about this. ---------- assignee: docs at python components: Documentation messages: 299378 nosy: docs at python, mark.dickinson priority: normal severity: normal status: open title: Documentation for Popen.poll is unclear versions: Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 28 06:31:17 2017 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 28 Jul 2017 10:31:17 +0000 Subject: [docs] [issue31065] Documentation for Popen.poll is unclear In-Reply-To: <1501237857.05.0.15004204926.issue31065@psf.upfronthosting.co.za> Message-ID: <1501237877.83.0.869425152233.issue31065@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 28 09:41:49 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 28 Jul 2017 13:41:49 +0000 Subject: [docs] [issue31057] pydoc for tempfile.TemporaryDirectory should say it returns the name In-Reply-To: <1501167953.07.0.778065697758.issue31057@psf.upfronthosting.co.za> Message-ID: <1501249309.22.0.467333987047.issue31057@psf.upfronthosting.co.za> R. David Murray added the comment: Boy, I wasn't thinking very clearly when I wrote that. As pointed out on the PR, tempfile.TemporaryDirectory of course returns a TemporaryDirectory object. That's in the nature of Python. I was reading so poorly that I didn't even notice it was the docstring you were modifying :( The main docs phrase this more clearly, especially the sentence that says the name can be retrieved from the name property (and I see I was wrong, it does use 'name', not 'path'). We don't want to copy all of the text from there, but it could be used as a model to improve the phrasing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 28 09:48:31 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 28 Jul 2017 13:48:31 +0000 Subject: [docs] [issue31065] Documentation for Popen.poll is unclear In-Reply-To: <1501237857.05.0.15004204926.issue31065@psf.upfronthosting.co.za> Message-ID: <1501249711.42.0.803022914515.issue31065@psf.upfronthosting.co.za> R. David Murray added the comment: Yes we can add "otherwise return None". However it is pretty clear as is, since "poll" implies an immediate return, and if there's no return code to return, the logical value in Python to get back is None :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 28 11:30:51 2017 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 28 Jul 2017 15:30:51 +0000 Subject: [docs] [issue31065] Documentation for Popen.poll is unclear In-Reply-To: <1501237857.05.0.15004204926.issue31065@psf.upfronthosting.co.za> Message-ID: <1501255851.06.0.919390227129.issue31065@psf.upfronthosting.co.za> Mark Dickinson added the comment: Right, after following the source, I realise that `poll` is indeed returning `self.returncode` in all cases, and if the process hasn't terminated yet then `self.returncode` is still at its initial value of `None`. I can think of other ways that the result could potentially be indicated, though: when I poll, I'm asking whether the child process is still running or not, so a boolean result wouldn't be unreasonable. Or perhaps an exception (like doing `get(block=False)` on a queue does). I don't there's a good reason not to be explicit here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 28 11:31:22 2017 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 28 Jul 2017 15:31:22 +0000 Subject: [docs] [issue31065] Documentation for Popen.poll is unclear In-Reply-To: <1501237857.05.0.15004204926.issue31065@psf.upfronthosting.co.za> Message-ID: <1501255882.39.0.529552641249.issue31065@psf.upfronthosting.co.za> Mark Dickinson added the comment: > I don't there's I don't *think* there's ... Stupid fingers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 28 12:48:54 2017 From: report at bugs.python.org (R. David Murray) Date: Fri, 28 Jul 2017 16:48:54 +0000 Subject: [docs] [issue31065] Documentation for Popen.poll is unclear In-Reply-To: <1501237857.05.0.15004204926.issue31065@psf.upfronthosting.co.za> Message-ID: <1501260534.47.0.141191243833.issue31065@psf.upfronthosting.co.za> R. David Murray added the comment: Agreed. Explicit is good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 28 21:59:19 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 29 Jul 2017 01:59:19 +0000 Subject: [docs] [issue31042] Inconsistency in documentation of operator.index In-Reply-To: <1501038179.61.0.173139487282.issue31042@psf.upfronthosting.co.za> Message-ID: <1501293559.2.0.226846388631.issue31042@psf.upfronthosting.co.za> Terry J. Reedy added the comment: To me, 'roughly' is wrong. Either the equivalence is exact, or it is completely absent . There is no 'nearly' or 'roughly' about this situation. This is difference from iterator_class_x(args) being mathematically equivalent to generator_function_y(args) in the sense of yielding *exactly* the same sequence of objects, but being different in the Python sense that type(iterator_class_x) != type(generator_function_y). Note: even in this case, I was once in favor of changing 'equivalent' to 'roughly equivalent' in the itertools doc. I now regret that because 'roughly' could be misunderstood. I think that 'mathematically equivalent' or 'equivalent when iterated' or 'equivalent*' would be better, with an explanatory note at the top. As for this issue, __index__ is a reserved name. https://docs.python.org/3/reference/lexical_analysis.html#reserved-classes-of-identifiers a.__index__ = is an unauthorized use of a *reserved* word and the effect of such usage is not and need not be documented. The entry for __*__ does include "*Any* use of __*__ names, in any context, that does not follow explicitly documented use, is subject to breakage without warning." To me, that says that the effect of the reserved-word assignment is undefined. It could be made to raise an exception. To be even clearer, I believe we should explicitly state what I consider implicit: something like "Any such use breaks these manuals, in the sense that it may make statements herein untrue. These manuals assume that reserved names are used as specified." ---------- nosy: +terry.reedy stage: -> needs patch type: -> enhancement versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 28 22:25:57 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 29 Jul 2017 02:25:57 +0000 Subject: [docs] [issue31045] Add a language switch to the Python documentation In-Reply-To: <1501078214.01.0.529111921671.issue31045@psf.upfronthosting.co.za> Message-ID: <1501295157.05.0.590341581163.issue31045@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I left out 2.7 because I don't know if the 2.7 docs have been or will be included. I am looking forward to this because I know someone who programs in Python and is also looking to learn 'professional' Japanese, including CS. I myself might try the Spanish translations, if there are any. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, terry.reedy stage: -> patch review type: -> enhancement versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 29 02:32:24 2017 From: report at bugs.python.org (Julien Palard) Date: Sat, 29 Jul 2017 06:32:24 +0000 Subject: [docs] [issue31045] Add a language switch to the Python documentation In-Reply-To: <1501078214.01.0.529111921671.issue31045@psf.upfronthosting.co.za> Message-ID: <1501309944.02.0.49293039737.issue31045@psf.upfronthosting.co.za> Julien Palard added the comment: @terry About Japanese translation, Inada Naoki is the coordinator, their repository is created (https://github.com/python/python-docs-ja) they just have to push now. Once this language switch fully tested / implemented / released, it will be easy to add a language. Rules to add a language to the picker are described in PEP 545 (translation have to meet criterias like having a fully translated tutorial). Spannish translation exist too, here https://github.com/PyAr/tutorial/commits/master but I don't remember if they contacted us about porting it to docs.python.org. FYI I try to document which language is at which step of landing to d.p.o here: https://mdk.fr/blog/python-documentation-translation.html, coordinators are documented here: https://docs.python.org/devguide/experts.html#documentation-translations FTR I'm currently testing the new switchers locally, I should be able to remove the "WIP" soon. ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 29 08:24:17 2017 From: report at bugs.python.org (Marcos Soutullo) Date: Sat, 29 Jul 2017 12:24:17 +0000 Subject: [docs] [issue31075] Collections - ChainMap - Documentation example wrong order line Message-ID: <1501331057.19.0.539549352975.issue31075@psf.upfronthosting.co.za> New submission from Marcos Soutullo: Hello, I have been taking a look into your ChainMap collections documentation (https://docs.python.org/3.6/library/collections.html?highlight=collections#collections.ChainMap), specifically the third code example on "8.3.1.1. ChainMap Examples and Recipes" that clearly describe and illustrate a use case for the ChainMap class. However, I found a very small code issue in regards to how the sample code (line 7) is presented to the reader. Please refer to the code compilation below: Line 7 >>> d['x'] # Get first key in the chain of contexts raise KeyError(key) KeyError: 'x' Line 8 >>> d['x'] d['x'] = 1 # Set value in current context The key named 'x' had not been initialised yet and of course, the compiler is complaining. It should be the other way around. Line 8 >>> d['x'] = 1 # Set value in current context Line 7 >>> d['x'] # Get first key in the chain of contexts Many thanks for the great work you do with Python, Marcos S. ---------- assignee: docs at python components: Documentation messages: 299465 nosy: Marcos Soutullo, docs at python priority: normal severity: normal status: open title: Collections - ChainMap - Documentation example wrong order line type: compile error versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 29 13:03:26 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 29 Jul 2017 17:03:26 +0000 Subject: [docs] [issue31075] Collections - ChainMap - Documentation example wrong order line In-Reply-To: <1501331057.19.0.539549352975.issue31075@psf.upfronthosting.co.za> Message-ID: <1501347806.7.0.116646851984.issue31075@psf.upfronthosting.co.za> Raymond Hettinger added the comment: -0 The code block was originally intended to just be a table of patterns, not meant to be executed sequentially. It followed the traditional presentation order (__getitem__, __setitem__, followed by __delitem__). If we do change this, then the subsequent "k in d" example should also be changed to "'x' in d" because k isn't defined. ---------- assignee: docs at python -> rhettinger nosy: +rhettinger priority: normal -> low resolution: -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 29 15:18:15 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 29 Jul 2017 19:18:15 +0000 Subject: [docs] [issue30803] Truth value of sets not properly documented In-Reply-To: <1498743378.1.0.0570911503542.issue30803@psf.upfronthosting.co.za> Message-ID: <1501355895.76.0.858204738308.issue30803@psf.upfronthosting.co.za> Terry J. Reedy added the comment: New changeset caa1280d1ee5f828f346b585169a7592371d3faa by Terry Jan Reedy (Peter Thomassen) in branch 'master': bpo-30803: clarify truth value testing documentation (#2508) https://github.com/python/cpython/commit/caa1280d1ee5f828f346b585169a7592371d3faa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 29 15:18:46 2017 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 29 Jul 2017 19:18:46 +0000 Subject: [docs] [issue31075] Collections - ChainMap - Documentation example wrong order line In-Reply-To: <1501331057.19.0.539549352975.issue31075@psf.upfronthosting.co.za> Message-ID: <1501355926.05.0.988642537874.issue31075@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Many thanks for the great work you do with Python, Thanks for the kudos. Also, thanks for the close reading of the docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 29 15:21:59 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 29 Jul 2017 19:21:59 +0000 Subject: [docs] [issue30803] Truth value of sets not properly documented In-Reply-To: <1498743378.1.0.0570911503542.issue30803@psf.upfronthosting.co.za> Message-ID: <1501356119.28.0.52088486937.issue30803@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- pull_requests: +2995 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 29 18:56:08 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 29 Jul 2017 22:56:08 +0000 Subject: [docs] [issue30803] Truth value of sets not properly documented In-Reply-To: <1498743378.1.0.0570911503542.issue30803@psf.upfronthosting.co.za> Message-ID: <1501368968.53.0.247570275874.issue30803@psf.upfronthosting.co.za> Terry J. Reedy added the comment: New changeset 4c7b368de7bcabdd821059c023c46c9d85668d3f by Terry Jan Reedy in branch '3.6': [3.6] bpo-30803: clarify truth value testing documentation (GH-2508) (#2946) https://github.com/python/cpython/commit/4c7b368de7bcabdd821059c023c46c9d85668d3f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 29 18:56:48 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 29 Jul 2017 22:56:48 +0000 Subject: [docs] [issue30803] Truth value of sets not properly documented In-Reply-To: <1498743378.1.0.0570911503542.issue30803@psf.upfronthosting.co.za> Message-ID: <1501369008.96.0.722873234767.issue30803@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> fixed stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 29 18:56:58 2017 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 29 Jul 2017 22:56:58 +0000 Subject: [docs] [issue30803] Truth value of sets not properly documented In-Reply-To: <1498743378.1.0.0570911503542.issue30803@psf.upfronthosting.co.za> Message-ID: <1501369018.76.0.296686316553.issue30803@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 30 17:06:27 2017 From: report at bugs.python.org (Stefan Pochmann) Date: Sun, 30 Jul 2017 21:06:27 +0000 Subject: [docs] [issue31082] reduce takes iterable, not just sequence Message-ID: <1501448787.5.0.80084797494.issue31082@psf.upfronthosting.co.za> New submission from Stefan Pochmann: functools.reduce has a parameter called "iterable" and it only needs to be an iterable, not a sequence. The paragraph documenting it says "sequence" instead of "iterable" six times: https://docs.python.org/3/library/functools.html#functools.reduce The help shown by executing "help(functools.reduce)" in Python additionally actually names the parameter "sequence" in the signature. ---------- assignee: docs at python components: Documentation messages: 299520 nosy: Stefan Pochmann, docs at python priority: normal severity: normal status: open title: reduce takes iterable, not just sequence type: enhancement versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 31 05:11:13 2017 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 31 Jul 2017 09:11:13 +0000 Subject: [docs] [issue30940] Documentation for round() is incorrect. In-Reply-To: <1500223918.38.0.72996478594.issue30940@psf.upfronthosting.co.za> Message-ID: <1501492272.95.0.944945534265.issue30940@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > For a general Python object ``number``, ``round`` delegates to > ``number.__round__``. This also can be not clear. See a discussion in issue31042. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 31 07:56:35 2017 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 31 Jul 2017 11:56:35 +0000 Subject: [docs] [issue30940] Documentation for round() is incorrect. In-Reply-To: <1500223918.38.0.72996478594.issue30940@psf.upfronthosting.co.za> Message-ID: <1501502195.45.0.26156654927.issue30940@psf.upfronthosting.co.za> Mark Dickinson added the comment: > This also can be not clear. Sure. But if it comes down to a clear, mostly accurate description that helps people understand versus a harder-to-read nitpick-proof statement, I'd rather see the former. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 31 14:16:17 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Mon, 31 Jul 2017 18:16:17 +0000 Subject: [docs] [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <1501524977.22.0.0487352722961.issue25910@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: New changeset 8474d87165593bac2bc231287f42c4cff3fd6aaf by Mariatta in branch 'master': bpo-25910: Update LICENSE (GH-2873) https://github.com/python/cpython/commit/8474d87165593bac2bc231287f42c4cff3fd6aaf ---------- nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 31 22:41:45 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 01 Aug 2017 02:41:45 +0000 Subject: [docs] [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <1501555305.23.0.409069328294.issue25910@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +3015 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 31 22:43:01 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 01 Aug 2017 02:43:01 +0000 Subject: [docs] [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <1501555381.5.0.735496733217.issue25910@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +3016 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 31 22:43:15 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 01 Aug 2017 02:43:15 +0000 Subject: [docs] [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <1501555395.15.0.681804369494.issue25910@psf.upfronthosting.co.za> Changes by Mariatta Wijaya : ---------- pull_requests: +3017 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 31 22:53:45 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 01 Aug 2017 02:53:45 +0000 Subject: [docs] [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <1501556025.36.0.9841529962.issue25910@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: New changeset f6306e737203ac1bf1717bbf62bc58dac24b68db by Mariatta in branch '3.5': bpo-25910: Update LICENSE (GH-2873) (GH-2968) https://github.com/python/cpython/commit/f6306e737203ac1bf1717bbf62bc58dac24b68db ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 31 22:55:22 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 01 Aug 2017 02:55:22 +0000 Subject: [docs] [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <1501556122.5.0.0295140532092.issue25910@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: New changeset b3c7d37c5ac8dbba4f1ebcf279bfceb570fb6c19 by Mariatta in branch '2.7': bpo-25910: Update LICENSE (GH-2873) (GH-2969) https://github.com/python/cpython/commit/b3c7d37c5ac8dbba4f1ebcf279bfceb570fb6c19 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 31 22:59:52 2017 From: report at bugs.python.org (Mariatta Wijaya) Date: Tue, 01 Aug 2017 02:59:52 +0000 Subject: [docs] [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <1501556392.71.0.810015372191.issue25910@psf.upfronthosting.co.za> Mariatta Wijaya added the comment: New changeset 330cdac5174e3dc6c1deb876bc12a39d7af9af84 by Mariatta in branch '3.6': bpo-25910: Update LICENSE (GH-2873) (GH-2967) https://github.com/python/cpython/commit/330cdac5174e3dc6c1deb876bc12a39d7af9af84 ---------- _______________________________________ Python tracker _______________________________________ From hendras at yahoo.com Wed Jul 26 23:33:54 2017 From: hendras at yahoo.com (Hendra Soetjahja) Date: Thu, 27 Jul 2017 03:33:54 +0000 (UTC) Subject: [docs] Bugs in Tutorial for Python 3.6.2. Section 4.4 (p. 19) In-Reply-To: References: <1141009084.155989.1501112375255.ref@mail.yahoo.com> <1141009084.155989.1501112375255@mail.yahoo.com> Message-ID: <1675945079.288974.1501126434120@mail.yahoo.com> Hi Zachary, Right you are. I need a reading glasses or get more sleep to see the indentation correctly? :)I suppose it's C/C++ programmer cognitive perception/dissonance that else goes with the if, not with for.We just glance it and started running the algo with if-else pairing in our head.It's like sleight of hand magic tricking our cognitive 'expectation' based on C/C++ experience. You probably know it immediately when I copied the code with incorrect indentation in my email. Thanks,? Hendra??---------------------------------------------------------------------------------- This message with its attachment(s) are confidential, restricted, proprietary, and only for the originally addressed recipient(s). If you are not among the intended recipient(s), you are obligated to destroy this message immediately without using, sharing, disclosing, copying, distributing, or archiving it. Anyone acting otherwise will be responsible for any ramification that may arise from the unauthorized usage or distribution of this message. The sender is not liable for any loss or damage arising in any way from this message or its attachment(s). By messaging with the sender you consent to the aforementioned terms. ---------------------------------------------------------------------------------- From: Zachary Ware To: "docs at python.org" Cc: Hendra Soetjahja Sent: Wednesday, July 26, 2017 10:53 PM Subject: Re: [docs] Bugs in Tutorial for Python 3.6.2. Section 4.4 (p. 19) Hi Hendra, On Wed, Jul 26, 2017 at 6:39 PM, Hendra Soetjahja via docs wrote: > Hi Python Development Team, > > There are 3 bugs in Tutorial for Python 3.6.2. Section 4.4 (p. 19). > These are tested for both in Python 2.7, 3.5, and 3.6 interpreters, as > module and in interactive mode. > I also tested it on Ubuntu 16.04 LTS, Windows 7, and Windows 10. Fortunately, the bug is in your transcription of the example, not in the docs (nor Python itself).? Look at the line immediately following the example: > (Yes, this is the correct code. Look closely: the else clause belongs to the for loop, not the if statement.) Note also that this section is titled "..., and else Clauses on Loops". This was also recently reported on the bug tracker; if you have any suggestions for improving the clarity of that section, please add a comment to http://bugs.python.org/issue31037 Regards, -- Zach -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shahzeb.Siddiqui at pfizer.com Thu Jul 27 18:28:36 2017 From: Shahzeb.Siddiqui at pfizer.com (Siddiqui, Shahzeb) Date: Thu, 27 Jul 2017 22:28:36 +0000 Subject: [docs] trouble uploading package Message-ID: <04A311CA8BF2B14F8E82B311197ED9E1540A5733@NDHAMREXDB01.amer.pfizer.com> Hello, I am trying to upload a python package for the first time. I am getting some issues. I looked at the documentation, and followed the process. I have created my account, and its verified. The upload is failing. Please advise [siddis14 at amrndhl1157 buildtest-framework]$ python setup.py register sdist upload running register running egg_info writing buildtest_framework.egg-info/PKG-INFO writing top-level names to buildtest_framework.egg-info/top_level.txt writing dependency_links to buildtest_framework.egg-info/dependency_links.txt reading manifest file 'buildtest_framework.egg-info/SOURCES.txt' writing manifest file 'buildtest_framework.egg-info/SOURCES.txt' running check We need to know who you are, so please choose either: 1. use your existing login, 2. register as a new user, 3. have the server generate a new password for you (and email it to you), or 4. quit Your selection [default 1]: 1 Username: shahzeb.siddiqui Password: Registering buildtest-framework to https://upload.pypi.org/legacy/ Server response (410): Project pre-registration is no longer required or supported, so continue directly to uploading files. running sdist creating buildtest-framework-1.0.1 creating buildtest-framework-1.0.1/buildtest_framework.egg-info copying files to buildtest-framework-1.0.1... copying README.rst -> buildtest-framework-1.0.1 copying setup.py -> buildtest-framework-1.0.1 copying buildtest_framework.egg-info/PKG-INFO -> buildtest-framework-1.0.1/buildtest_framework.egg-info copying buildtest_framework.egg-info/SOURCES.txt -> buildtest-framework-1.0.1/buildtest_framework.egg-info copying buildtest_framework.egg-info/dependency_links.txt -> buildtest-framework-1.0.1/buildtest_framework.egg-info copying buildtest_framework.egg-info/not-zip-safe -> buildtest-framework-1.0.1/buildtest_framework.egg-info copying buildtest_framework.egg-info/top_level.txt -> buildtest-framework-1.0.1/buildtest_framework.egg-info Writing buildtest-framework-1.0.1/setup.cfg Creating tar archive removing 'buildtest-framework-1.0.1' (and everything under it) running upload Password: Submitting dist/buildtest-framework-1.0.1.tar.gz to https://upload.pypi.org/legacy/ Upload failed (403): Invalid or non-existent authentication information. error: Upload failed (403): Invalid or non-existent authentication information. I have the following file, I didn't make any changes [siddis14 at amrndhl1157 buildtest-framework]$ cat ~/.pypirc [distutils] index-servers = pypi [pypi] repository: username: password: What is the problem? Shahzeb Siddiqui HPC Linux Engineer B2220-447.2 Groton, CT -------------- next part -------------- An HTML attachment was scrubbed... URL: