From report at bugs.python.org Fri Jan 1 00:04:18 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 01 Jan 2016 05:04:18 +0000 Subject: [docs] [issue19006] UnitTest docs should have a single list of assertions In-Reply-To: <1378914335.13.0.0543263347661.issue19006@psf.upfronthosting.co.za> Message-ID: <1451624658.59.0.115207561526.issue19006@psf.upfronthosting.co.za> Ezio Melotti added the comment: Here's a patch. ---------- assignee: docs at python -> ezio.melotti keywords: +patch stage: -> commit review versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4 Added file: http://bugs.python.org/file41462/issue19006.diff _______________________________________ Python tracker _______________________________________ From zachary.ware+pydocs at gmail.com Fri Jan 1 13:25:37 2016 From: zachary.ware+pydocs at gmail.com (Zachary Ware) Date: Fri, 1 Jan 2016 12:25:37 -0600 Subject: [docs] typo In-Reply-To: References: Message-ID: On Wed, Dec 30, 2015 at 12:59 AM, anatoly techtonik wrote: > https://docs.python.org/2/library/ctypes.html#loading-shared-libraries > > - There are several ways to loaded shared libraries into the Python process. > + There are several ways to load shared libraries into the Python process. Fixed, thanks for the report! -- Zach From report at bugs.python.org Fri Jan 1 15:09:45 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 01 Jan 2016 20:09:45 +0000 Subject: [docs] [issue24899] Add an os.path <=> pathlib equivalence table in pathlib docs In-Reply-To: <1440050617.44.0.44226546659.issue24899@psf.upfronthosting.co.za> Message-ID: <1451678985.22.0.0613633817364.issue24899@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: docs at python -> ezio.melotti stage: needs patch -> patch review versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 15:13:25 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 01 Jan 2016 20:13:25 +0000 Subject: [docs] [issue25916] wave module readframes now returns bytes not str In-Reply-To: <1450607471.45.0.396609211559.issue25916@psf.upfronthosting.co.za> Message-ID: <1451679205.07.0.993778712233.issue25916@psf.upfronthosting.co.za> R. David Murray added the comment: Agree with Martin. Only the two audio module changes are correct. However, I think we can reduce ambiguity without compromising the meaning by changing "string of bytes" to "sequence of bytes" in both of those other cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 15:24:03 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 01 Jan 2016 20:24:03 +0000 Subject: [docs] [issue25963] strptime not parsing some timezones In-Reply-To: <1451291533.28.0.979317956785.issue25963@psf.upfronthosting.co.za> Message-ID: <1451679843.88.0.729982873056.issue25963@psf.upfronthosting.co.za> R. David Murray added the comment: The code is shared by the two modules (it's in _strptime.py). So, yes. There is clearly a doc bug here (%Z needs a footnote in the table in the datetime docs), but there is no practical way to implement the parsing of arbitrary (non-locale) timezone strings, since it is not a one-to-one mapping. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, r.david.murray versions: +Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 15:44:51 2016 From: report at bugs.python.org (SilentGhost) Date: Fri, 01 Jan 2016 20:44:51 +0000 Subject: [docs] [issue25916] wave module readframes now returns bytes not str In-Reply-To: <1450607471.45.0.396609211559.issue25916@psf.upfronthosting.co.za> Message-ID: <1451681091.4.0.21834561466.issue25916@psf.upfronthosting.co.za> SilentGhost added the comment: Here is the updated patch. ---------- Added file: http://bugs.python.org/file41465/issue25916_3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 15:47:27 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 01 Jan 2016 20:47:27 +0000 Subject: [docs] [issue25916] wave module readframes now returns bytes not str In-Reply-To: <1450607471.45.0.396609211559.issue25916@psf.upfronthosting.co.za> Message-ID: <1451681247.18.0.486180794376.issue25916@psf.upfronthosting.co.za> R. David Murray added the comment: In those contexts, bytes should not be linked to the bytes object. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 15:52:42 2016 From: report at bugs.python.org (SilentGhost) Date: Fri, 01 Jan 2016 20:52:42 +0000 Subject: [docs] [issue25916] wave module readframes now returns bytes not str In-Reply-To: <1450607471.45.0.396609211559.issue25916@psf.upfronthosting.co.za> Message-ID: <1451681562.11.0.093191674263.issue25916@psf.upfronthosting.co.za> Changes by SilentGhost : Added file: http://bugs.python.org/file41466/issue25916_4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 16:00:18 2016 From: report at bugs.python.org (Camilla Montonen) Date: Fri, 01 Jan 2016 21:00:18 +0000 Subject: [docs] [issue16731] xxlimited/xxmodule docstrings ambiguous In-Reply-To: <1355946646.69.0.259699636535.issue16731@psf.upfronthosting.co.za> Message-ID: <1451682018.02.0.0681909217296.issue16731@psf.upfronthosting.co.za> Camilla Montonen added the comment: Changed xxlimited.c to xxmodule.c in the xxlimited.c docstring. ---------- versions: +Python 3.5, Python 3.6 -Python 3.4 Added file: http://bugs.python.org/file41467/issue16731.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 16:24:18 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 01 Jan 2016 21:24:18 +0000 Subject: [docs] [issue25916] wave module readframes now returns bytes not str In-Reply-To: <1450607471.45.0.396609211559.issue25916@psf.upfronthosting.co.za> Message-ID: <1451683458.42.0.610008750536.issue25916@psf.upfronthosting.co.za> Martin Panter added the comment: Patch 4 looks fine to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 16:30:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 01 Jan 2016 21:30:54 +0000 Subject: [docs] [issue25916] wave module readframes now returns bytes not str In-Reply-To: <1450607471.45.0.396609211559.issue25916@psf.upfronthosting.co.za> Message-ID: <1451683854.22.0.355273561063.issue25916@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Another uses of this idiom: "string of 16 bytes" in uuid.rst and uuid.py "string of *n* random bytes" in os.rst "string of bytes" in bytesio.c And a number of uses "bytestring", "byte string" and "bytes string". I think that either all occurrences should be changed consistently, or nothing. Personally I'm good with all these "string of bytes", "bytestring", etc, it is clear to me that that mean bytes or bytes-like objects. What is a bug, it's using the term "string" without "bytes" for bytes strings (there are a lot of such Python 2 remnants in the documentation and comments). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 16:36:15 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 01 Jan 2016 21:36:15 +0000 Subject: [docs] [issue25916] wave module readframes now returns bytes not str In-Reply-To: <1450607471.45.0.396609211559.issue25916@psf.upfronthosting.co.za> Message-ID: <1451684175.71.0.538348087198.issue25916@psf.upfronthosting.co.za> R. David Murray added the comment: As I said, I think it's like fixing style issues in code: only do it if you touch the docs for some other reason. But this patch is fine. Although we should fix the 'string' when it is really 'bytes' issues, if we can find them. Those are real bugs, not style issues. But that should be a different issue or issues from this one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 17:31:30 2016 From: report at bugs.python.org (Camilla Montonen) Date: Fri, 01 Jan 2016 22:31:30 +0000 Subject: [docs] [issue15718] Possible OverflowError in __len__ method undocumented (when called via len() function) In-Reply-To: <1345202279.02.0.767068523185.issue15718@psf.upfronthosting.co.za> Message-ID: <1451687490.55.0.838298499481.issue15718@psf.upfronthosting.co.za> Camilla Montonen added the comment: The deficiency noticed by Terry has been at least partially corrected in the len() docs https://docs.python.org/2/library/functions.html#len Return the length (the number of items) of an object. The argument may be a sequence (such as a string, bytes, tuple, list, or range) or a collection (such as a dictionary, set, or frozen set). It doesn't mention the fact that the collection has to implement __len__, but I suppose that might be obvious to experienced Python users (isn't obvious to a beginner like me, though). So perhaps this might be a welcome clarification. The issue regarding OverflowError raised by Rostyslav still remains unresolved. ---------- nosy: +Winterflower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 17:57:02 2016 From: report at bugs.python.org (Camilla Montonen) Date: Fri, 01 Jan 2016 22:57:02 +0000 Subject: [docs] [issue24899] Add an os.path <=> pathlib equivalence table in pathlib docs In-Reply-To: <1440050617.44.0.44226546659.issue24899@psf.upfronthosting.co.za> Message-ID: <1451689022.22.0.842108670394.issue24899@psf.upfronthosting.co.za> Camilla Montonen added the comment: This is a good one for beginner patch reviewers, so submitted this to the core-mentorship mailing list. ---------- nosy: +Winterflower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 18:01:16 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 01 Jan 2016 23:01:16 +0000 Subject: [docs] [issue15718] Possible OverflowError in __len__ method undocumented (when called via len() function) In-Reply-To: <1345202279.02.0.767068523185.issue15718@psf.upfronthosting.co.za> Message-ID: <1451689276.97.0.689934096641.issue15718@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: +Python 3.5, Python 3.6 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 18:46:57 2016 From: report at bugs.python.org (Vincent Davis) Date: Fri, 01 Jan 2016 23:46:57 +0000 Subject: [docs] [issue25989] documentation version switcher is broken fro 2.6, 3.2, 3.3 Message-ID: <1451692017.71.0.123733949867.issue25989@psf.upfronthosting.co.za> New submission from Vincent Davis: >From the documentation pages for python 2.7 and 3.4, 3.5, 3.6 it is possible to select another python version in the breadcrumb at the top left of the page. This is not available for python 2.6, 3.2 and 3.3. See related issue which is closed. https://bugs.python.org/issue25113 I posted this on pythondotorg but I guess this is a cpython issue not a website issue. https://github.com/python/pythondotorg/issues/868 Berker Peksag response to the report "The version switcher is activated via a versionswitcher option in Doc/Makefile in CPython codebase. Docs are generated daily by using that Makefile, but 2.6, 3.2 and 3.3 are in security-fix-only mode (which means they won't even get documentation fixes) so the daily build script skips generating docs for those versions." ---------- assignee: docs at python components: Documentation messages: 257317 nosy: Vincentdavis, docs at python priority: normal severity: normal status: open title: documentation version switcher is broken fro 2.6, 3.2, 3.3 type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 18:47:02 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 01 Jan 2016 23:47:02 +0000 Subject: [docs] [issue15718] Possible OverflowError in __len__ method undocumented (when called via len() function) In-Reply-To: <1345202279.02.0.767068523185.issue15718@psf.upfronthosting.co.za> Message-ID: <1451692022.77.0.313831784261.issue15718@psf.upfronthosting.co.za> Martin Panter added the comment: Issue 10289 proposes to link from len() to __len__() in the documentation. I think the limitation only needs to be documented for __len__(); there are other ways to invoke it as well. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 1 18:52:51 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 01 Jan 2016 23:52:51 +0000 Subject: [docs] [issue25959] tkinter - PhotoImage.zoom() causes segfault In-Reply-To: <1451171771.79.0.252031360467.issue25959@psf.upfronthosting.co.za> Message-ID: <1451692371.59.0.106535344324.issue25959@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Tk ticket update: '''aspect added on 2015-12-28 00:30:33: I can reproduce this crash on 8.5.18 and 8.6.4, but it appears to be fixed in trunk: "not enough free memory for image buffer".''' We should see fix in 3.6. Doc addition is not exactly trivial, as there is only the barest mention of images in https://docs.python.org/3/library/tkinter.html#images. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From ezio.melotti at gmail.com Fri Jan 1 19:05:54 2016 From: ezio.melotti at gmail.com (ezio.melotti at gmail.com) Date: Sat, 02 Jan 2016 00:05:54 -0000 Subject: [docs] include the "object" type in the lists of documented types (issue 16508) Message-ID: <20160102000554.24091.58947@psf.upfronthosting.co.za> http://bugs.python.org/review/16508/diff/15301/Doc/library/functions.rst File Doc/library/functions.rst (right): http://bugs.python.org/review/16508/diff/15301/Doc/library/functions.rst#newcode855 Doc/library/functions.rst:855: The constructor does not accept any arguments. What about: `object` is a type used as base class for all other classes. When called, it accepts no arguments and returns a new unique and featureless object. http://bugs.python.org/review/16508/diff/15301/Doc/library/functions.rst#newcode861 Doc/library/functions.rst:861: the :class:`object` class. I think this note might be removed, and replaced with a sentence that says that object already defines some methods/attributes (but not others) and link to the list of methods. There it can be explained in more details what are the methods/attributes, and that __dict__ is not one of them. http://bugs.python.org/review/16508/diff/15301/Doc/library/stdtypes.rst File Doc/library/stdtypes.rst (right): http://bugs.python.org/review/16508/diff/15301/Doc/library/stdtypes.rst#newcode4326 Doc/library/stdtypes.rst:4326: instances of :class:`object`, the universal type. Most of these support I'm not sure I would use universal here. http://bugs.python.org/review/16508/diff/15301/Doc/reference/datamodel.rst File Doc/reference/datamodel.rst (right): http://bugs.python.org/review/16508/diff/15301/Doc/reference/datamodel.rst#newcode131 Doc/reference/datamodel.rst:131: whether built-in or not, are derived from it. Extension modules You already called it "ultimate", "universal", and now "fundamental". I don't like any of those terms. You can simply say: All types, built-in or not, are derived from :class:`object`. http://bugs.python.org/review/16508/diff/15301/Doc/reference/datamodel.rst#newcode1146 Doc/reference/datamodel.rst:1146: :meth:`__del__` method. Note that it is possible I wonder if it's better to split the actual object methods, with the ones that users must define themselves. The former can use :meth:`object.__*__` and describe the behavior of the default implementation, whereas the latter can use :meth:`cls.__*__`, describe what the method should do, and possibly link to the default implementation. This might also save you from repeating "object doesn't implement this method" several times. http://bugs.python.org/review/16508/diff/15301/Lib/test/test_class.py File Lib/test/test_class.py (right): http://bugs.python.org/review/16508/diff/15301/Lib/test/test_class.py#newcode541 Lib/test/test_class.py:541: self.assertFalse(hasattr(c, "__call__")) Maybe add a test for __dict__ too. http://bugs.python.org/review/16508/ From m.recachinas at gmail.com Fri Jan 1 19:12:38 2016 From: m.recachinas at gmail.com (m.recachinas at gmail.com) Date: Sat, 02 Jan 2016 00:12:38 -0000 Subject: [docs] Add an os.path <=> pathlib equivalence table in pathlib docs (issue 24899) Message-ID: <20160102001238.24820.63477@psf.upfronthosting.co.za> I've reviewed the patch -- it looks good. There's one small change (grp.getpwuid -> pwd.getpwuid on line 1070), but no other inaccuracies. As I noted in the line-by-line patch review, the multi-line rows (e.g., lines 1046 - 1047 or 1069 - 1070) render differently in the html (with `make html`). I tried adding another newline in between, but this introduced excess whitespace in the rendered html. http://bugs.python.org/review/24899/diff/15552/Doc/library/pathlib.rst File Doc/library/pathlib.rst (right): http://bugs.python.org/review/24899/diff/15552/Doc/library/pathlib.rst#newcode1047 Doc/library/pathlib.rst:1047: | | grp.getgrgid()[0] | This row (lines 1046 - 1047) and lines 1069 - 1070 look perfectly formatted here in the .rst file, but when you build the docs, `os.stat()` and `grp.getgrgid()[0]` appear as one line separated by a space, and the `[0]` trails on the next line. Unsure if this is an issue, but it's worth mentioning as a formatting comment. http://bugs.python.org/review/24899/diff/15552/Doc/library/pathlib.rst#newcode1070 Doc/library/pathlib.rst:1070: | | grp.getpwuid()[0] | The `grp` module has no member function `getpwuid`. `getpwuid` is located in the `pwd` module. http://bugs.python.org/review/24899/ From report at bugs.python.org Fri Jan 1 23:28:53 2016 From: report at bugs.python.org (Bruce Frederiksen) Date: Sat, 02 Jan 2016 04:28:53 +0000 Subject: [docs] [issue25991] readline example eventually consumes all memory Message-ID: <1451708933.83.0.797303528676.issue25991@psf.upfronthosting.co.za> New submission from Bruce Frederiksen: The Example in the readline documentation (section 6.7 of the Library Reference) shows how to save your readline history in a file, and restore it each time you start Python. The problem with the Example is that it does not include a call to readline.set_history_length and the default is -1 (infinite). As a Python developer, I start Python quite a lot and had a .python_history file that was 850M bytes. Just starting Python was causing my system to thrash before the first prompt (>>>) even appeared. I suggest adding the following line to the example to avoid this: readline.set_history_length(1000) I'm not sure how far back this goes in terms of earlier versions of Python, but probably quite far. ---------- assignee: docs at python components: Documentation messages: 257325 nosy: dangyogi, docs at python priority: normal severity: normal status: open title: readline example eventually consumes all memory type: resource usage versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 02:27:48 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 Jan 2016 07:27:48 +0000 Subject: [docs] [issue25917] Fixing howto links in docs In-Reply-To: <1450610247.39.0.486318634402.issue25917@psf.upfronthosting.co.za> Message-ID: <20160102072744.8289.31405@psf.io> Roundup Robot added the comment: New changeset 521a402ae177 by Senthil Kumaran in branch '3.4': Issue25917 : Fix howto links in docs. Point the reference documentation instead of wiki. https://hg.python.org/cpython/rev/521a402ae177 New changeset 6b9d8957aeef by Senthil Kumaran in branch '3.5': merge from 3.4 https://hg.python.org/cpython/rev/6b9d8957aeef New changeset 3a6b1186745f by Senthil Kumaran in branch 'default': merge from 3.5 https://hg.python.org/cpython/rev/3a6b1186745f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 02:30:06 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 02 Jan 2016 07:30:06 +0000 Subject: [docs] [issue25917] Fixing howto links in docs In-Reply-To: <1450610247.39.0.486318634402.issue25917@psf.upfronthosting.co.za> Message-ID: <1451719806.81.0.64548172642.issue25917@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Thanks for the helpful, patch. I modified it to include only the faq.rst and functions.rst and applied it. ---------- assignee: docs at python -> orsenthil nosy: +orsenthil stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 02:40:52 2016 From: report at bugs.python.org (Sonali Gupta) Date: Sat, 02 Jan 2016 07:40:52 +0000 Subject: [docs] [issue25909] Incorrect documentation for PyMapping_Items and like In-Reply-To: <1450525085.87.0.352365699992.issue25909@psf.upfronthosting.co.za> Message-ID: <1451720452.65.0.824489422659.issue25909@psf.upfronthosting.co.za> Sonali Gupta added the comment: The documentation in mapping.rst and the comments in abstract.h have been changed for PyMapping_Items, PyMapping_Keys and PyMapping_Values. ---------- Added file: http://bugs.python.org/file41472/bug.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 03:14:28 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 02 Jan 2016 08:14:28 +0000 Subject: [docs] [issue23560] Group the docs of similar methods in stdtypes.rst In-Reply-To: <1425288490.4.0.288876913126.issue23560@psf.upfronthosting.co.za> Message-ID: <1451722468.65.0.49648512021.issue23560@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 03:25:36 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 02 Jan 2016 08:25:36 +0000 Subject: [docs] [issue16544] Add external link to ast docs In-Reply-To: <1353702032.57.0.687396127567.issue16544@psf.upfronthosting.co.za> Message-ID: <1451723136.71.0.163306436338.issue16544@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: docs at python -> ezio.melotti versions: +Python 3.6 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 03:41:51 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 02 Jan 2016 08:41:51 +0000 Subject: [docs] [issue24024] str.__doc__ needs an update In-Reply-To: <1429708426.75.0.208318155296.issue24024@psf.upfronthosting.co.za> Message-ID: <1451724111.3.0.151350321323.issue24024@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> docs at python components: +Documentation keywords: +easy nosy: +docs at python stage: -> needs patch type: -> enhancement versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 03:58:08 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 02 Jan 2016 08:58:08 +0000 Subject: [docs] [issue13814] Document why generators don't support the context management protocol In-Reply-To: <1326883396.25.0.884733470267.issue13814@psf.upfronthosting.co.za> Message-ID: <1451725088.11.0.858052897472.issue13814@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: needs patch -> patch review versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 06:22:03 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 02 Jan 2016 11:22:03 +0000 Subject: [docs] [issue25959] tkinter - PhotoImage.zoom() causes segfault In-Reply-To: <1451171771.79.0.252031360467.issue25959@psf.upfronthosting.co.za> Message-ID: <1451733723.86.0.867897481576.issue25959@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think it is enough just to update a docstring. Adding comprehensive RST documentation for Tkinter widgets is different issue. ---------- keywords: +patch Added file: http://bugs.python.org/file41473/tkinter_photo_zoom_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 11:40:37 2016 From: report at bugs.python.org (Alessandro Cucci) Date: Sat, 02 Jan 2016 16:40:37 +0000 Subject: [docs] [issue13305] datetime.strftime("%Y") not consistent for years < 1000 In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za> Message-ID: <1451752837.66.0.384433712952.issue13305@psf.upfronthosting.co.za> Changes by Alessandro Cucci : Added file: http://bugs.python.org/file41476/doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 15:12:28 2016 From: report at bugs.python.org (Patrik Dufresne) Date: Sat, 02 Jan 2016 20:12:28 +0000 Subject: [docs] [issue24110] zipfile.ZipFile.write() does not accept bytes arcname In-Reply-To: <1430515803.94.0.193757537296.issue24110@psf.upfronthosting.co.za> Message-ID: <1451765548.83.0.201399629445.issue24110@psf.upfronthosting.co.za> Patrik Dufresne added the comment: I'm converting my project into python3. I'm encountering issue with zipfile encoding. Look like, it only support unicode path. This is a huge issue since path are, by definition, bytes. You may store a file name with an invalid character without issue on the filesystem. As such, arcname should support bytes. Like, Tar, zip file format doesn't define a specific encoding. You may store filename as bytes. ---------- nosy: +Patrik Dufresne _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 15:20:18 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jan 2016 20:20:18 +0000 Subject: [docs] [issue24110] zipfile.ZipFile.write() does not accept bytes arcname In-Reply-To: <1430515803.94.0.193757537296.issue24110@psf.upfronthosting.co.za> Message-ID: <1451766018.53.0.746086490651.issue24110@psf.upfronthosting.co.za> R. David Murray added the comment: As noted, adding that support is the subject of issue 10757. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 16:25:13 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 02 Jan 2016 21:25:13 +0000 Subject: [docs] [issue24024] str.__doc__ needs an update In-Reply-To: <1429708426.75.0.208318155296.issue24024@psf.upfronthosting.co.za> Message-ID: <1451769913.85.0.448448680983.issue24024@psf.upfronthosting.co.za> Martin Panter added the comment: Slightly easier to read version: >>> pprint(str.__doc__) ("str(object='') -> str\n" 'str(bytes_or_buffer[, encoding[, errors]]) -> str\n' '\n' 'Create a new string object from the given object. If encoding or\n' 'errors is specified, then the object must expose a data buffer\n' 'that will be decoded using the given encoding and error handler.\n' 'Otherwise, returns the result of object.__str__() (if defined)\n' 'or repr(object).\n' 'encoding defaults to sys.getdefaultencoding().\n' "errors defaults to 'strict'.") I don?t exactly understand your complaint. Do you want to say encoding directly defaults to UTF-8, bypassing the getdefaultencoding() reference? Do you want to explicitly point out that bytes() and bytearray() expose a data buffer and can therefore be decoded? This is already hinted in the name bytes_or_buffer. Do you want to clarify that the Otherwise sentence applies when encoding and errors are not specified, rather than when the object does not expose a buffer? Maybe another thing to change could be fixing the second signature, to show that an explicit encoding can be omitted, and bytes_or_buffer is not a valid keyword name: str(object, encoding="utf-8", errors="strict") ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 16:27:32 2016 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 02 Jan 2016 21:27:32 +0000 Subject: [docs] [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451770052.04.0.891845217475.issue25813@psf.upfronthosting.co.za> Mark Lawrence added the comment: Clearly nobody is interested so closing. ---------- status: open -> closed versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 16:32:57 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 02 Jan 2016 21:32:57 +0000 Subject: [docs] [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451770377.44.0.0281961041959.issue25813@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> needs patch status: closed -> open type: -> enhancement versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 16:34:50 2016 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 02 Jan 2016 21:34:50 +0000 Subject: [docs] [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451770490.28.0.0914010908692.issue25813@psf.upfronthosting.co.za> Mark Lawrence added the comment: I am the OP, this stays closed. If you couldn't be bothered to reply before please raise a new issue. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 16:35:32 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jan 2016 21:35:32 +0000 Subject: [docs] [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451770532.86.0.0644710317172.issue25813@psf.upfronthosting.co.za> R. David Murray added the comment: I think Yuri might be interested. ---------- assignee: docs at python -> yselivanov nosy: +r.david.murray, yselivanov stage: needs patch -> status: closed -> open type: enhancement -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 16:38:22 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jan 2016 21:38:22 +0000 Subject: [docs] [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451770702.82.0.823260998403.issue25813@psf.upfronthosting.co.za> R. David Murray added the comment: Mark, please don't close the issue. You raised a valid point, it got overlooked, but like I said I think Yuri will be interested in looking at it. This is a volunteer operation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 16:38:39 2016 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 02 Jan 2016 21:38:39 +0000 Subject: [docs] [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451770719.05.0.5367252532.issue25813@psf.upfronthosting.co.za> Mark Lawrence added the comment: For the final time, *I* am the OP and not one of you could be bothered before so this remains closed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 16:39:32 2016 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 02 Jan 2016 21:39:32 +0000 Subject: [docs] [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451770772.36.0.950911929564.issue25813@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 16:44:10 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 02 Jan 2016 21:44:10 +0000 Subject: [docs] [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451771050.91.0.409558773895.issue25813@psf.upfronthosting.co.za> R. David Murray added the comment: I'll leave it closed, but I don't think that is best for the community. ---------- assignee: yselivanov -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 17:55:38 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 02 Jan 2016 22:55:38 +0000 Subject: [docs] [issue13305] datetime.strftime("%Y") not consistent for years < 1000 In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za> Message-ID: <1451775338.69.0.688440701936.issue13305@psf.upfronthosting.co.za> Martin Panter added the comment: At the bottom of it suggests that this four-digit field width specifier is not portable. Does that also hold for the datetime version? It seems like a bad idea to recommend an unportable workaround for a portability problem. Also, in the patch it is not clear if you are referring to strptime(), strftime(), or both. On Linux, datetime.strptime(..., "%4Y") fails for me. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 2 20:00:32 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 03 Jan 2016 01:00:32 +0000 Subject: [docs] [issue1753718] base64 "legacy" functions violate RFC 3548 Message-ID: <1451782832.23.0.557933918207.issue1753718@psf.upfronthosting.co.za> Martin Panter added the comment: I was waiting for you to finish here to avoid any new merge conflicts. Now that you have committed your patch, I will try and work on mine in the next few days, and I am happy to update the doc strings at the same time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 01:20:49 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 06:20:49 +0000 Subject: [docs] [issue13305] datetime.strftime("%Y") not consistent for years < 1000 In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za> Message-ID: <1451802049.14.0.852114428632.issue13305@psf.upfronthosting.co.za> Ezio Melotti added the comment: > Also, using %4Y seems to consistently produce zero-padded values across > different platforms. Actually I was wrong. Based on some more testing I did on Linux and Windows 8 and the previous comments in this thread, it seems that, with 1 as year: * '%4Y' does produces '0001' on Linux but gives a value error on Windows and '4Y' on OS X; * '%Y' produces '1' on Linux and '0001' on Windows and OS X; So the problem is only on Linux and only with years <1000, where to have a zero-padded value %4Y can be used instead. I don't know if these results are true for all versions of Linux/Win/OSX, so the note could just say that: 1) some platforms (e.g. Linux) don't zero-pad years <1000; 2) some platforms (e.g. Linux) support %4Y to add padding, but this doesn't work on other platforms. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 01:35:40 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 06:35:40 +0000 Subject: [docs] [issue23890] assertRaises increases reference counter In-Reply-To: <1428518225.53.0.665360255509.issue23890@psf.upfronthosting.co.za> Message-ID: <1451802940.18.0.810675559085.issue23890@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python stage: -> needs patch versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 04:04:15 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Jan 2016 09:04:15 +0000 Subject: [docs] [issue21221] Minor struct_time documentation bug In-Reply-To: <1397500160.88.0.743491348049.issue21221@psf.upfronthosting.co.za> Message-ID: <20160103090411.77241.28750@psf.io> Roundup Robot added the comment: New changeset fae779a811ec by Senthil Kumaran in branch '3.4': Issue21221 - Explain the usage of tm_isdst attribute of mktime, with valid https://hg.python.org/cpython/rev/fae779a811ec New changeset 3b7a7ea1214c by Senthil Kumaran in branch '3.5': merge from 3.4 https://hg.python.org/cpython/rev/3b7a7ea1214c New changeset b729e7ae2747 by Senthil Kumaran in branch 'default': merge from 3.5 https://hg.python.org/cpython/rev/b729e7ae2747 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 04:04:24 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 03 Jan 2016 09:04:24 +0000 Subject: [docs] [issue21221] Minor struct_time documentation bug In-Reply-To: <1397500160.88.0.743491348049.issue21221@psf.upfronthosting.co.za> Message-ID: <20160103090422.70421.44240@psf.io> Roundup Robot added the comment: New changeset f7324e5935f8 by Senthil Kumaran in branch '2.7': Backport doc improvements for Issue21221 - Explain the usage of tm_isdst https://hg.python.org/cpython/rev/f7324e5935f8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 04:14:29 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 03 Jan 2016 09:14:29 +0000 Subject: [docs] [issue21221] Minor struct_time documentation bug In-Reply-To: <1397500160.88.0.743491348049.issue21221@psf.upfronthosting.co.za> Message-ID: <1451812469.95.0.763585377585.issue21221@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- assignee: docs at python -> orsenthil nosy: +orsenthil resolution: -> fixed status: open -> closed versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 04:57:23 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 09:57:23 +0000 Subject: [docs] [issue23675] glossary entry for 'method resolution order' links to something with python 2.3 in the title In-Reply-To: <1426456234.82.0.0903487839974.issue23675@psf.upfronthosting.co.za> Message-ID: <1451815043.16.0.749756302706.issue23675@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> docs at python components: +Documentation keywords: +easy nosy: +docs at python, ezio.melotti stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 04:58:14 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 09:58:14 +0000 Subject: [docs] [issue23677] Mention dict and set comps in library reference In-Reply-To: <1426495855.1.0.56894829498.issue23677@psf.upfronthosting.co.za> Message-ID: <1451815094.34.0.273213830218.issue23677@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> patch review type: -> enhancement versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 04:58:39 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 09:58:39 +0000 Subject: [docs] [issue23702] docs.python.org/3/howto/descriptor.html still refers to "unbound methods" In-Reply-To: <1426708114.47.0.635748134131.issue23702@psf.upfronthosting.co.za> Message-ID: <1451815119.08.0.679863310392.issue23702@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 05:01:40 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 10:01:40 +0000 Subject: [docs] [issue23762] python.org page on new-style classes should be updated In-Reply-To: <1427207285.84.0.436806674049.issue23762@psf.upfronthosting.co.za> Message-ID: <1451815300.38.0.749818370653.issue23762@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- resolution: -> third party status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 05:06:50 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 10:06:50 +0000 Subject: [docs] [issue23986] Inaccuracy about "in" keyword for list and tuple In-Reply-To: <1429255378.08.0.140067438597.issue23986@psf.upfronthosting.co.za> Message-ID: <1451815610.6.0.129940797535.issue23986@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 05:16:53 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 10:16:53 +0000 Subject: [docs] [issue21593] Clarify re.search documentation first match In-Reply-To: <1401287966.38.0.860641123785.issue21593@psf.upfronthosting.co.za> Message-ID: <1451816213.5.0.271720889279.issue21593@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Regular Expressions nosy: +ezio.melotti, mrabarnett stage: resolved -> commit review versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 08:56:15 2016 From: report at bugs.python.org (Dimitri Papadopoulos Orfanos) Date: Sun, 03 Jan 2016 13:56:15 +0000 Subject: [docs] [issue26001] Tutorial: write() does not expect string in binary mode Message-ID: <1451829375.45.0.0188699168911.issue26001@psf.upfronthosting.co.za> New submission from Dimitri Papadopoulos Orfanos: About section "7.2.1. Methods of File Objects" of the tutorial: 1. Method read() is documented as follows: reads some quantity of data and returns it as a string or bytes object. Indeed read() returns a string in text mode and bytes in binary mode. For the sake of clarity, I suggest changing to: reads some quantity of data and returns it as a string (in text mode) or bytes object (in binary mode). This might seem long-winded but I believe it would help those moving from Python 2 to Python 3. 2. Method write() is documented as follows: To write something other than a string, it needs to be converted to a string first While this is correct in text mode, it is wrong in binary mode. May I suggest: To write something other than a string (in text mode) or bytes object (in binary mode), it needs to be converted first ---------- assignee: docs at python components: Documentation messages: 257418 nosy: Dimitri Papadopoulos Orfanos, docs at python priority: normal severity: normal status: open title: Tutorial: write() does not expect string in binary mode versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 14:08:18 2016 From: report at bugs.python.org (tzickel) Date: Sun, 03 Jan 2016 19:08:18 +0000 Subject: [docs] [issue19576] "Non-Python created threads" documentation doesn't mention PyEval_InitThreads() In-Reply-To: <1384379370.85.0.232061958171.issue19576@psf.upfronthosting.co.za> Message-ID: <1451848097.97.0.398904358311.issue19576@psf.upfronthosting.co.za> tzickel added the comment: I think that the document regarding PyGILState_Ensure and PyEval_InitThreads should be clarified better, written in issue #26003 ---------- nosy: +tzickel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 16:19:48 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 03 Jan 2016 21:19:48 +0000 Subject: [docs] [issue23677] Mention dict and set comps in library reference In-Reply-To: <1426495855.1.0.56894829498.issue23677@psf.upfronthosting.co.za> Message-ID: <1451855988.66.0.17143178365.issue23677@psf.upfronthosting.co.za> Martin Panter added the comment: The distiction about non-empty sets is a bit misleading. You can create an empty set via comprehension: >>> {x for x in ()} set() ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 18:55:20 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 03 Jan 2016 23:55:20 +0000 Subject: [docs] [issue24632] Improve documentation about __main__.py In-Reply-To: <1436856841.67.0.538500952598.issue24632@psf.upfronthosting.co.za> Message-ID: <1451865320.71.0.576814509977.issue24632@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ncoghlan versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 19:03:50 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 00:03:50 +0000 Subject: [docs] [issue24715] Sorting HOW TO: bad example for reverse sort stability In-Reply-To: <1437817871.39.0.0442628081402.issue24715@psf.upfronthosting.co.za> Message-ID: <1451865830.33.0.0654543705083.issue24715@psf.upfronthosting.co.za> Ezio Melotti added the comment: LGTM, however I would also show the sorted output too. ---------- nosy: +ezio.melotti stage: -> commit review type: -> enhancement versions: +Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 19:13:33 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 00:13:33 +0000 Subject: [docs] [issue24896] It is undocumented that re.UNICODE affects re.IGNORECASE In-Reply-To: <1439987891.31.0.547960058443.issue24896@psf.upfronthosting.co.za> Message-ID: <1451866413.75.0.97004566501.issue24896@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Regular Expressions nosy: +ezio.melotti, mrabarnett stage: -> needs patch type: -> enhancement versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 19:14:06 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 00:14:06 +0000 Subject: [docs] [issue24898] Documentation for str.find() is confusing In-Reply-To: <1440038088.25.0.955584919768.issue24898@psf.upfronthosting.co.za> Message-ID: <1451866446.08.0.405608453164.issue24898@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy stage: -> needs patch type: -> enhancement versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 19:15:47 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 00:15:47 +0000 Subject: [docs] [issue24918] Docs layout bug In-Reply-To: <1440361207.71.0.0873906255469.issue24918@psf.upfronthosting.co.za> Message-ID: <1451866547.25.0.718427174713.issue24918@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +ezio.melotti versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 21:00:43 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 04 Jan 2016 02:00:43 +0000 Subject: [docs] [issue24898] Documentation for str.find() is confusing In-Reply-To: <1440038088.25.0.955584919768.issue24898@psf.upfronthosting.co.za> Message-ID: <20160104020039.9620.63037@psf.io> Roundup Robot added the comment: New changeset 7150e8a38c63 by Senthil Kumaran in branch '3.4': Issue24898 - Improve str.find documentation. https://hg.python.org/cpython/rev/7150e8a38c63 New changeset 164b564e3c1a by Senthil Kumaran in branch '3.5': merge from 3.4 https://hg.python.org/cpython/rev/164b564e3c1a New changeset 136adbcefa5f by Senthil Kumaran in branch 'default': merge from 3.5 https://hg.python.org/cpython/rev/136adbcefa5f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 21:07:17 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 04 Jan 2016 02:07:17 +0000 Subject: [docs] [issue24898] Documentation for str.find() is confusing In-Reply-To: <1440038088.25.0.955584919768.issue24898@psf.upfronthosting.co.za> Message-ID: <20160104020713.124866.38477@psf.io> Roundup Robot added the comment: New changeset da934a19855b by Senthil Kumaran in branch '2.7': Backport documentation improvement. https://hg.python.org/cpython/rev/da934a19855b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 21:08:31 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 04 Jan 2016 02:08:31 +0000 Subject: [docs] [issue24898] Documentation for str.find() is confusing In-Reply-To: <1440038088.25.0.955584919768.issue24898@psf.upfronthosting.co.za> Message-ID: <1451873311.65.0.752781903281.issue24898@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Updated the docs as per Georg's suggestion. Thank you Ted Lemon for bringing this up. ---------- assignee: docs at python -> orsenthil nosy: +orsenthil resolution: -> fixed stage: needs patch -> resolved status: open -> closed versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 21:13:59 2016 From: report at bugs.python.org (Upendra Kumar) Date: Mon, 04 Jan 2016 02:13:59 +0000 Subject: [docs] [issue26001] Tutorial: write() does not expect string in binary mode In-Reply-To: <1451829375.45.0.0188699168911.issue26001@psf.upfronthosting.co.za> Message-ID: <1451873639.2.0.830589775297.issue26001@psf.upfronthosting.co.za> Upendra Kumar added the comment: I also think that for better clarification, binary mode and text mode should be specified clearly for both methods read() and write(). For read(), I have changed it to: ' some quantity of data and returns it as a string (in text mode) or bytes object (in binary mode).' For write(), I have changed it to: ' To write something other than a string (in text mode) or bytes object (in binary mode), it needs to be converted first to string or bytes object respectively. ' Please if someone could review it, as I have not submitted a patch related to docs before. And I am not sure, if I have made correct changes at right place. ---------- keywords: +patch nosy: +upendra-k14 Added file: http://bugs.python.org/file41486/fileiotutorial.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 22:23:41 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 03:23:41 +0000 Subject: [docs] [issue25179] PEP 498 f-strings need to be documented In-Reply-To: <1442688918.61.0.173837832796.issue25179@psf.upfronthosting.co.za> Message-ID: <1451877821.55.0.4111559047.issue25179@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 22:25:33 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 03:25:33 +0000 Subject: [docs] [issue25197] Allow documentation switcher to change url to /3/ and /dev/ In-Reply-To: <1442780092.62.0.798906880968.issue25197@psf.upfronthosting.co.za> Message-ID: <1451877933.01.0.375122815427.issue25197@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti, georg.brandl stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 22:36:12 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 03:36:12 +0000 Subject: [docs] [issue25381] Doc: Use of old description of raise in Python3 In-Reply-To: <1444637496.5.0.854563191712.issue25381@psf.upfronthosting.co.za> Message-ID: <1451878572.6.0.714429764449.issue25381@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti type: -> enhancement versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 22:41:04 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 03:41:04 +0000 Subject: [docs] [issue25433] whitespace in strip()/lstrip()/rstrip() In-Reply-To: <1445170536.34.0.94220475409.issue25433@psf.upfronthosting.co.za> Message-ID: <1451878864.57.0.37482531309.issue25433@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +ezio.melotti stage: -> needs patch versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 22:42:47 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 03:42:47 +0000 Subject: [docs] [issue25517] regex howto example in "Lookahead Assertions" In-Reply-To: <1446199646.71.0.249231376897.issue25517@psf.upfronthosting.co.za> Message-ID: <1451878967.06.0.0236979755697.issue25517@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Regular Expressions nosy: +ezio.melotti, mrabarnett versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 22:52:01 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 03:52:01 +0000 Subject: [docs] [issue25743] Clarify exactly what \w matches in UNICODE mode In-Reply-To: <1448639458.78.0.12264064003.issue25743@psf.upfronthosting.co.za> Message-ID: <1451879521.6.0.897029639016.issue25743@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Regular Expressions nosy: +ezio.melotti, mrabarnett stage: -> needs patch type: -> enhancement versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 22:55:57 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 03:55:57 +0000 Subject: [docs] [issue25810] Python 3 documentation for eval is incorrect In-Reply-To: <1449346403.16.0.483198527619.issue25810@psf.upfronthosting.co.za> Message-ID: <1451879757.47.0.919963475423.issue25810@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti type: -> enhancement versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 22:56:32 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 04 Jan 2016 03:56:32 +0000 Subject: [docs] [issue25866] Reference 3. Data Model: miscellaneous minor cleanups on the word "sequence". In-Reply-To: <1450167167.45.0.614001159878.issue25866@psf.upfronthosting.co.za> Message-ID: <1451879792.53.0.0924805117728.issue25866@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +ezio.melotti stage: -> needs patch versions: +Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 3 23:55:59 2016 From: report at bugs.python.org (Kushal Das) Date: Mon, 04 Jan 2016 04:55:59 +0000 Subject: [docs] [issue19006] UnitTest docs should have a single list of assertions In-Reply-To: <1378914335.13.0.0543263347661.issue19006@psf.upfronthosting.co.za> Message-ID: <1451883359.57.0.196616457754.issue19006@psf.upfronthosting.co.za> Kushal Das added the comment: The patch looks good to me. Commit :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 04:42:13 2016 From: report at bugs.python.org (Dimitri Papadopoulos Orfanos) Date: Mon, 04 Jan 2016 09:42:13 +0000 Subject: [docs] [issue25433] whitespace in strip()/lstrip()/rstrip() In-Reply-To: <1445170536.34.0.94220475409.issue25433@psf.upfronthosting.co.za> Message-ID: <1451900533.26.0.027212012044.issue25433@psf.upfronthosting.co.za> Dimitri Papadopoulos Orfanos added the comment: In Python 2, as far as I can understand, string.whitespace and str.isspace() are different: * str.isspace() is built upon the C isspace() function and is therefore locale-dependant. Python heavily relies on isspace() to detect "whitespace" characters. * string.whitespace is a list of "ASCII whitespace characters" carved in stone. As far as I can see string.whitespace is defined but not used anywhere in Python source code. See source code: * Modules/stringobject.c around line 3319: [...] string_isspace(PyStringObject *self) { [...] e = p + PyString_GET_SIZE(self); for (; p < e; p++) { if (!isspace(*p)) return PyBool_FromLong(0); } return PyBool_FromLong(1); [...] * Lib/string.py near line 23: whitespace = ' \t\n\r\v\f' Functions strip()/lstrip()/rstrip() use str.isspace() and have nothing to do with string.whitespace: * Modules/stringobject.c around line 1861: [...] do_strip(PyStringObject *self, int striptype) { [...] i = 0; if (striptype != RIGHTSTRIP) { while (i < len && isspace(Py_CHARMASK(s[i]))) { i++; } } [...] Therefore I suggest the documentation of Python 2.7 points to str.isspace() wherever the term "whitespace" is used in the documentation - including this specific case of strip()/lstrip()/rstrip(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 05:06:11 2016 From: report at bugs.python.org (Dimitri Papadopoulos Orfanos) Date: Mon, 04 Jan 2016 10:06:11 +0000 Subject: [docs] [issue25433] whitespace in strip()/lstrip()/rstrip() In-Reply-To: <1445170536.34.0.94220475409.issue25433@psf.upfronthosting.co.za> Message-ID: <1451901971.2.0.716238404036.issue25433@psf.upfronthosting.co.za> Dimitri Papadopoulos Orfanos added the comment: In Python 3 the situation is similar: * The Py_UNICODE_ISSPACE macro is used internally to define str.isspace() and wherever Python needs to detect "whitespace" characters in strings. * There is an equivalent function Py_ISSPACE for bytes/bytearray. * The bytearray.strip() implementation for bytearray relies on hardcoded ASCII whitespaces instead of Py_ISSPACE. * string.whitespace is a list of "ASCII whitespace characters" carved in stone. As far as I can see string.whitespace is defined but not used anywhere in Python source code. Therefore I suggest the documentation of Python 3 points to str.isspace() wherever the term "whitespace" is used in any documentation related to strings - including this specific case of strip()/lstrip()/rstrip(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 11:51:53 2016 From: report at bugs.python.org (Ramchandra Apte) Date: Mon, 04 Jan 2016 16:51:53 +0000 Subject: [docs] [issue17006] Add advice on best practices for hashing secrets In-Reply-To: <1451618657.96.0.304750754668.issue17006@psf.upfronthosting.co.za> Message-ID: Ramchandra Apte added the comment: It is good to add warnings; if they are ignored it is little worse than the status quo. On 1 January 2016 at 08:54, Ezio Melotti wrote: > > Ezio Melotti added the comment: > > > People are going to skip warning boxes if they occur too often. > > I'm not sure I agree. This would be true if they were abused for trivial > things ("Warnings: using .pop() on a empty list will return an > IndexError!"), but I don't think they are. > > I think warnings are ignored only by people that are already familiar with > the module and its limitation/issues, and that know what they are doing. > If the warning is not evident, people are going to miss it [0]. > > If warnings are used correctly, people will spot them easily and read them > (or ignore them if they already know what they are warning against). > > [0]: I know I missed it in e.g. https://api.jquery.com/die/ -- the > function is deprecated, but (currently) this is only written in the top > right corner and in small in the category at the top -- two places that are > easily overlooked. https://api.jquery.com/toggle-event/ on the other > hand has a clearly visible yellow box at the top that immediately says that > the method is deprecated. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 14:22:22 2016 From: report at bugs.python.org (Hamza T Khan) Date: Mon, 04 Jan 2016 19:22:22 +0000 Subject: [docs] [issue25496] tarfile: Default value for compresslevel is not documented In-Reply-To: <1446021567.06.0.820338275323.issue25496@psf.upfronthosting.co.za> Message-ID: <1451935342.74.0.422537427208.issue25496@psf.upfronthosting.co.za> Hamza T Khan added the comment: Here is trivial fix for this issue. This is my first patch and I hope that it gets accepted and integrated. hamza at hamza-ub94:~/git/cpython$ grep compresslevel Lib/tarfile.py def gzopen(cls, name, mode="r", fileobj=None, compresslevel=9, **kwargs): fileobj = gzip.GzipFile(name, mode + "b", compresslevel, fileobj) def bz2open(cls, name, mode="r", fileobj=None, compresslevel=9, **kwargs): compresslevel=compresslevel) hamza at hamza-ub94:~/git/cpython$ ---------- hgrepos: +330 keywords: +patch nosy: +hamzatkhan94 Added file: http://bugs.python.org/file41499/Issue25496.v1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 16:43:19 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 04 Jan 2016 21:43:19 +0000 Subject: [docs] [issue26010] document CO_* constants Message-ID: <1451943799.6.0.914278570087.issue26010@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- assignee: docs at python components: Documentation keywords: needs review nosy: docs at python, r.david.murray, yselivanov priority: normal severity: normal stage: patch review status: open title: document CO_* constants type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 16:45:12 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 04 Jan 2016 21:45:12 +0000 Subject: [docs] [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451943912.03.0.89406990615.issue25813@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- superseder: -> document CO_* constants _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 16:47:03 2016 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 04 Jan 2016 21:47:03 +0000 Subject: [docs] [issue26010] document CO_* constants Message-ID: <1451944023.51.0.951612152691.issue26010@psf.upfronthosting.co.za> New submission from Yury Selivanov: Hi David, This is a follow up to issue #26010. Please review the attached patch. I've skipped the CO_NESTED flag since it's no longer used, and CO_OPTIMIZED because I don't know too much about it. ---------- keywords: +patch Added file: http://bugs.python.org/file41500/Issue26010.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 16:56:24 2016 From: report at bugs.python.org (Georg Brandl) Date: Mon, 04 Jan 2016 21:56:24 +0000 Subject: [docs] [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451944584.47.0.140180960929.issue25813@psf.upfronthosting.co.za> Georg Brandl added the comment: > For the final time, *I* am the OP and not one of you could be bothered before so this remains closed. Are you quite all right? Continuing behavior of that sort will get your tracker account disabled. ---------- nosy: +georg.brandl status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 17:09:32 2016 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 04 Jan 2016 22:09:32 +0000 Subject: [docs] [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451945372.33.0.695434327136.issue25813@psf.upfronthosting.co.za> Mark Lawrence added the comment: It's all ready been superceeded, or haven't you woken up to that fact either? ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 17:26:45 2016 From: report at bugs.python.org (Georg Brandl) Date: Mon, 04 Jan 2016 22:26:45 +0000 Subject: [docs] [issue25813] co_flags section of inspect module docs out of date In-Reply-To: <1449353474.35.0.531055283092.issue25813@psf.upfronthosting.co.za> Message-ID: <1451946405.69.0.697166223435.issue25813@psf.upfronthosting.co.za> Georg Brandl added the comment: > It's all ready been superceeded, or haven't you woken up to that fact either? Excuse me for not having all issues in my head. (And that #26010 states that it's a followup to #26010 doesn't help.) In the future, please accept that the core developers are who decide about issues being closed or not. Submitters are only given privilege to close their own issues because it lightens the load on coredevs if issues become obsolete (and no, no answer in less than 30 days does not mean obsolete). As I already said, abusing that privilege will eventually get you banned - so much the sooner with your past history taken into account. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 18:32:19 2016 From: report at bugs.python.org (Karl Richter) Date: Mon, 04 Jan 2016 23:32:19 +0000 Subject: [docs] [issue26011] Document necesities for cmp argument of sorted Message-ID: <1451950339.23.0.203915233375.issue26011@psf.upfronthosting.co.za> New submission from Karl Richter: The docstring of `sorted` doesn't explain what can be passed to the `cmp` and `key` argument of `sorted`. ---------- assignee: docs at python components: Documentation messages: 257505 nosy: docs at python, krichter priority: normal severity: normal status: open title: Document necesities for cmp argument of sorted type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 20:55:09 2016 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 05 Jan 2016 01:55:09 +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: <1451958909.53.0.541229119253.issue22062@psf.upfronthosting.co.za> Guido van Rossum added the comment: Classifying as easy doc bug. ---------- assignee: -> docs at python components: +Documentation keywords: +easy nosy: +docs at python, gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 4 22:40:28 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 05 Jan 2016 03:40:28 +0000 Subject: [docs] [issue23677] Mention dict and set comps in library reference In-Reply-To: <1426495855.1.0.56894829498.issue23677@psf.upfronthosting.co.za> Message-ID: <1451965228.56.0.353746354698.issue23677@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Heck, with the addition of additional unpacking generalizations in 3.5, you can make an empty set even without a comprehension: {*()} Not really recommending the "one-eyed monkey operator", but the addition of unpacking generalizations undoes several of the limits on literals that previously existed. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 00:15:49 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 05 Jan 2016 05:15:49 +0000 Subject: [docs] [issue26011] Document necesities for cmp argument of sorted In-Reply-To: <1451950339.23.0.203915233375.issue26011@psf.upfronthosting.co.za> Message-ID: <1451970949.13.0.154622224116.issue26011@psf.upfronthosting.co.za> Josh Rosenberg added the comment: The docstring doesn't give details, but many docstrings don't. The docs themselves do; not sure it's a good idea to expand every docstring into complete documentation; if you don't know the function you read the real docs, the docstrings are useful as a reminder for stuff like argument order and names, higher logic, etc., without getting into details. cmp is almost certainly not going to be documented further in the docstrings; 2.7 is in bug fix only mode IIRC (and even then, mostly security fix only), and tweaking docstrings that aren't wrong, just less detailed than you might like isn't likely to meet the bar. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 07:54:21 2016 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 05 Jan 2016 12:54:21 +0000 Subject: [docs] [issue26010] document CO_* constants In-Reply-To: <1451944023.51.0.951612152691.issue26010@psf.upfronthosting.co.za> Message-ID: <1451998461.34.0.109447809704.issue26010@psf.upfronthosting.co.za> Yury Selivanov added the comment: > This is a follow up to issue #26010. The correct issue # is 25813 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 08:04:26 2016 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 05 Jan 2016 13:04:26 +0000 Subject: [docs] [issue26014] Guide users to the newer package install instructions Message-ID: <1451999065.99.0.467691766338.issue26014@psf.upfronthosting.co.za> New submission from Nick Coghlan: The up to date module installation docs are at: * https://docs.python.org/2/installing/index.html * https://docs.python.org/3/installing/index.html However, legacy deep links still resolve to the old docs: * https://docs.python.org/2/install/index.html * https://docs.python.org/3/install/index.html Those link out to packaging.python.org, the link is buried in a longish note, rather than being highlighted as a more obvious See Also link. The top level landing page in the Python 2.7 docs also still links to the legacy docs rather than the new ones, and the "(Legacy)" notation hasn't been appended to the headings on the legacy docs the way it has in 3.x. There's a few long hanging fruit for cleanup here: * add See Also links to the modern docs from the legacy docs * append the (Legacy) suffix in the 2.x docs * fix the 2.x top level docs page to link to the new docs rather than the legacy ones * link to the legacy docs from the distutils package docs in 2.7 (as has already been done in 3.x) ---------- assignee: docs at python components: Documentation messages: 257529 nosy: docs at python, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Guide users to the newer package install instructions type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 12:43:16 2016 From: report at bugs.python.org (Brett Cannon) Date: Tue, 05 Jan 2016 17:43:16 +0000 Subject: [docs] [issue26017] Update https://docs.python.org/3/installing/index.html to always quote arguments Message-ID: <1452015796.73.0.274069830205.issue26017@psf.upfronthosting.co.za> New submission from Brett Cannon: If you look at https://docs.python.org/3/installing/index.html it lists two commands: python -m pip install SomePackage==1.0.4 # specific version python -m pip install 'SomePackage>=1.0.4' # minimum version If you notice that beyond the change from `==` to `>=`, you will notice one quotes its argument while the other one doesn't. This is a UNIX shell thing due to what `>` means. But if you don't know how the UNIX shell works this could be easily overlooked. It would be best to simply quote both examples and avoid people messing up by leaving off the quotes. ---------- assignee: docs at python components: Documentation messages: 257536 nosy: alexis, brett.cannon, docs at python, dstufft, eric.araujo, lemburg, ncoghlan, paul.moore, tarek priority: normal severity: normal stage: needs patch status: open title: Update https://docs.python.org/3/installing/index.html to always quote arguments type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 12:55:43 2016 From: report at bugs.python.org (Zachary Ware) Date: Tue, 05 Jan 2016 17:55:43 +0000 Subject: [docs] [issue26017] Update https://docs.python.org/3/installing/index.html to always quote arguments In-Reply-To: <1452015796.73.0.274069830205.issue26017@psf.upfronthosting.co.za> Message-ID: <1452016543.62.0.287802425324.issue26017@psf.upfronthosting.co.za> Zachary Ware added the comment: I'd also suggest using double quotes ("); single quotes don't work on Windows. C:\>echo 'test>=test' C:\>dir /b test* test' C:\>type "test'" 'test ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 19:06:41 2016 From: report at bugs.python.org (Martin von Gagern) Date: Wed, 06 Jan 2016 00:06:41 +0000 Subject: [docs] [issue26018] documentation of ZipFile file name encoding Message-ID: <1452038801.7.0.594053315947.issue26018@psf.upfronthosting.co.za> New submission from Martin von Gagern: https://docs.python.org/3/library/zipfile.html#zipfile.ZipFile.write writes: ?Note: There is no official file name encoding for ZIP files. If you have unicode file names, you must convert them to byte strings in your desired encoding before passing them to write(). WinZip interprets all file names as encoded in CP437, also known as DOS Latin.? I think this is wrong in many ways. Firstly, APPNOTE.TXT used to explicitely define CP437 as the standard, and it's still the standard in the absence of general purpose bit 11 and a more specific description using the 0x0008 Extra Field. On the other hand, we do have that general purpose bit these days, so there are now not just one but two well-defined file name encodings. And thirdly, encoding the string to bytes as suggested will in fact lead to a run time error, since ZipInfo expects to do this conversion itself. See work towards issue1734346, starting at commit 8e33f316ce14, for details on when this was addressed in the source code. ---------- assignee: docs at python components: Documentation messages: 257567 nosy: docs at python, gagern priority: normal severity: normal status: open title: documentation of ZipFile file name encoding type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 19:12:06 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 06 Jan 2016 00:12:06 +0000 Subject: [docs] [issue25917] Fixing howto links in docs In-Reply-To: <1450610247.39.0.486318634402.issue25917@psf.upfronthosting.co.za> Message-ID: <1452039126.67.0.10131947083.issue25917@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 20:00:13 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 06 Jan 2016 01:00:13 +0000 Subject: [docs] [issue26018] documentation of ZipFile file name encoding In-Reply-To: <1452038801.7.0.594053315947.issue26018@psf.upfronthosting.co.za> Message-ID: <1452042013.24.0.983186616109.issue26018@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 20:19:20 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 01:19:20 +0000 Subject: [docs] [issue22558] Missing hint to source code - complete In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1452043159.59.0.19354709612.issue22558@psf.upfronthosting.co.za> Guido van Rossum added the comment: Actually uploading a patch for this should be easy, right? ---------- keywords: +easy nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 21:05:12 2016 From: report at bugs.python.org (Andrew Barnert) Date: Wed, 06 Jan 2016 02:05:12 +0000 Subject: [docs] [issue26019] collections.abc documentation incomplete Message-ID: <1452045912.74.0.509683701942.issue26019@psf.upfronthosting.co.za> New submission from Andrew Barnert: Some of the modules in collections.abc have a subclass hook that implicitly registers any type that declares the right methods, like Iterator. Others do not, like Sequence. For those that do have the hook, it's not always obvious what methods are tested. And some of them test the methods for truthiness, others only for existence (although #25958 will fix that last bit). The documentation doesn't even mention this, much less describe which ABCs are of which kind. For someone who just wants to know how to write isinstance(arg, Iterable), that's fine. But anyone who wants to create new classes, or integrate third-party classes that weren't ABC-friendly, has to read the collections.abc module source to figure out what they want to do. ---------- assignee: docs at python components: Documentation messages: 257577 nosy: abarnert, docs at python priority: normal severity: normal status: open title: collections.abc documentation incomplete type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 21:42:21 2016 From: report at bugs.python.org (Hamish Campbell) Date: Wed, 06 Jan 2016 02:42:21 +0000 Subject: [docs] [issue26020] set_display evaluation order doesn't match documented behaviour Message-ID: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> New submission from Hamish Campbell: It looks like the behaviour of set displays do not match behaviour in some cases. The documentation states: "A set display yields a new mutable set object, the contents being specified by either a sequence of expressions or a comprehension. When a comma-separated list of expressions is supplied, its elements are evaluated from left to right and added to the set object. When a comprehension is supplied, the set is constructed from the elements resulting from the comprehension." Note the following: >>> foo = { True, 1 } >>> print(foo) {1} However, if we add elements 'left to right': >>> foo = set() >>> foo.add(True) >>> foo.add(1) >>> print(foo) {True} Note that similar documentation for dict displays produces the expected result. "If a comma-separated sequence of key/datum pairs is given, they are evaluated from left to right to define the entries of the dictionary: each key object is used as a key into the dictionary to store the corresponding datum. This means that you can specify the same key multiple times in the key/datum list, and the final dictionary?s value for that key will be the last one given." >>> foo = {} >>> foo[True] = 'bar' >>> foo[1] = 'baz' >>> print(foo) {True: 'baz'} Which matches the dict display construction: >>> foo = { True: 'bar', 1: 'baz'} >>> print(foo) {True: 'baz'} Note that I've tagged this as a documentation bug, but it seems like the documentation might be the preferred implementation. ---------- assignee: docs at python components: Documentation messages: 257579 nosy: Hamish Campbell, docs at python priority: normal severity: normal status: open title: set_display evaluation order doesn't match documented behaviour versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 21:45:04 2016 From: report at bugs.python.org (Hamish Campbell) Date: Wed, 06 Jan 2016 02:45:04 +0000 Subject: [docs] [issue26020] set_display evaluation order doesn't match documented behaviour In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> Message-ID: <1452048304.01.0.370334889654.issue26020@psf.upfronthosting.co.za> Hamish Campbell added the comment: Apologies, that first line should read "It looks like the documentation of set displays do not match behaviour in some cases". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 21:50:22 2016 From: report at bugs.python.org (Andrew Barnert) Date: Wed, 06 Jan 2016 02:50:22 +0000 Subject: [docs] [issue26019] collections.abc documentation incomplete In-Reply-To: <1452045912.74.0.509683701942.issue26019@psf.upfronthosting.co.za> Message-ID: <1452048622.01.0.232307042196.issue26019@psf.upfronthosting.co.za> Andrew Barnert added the comment: The attached patch is, I think, the smallest change that includes all the necessary information. Of course it will need to be redone if #25958 goes through, with a version-changed note explaining that prior to 3.6 some of the implicit ABCs (maybe with a list) treated None as an abstract method implementation while others didn't. So, this patch is basically a throwaway. But any review comments would still be useful, of course. ---------- keywords: +patch Added file: http://bugs.python.org/file41513/patch26019.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 21:54:07 2016 From: report at bugs.python.org (Hamish Campbell) Date: Wed, 06 Jan 2016 02:54:07 +0000 Subject: [docs] [issue26020] set_display evaluation order doesn't match documented behaviour In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> Message-ID: <1452048847.64.0.13359194332.issue26020@psf.upfronthosting.co.za> Hamish Campbell added the comment: Note also the differences here: >>> print(set([True, 1])) {True} >>> print({True, 1}) {1} >>> print({x for x in [True, 1]}) {True} ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 22:18:49 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 06 Jan 2016 03:18:49 +0000 Subject: [docs] [issue22558] Missing hint to source code - complete In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1452050329.01.0.695957028018.issue22558@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Guido, should we take your comment as approving linking every source, as opposed to only some? This scope issue is the main sticking point for this issue. Otherwise, the standard patch is 3 easy new lines after the :synopsis: (and any 'New in Version x.y' note for the module -- see argparse). The following is Benjamin's patch for #22528. --- a/Doc/library/pdb.rst +++ b/Doc/library/pdb.rst @@ -6,6 +6,9 @@ .. module:: pdb :synopsis: The Python debugger for interactive interpreters. +**Source code:** :source:`Lib/pdb.py` + +-------------- .. index:: single: debugging Friedrich, were you planning to write a patch, once the list of modules is decided on? Or should we invite submissions on the core-mentorship list? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 22:40:53 2016 From: report at bugs.python.org (Emanuel Barry) Date: Wed, 06 Jan 2016 03:40:53 +0000 Subject: [docs] [issue26020] set_display evaluation order doesn't match documented behaviour In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> Message-ID: <1452051653.27.0.874198643731.issue26020@psf.upfronthosting.co.za> Emanuel Barry added the comment: Set displays appear to be the culprit here: >>> class A: ... count = 0 ... def __init__(self): ... self.cnt = self.count ... type(self).count += 1 ... def __eq__(self, other): ... return type(self) is type(other) ... def __hash__(self): ... return id(type(self)) ... >>> e={A(), A(), A(), A(), A()} >>> e {<__main__.A object at 0x002BB2B0>} >>> list(e)[0].cnt 4 >>> list(e)[0].count 5 >>> A.count = 0 >>> q=set([A(), A(), A(), A(), A()]) >>> q {<__main__.A object at 0x002BB310>} >>> list(q)[0].cnt 0 >>> list(q)[0].count 5 I'm guessing this is an optimization and/or set displays just don't keep ordering at definition time. Do you have a use case where `x == y`/`hash(x) == hash(y)` does not mean that `x` and `y` should be interchangeable? True and 1 are 100% interchangeable, minus their str() output, and my example is very unlikely to ever appear in actual code. Probably just better to fix the docs to specify that sets literals don't check ordering. ---------- nosy: +ebarry versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 5 23:35:22 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 06 Jan 2016 04:35:22 +0000 Subject: [docs] [issue26020] set_display evaluation order doesn't match documented behaviour In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> Message-ID: <1452054922.75.0.920029380642.issue26020@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The culprit is the BUILD_SET opcode in Python/ceval.c which unnecessarily loops backwards (it looks like it was copied from the BUILD_TUPLE opcode). ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 00:11:58 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 05:11:58 +0000 Subject: [docs] [issue22558] Missing hint to source code - complete In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1452057118.69.0.667059089543.issue22558@psf.upfronthosting.co.za> Guido van Rossum added the comment: It's fine to add a source link to any module for which there is Python source code. I suppose this adds a slight maintenance burden when a module moves (e.g. when a module is turned into a package, or when the subdirectory structure of the Lib directory changes). I'm a little confused about the "New in x.y" note -- why is that connected to the source code link? Of course, the source tells a different story from the docs -- e.g. undocumented implementation details may change, and sometimes the source is hard to understand (on occasion I've been confused myself :-). But Python is open source, so people can always read the source -- I don't see why we should try to make reading the source harder for people who don't yet have the chops to just read it on their own computer! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 00:43:39 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 06 Jan 2016 05:43:39 +0000 Subject: [docs] [issue26020] set_display evaluation order doesn't match documented behaviour In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> Message-ID: <1452059019.98.0.389551153265.issue26020@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- keywords: +patch Added file: http://bugs.python.org/file41514/build_set.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 03:46:13 2016 From: report at bugs.python.org (Hamish Campbell) Date: Wed, 06 Jan 2016 08:46:13 +0000 Subject: [docs] [issue26020] set_display evaluation order doesn't match documented behaviour In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> Message-ID: <1452069973.3.0.759929011441.issue26020@psf.upfronthosting.co.za> Hamish Campbell added the comment: > Do you have a use case where `x == y`/`hash(x) == hash(y)` does not mean that `x` and `y` should be interchangeable? True and 1 are 100% interchangeable, minus their str() output, and my example is very unlikely to ever appear in actual code. No I don't have a use case :) > The culprit is the BUILD_SET opcode in Python/ceval.c which unnecessarily loops backwards (it looks like it was copied from the BUILD_TUPLE opcode). Incidentally, pypy seems to behave the same as reported here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 06:54:27 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 06 Jan 2016 11:54:27 +0000 Subject: [docs] [issue18918] help('FILES') finds no documentation In-Reply-To: <1378269620.52.0.763555902483.issue18918@psf.upfronthosting.co.za> Message-ID: <20160106115423.8269.16703@psf.io> Roundup Robot added the comment: New changeset 0792a0ad7f22 by Senthil Kumaran in branch '2.7': Fix issue18918 : Attach the pydoc documentation for 'FILES' topic. https://hg.python.org/cpython/rev/0792a0ad7f22 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 06:57:41 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 06 Jan 2016 11:57:41 +0000 Subject: [docs] [issue18918] help('FILES') finds no documentation In-Reply-To: <1378269620.52.0.763555902483.issue18918@psf.upfronthosting.co.za> Message-ID: <1452081461.28.0.599831229635.issue18918@psf.upfronthosting.co.za> Senthil Kumaran added the comment: The bltin-file-objects was not referenced in pyspecific.py from which this data was generated. Added it and fixed it. Verified that it is available in 2.7 now. ---------- nosy: +orsenthil resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 07:05:24 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 06 Jan 2016 12:05:24 +0000 Subject: [docs] [issue22558] Missing hint to source code - complete In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1452081924.81.0.263051157453.issue22558@psf.upfronthosting.co.za> Terry J. Reedy added the comment: If there is a New-in note (which follows Synopsis), then (to be consistent) the Source note should follow it. If not (the normal situation), then Source follows Synopsis directly. A point in favor of linking all Python sources from the docs is that default single users installs are much harder to access on Windows than they used to be: /Users/Name/[Appdata - hidden by default]/Roaming?/Python/Pythonxy (I believe) versus the old /Pythonxy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 07:05:35 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 06 Jan 2016 12:05:35 +0000 Subject: [docs] [issue22558] Missing hint to source code - complete In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1452081935.81.0.716350616512.issue22558@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 11:19:53 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 06 Jan 2016 16:19:53 +0000 Subject: [docs] [issue26020] set_display evaluation order doesn't match documented behaviour In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> Message-ID: <1452097193.84.0.676829135005.issue26020@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file41518/build_set2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 11:20:06 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 06 Jan 2016 16:20:06 +0000 Subject: [docs] [issue26020] set_display evaluation order doesn't match documented behaviour In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> Message-ID: <1452097206.82.0.855514147211.issue26020@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 11:21:05 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 06 Jan 2016 16:21:05 +0000 Subject: [docs] [issue26020] set_display evaluation order doesn't match documented behaviour In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> Message-ID: <1452097265.96.0.761065635504.issue26020@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 12:39:34 2016 From: report at bugs.python.org (Brett Cannon) Date: Wed, 06 Jan 2016 17:39:34 +0000 Subject: [docs] [issue26025] Document pathlib.Path.__truediv__() Message-ID: <1452101974.47.0.473485918535.issue26025@psf.upfronthosting.co.za> New submission from Brett Cannon: I noticed that the documentation for pathlib only mentions the overloading of __truediv__ in examples and not anywhere in the actual docs for the Path object itself. ---------- assignee: docs at python components: Documentation messages: 257617 nosy: brett.cannon, docs at python, pitrou priority: normal severity: normal stage: needs patch status: open title: Document pathlib.Path.__truediv__() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 15:48:32 2016 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 06 Jan 2016 20:48:32 +0000 Subject: [docs] [issue26019] collections.abc documentation incomplete In-Reply-To: <1452045912.74.0.509683701942.issue26019@psf.upfronthosting.co.za> Message-ID: <1452113312.09.0.101071786083.issue26019@psf.upfronthosting.co.za> Guido van Rossum added the comment: LGTM. Do you want me to commit it now or wait until you've redone it after #25958 has gone through? ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 16:44:08 2016 From: report at bugs.python.org (Julien) Date: Wed, 06 Jan 2016 21:44:08 +0000 Subject: [docs] [issue26029] Broken sentence in extending documentation Message-ID: <1452116648.24.0.989848174126.issue26029@psf.upfronthosting.co.za> New submission from Julien: Hello, While translating the documentation to French, I found a bug here : https://docs.python.org/3/extending/building.html#building-c-and-c-extensions-with-distutils The sentence: "Normally, a package will contain of addition modules:" Should probably be: "Normally, a package will contain additional modules:" Bests. ---------- assignee: docs at python components: Documentation messages: 257645 nosy: docs at python, sizeof priority: normal severity: normal status: open title: Broken sentence in extending documentation type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 17:06:04 2016 From: report at bugs.python.org (Julien) Date: Wed, 06 Jan 2016 22:06:04 +0000 Subject: [docs] [issue26030] Use PEP8 in documentation examples Message-ID: <1452117964.46.0.438153899324.issue26030@psf.upfronthosting.co.za> New submission from Julien: Hi, Shouldn't Python use PEP8 in its examples in the documentation ? I found a lot of missing spaces around binary operators, and things like "setup (name = 'PackageName'," (found in the Distributing section, but that's just a single example) which hurt my eyes and will probably teach bad practices to newcomers reading it. If everybody agree documentation examples should be PEP8 compliant, I'll can gladly provide some patches. I also found http://bugs.python.org/issue23921 which is probably not merged as it's still open, and the patch don't fix my example, so there is probably some problems left. ---------- assignee: docs at python components: Documentation messages: 257649 nosy: docs at python, sizeof priority: normal severity: normal status: open title: Use PEP8 in documentation examples type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 18:39:46 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 06 Jan 2016 23:39:46 +0000 Subject: [docs] [issue26030] Use PEP8 in documentation examples In-Reply-To: <1452117964.46.0.438153899324.issue26030@psf.upfronthosting.co.za> Message-ID: <1452123586.52.0.39256569891.issue26030@psf.upfronthosting.co.za> Martin Panter added the comment: In general I agree with fixing style problems in the documentation, especially if you supply patches :) ---------- nosy: +martin.panter stage: -> needs patch _______________________________________ Python tracker _______________________________________ From vadmium+py at gmail.com Wed Jan 6 20:41:26 2016 From: vadmium+py at gmail.com (vadmium+py at gmail.com) Date: Thu, 07 Jan 2016 01:41:26 -0000 Subject: [docs] Standardize documentation whitespace, formatting (issue 23921) Message-ID: <20160107014126.16741.74170@psf.upfronthosting.co.za> http://bugs.python.org/review/23921/diff/14579/Doc/faq/library.rst File Doc/faq/library.rst (right): http://bugs.python.org/review/23921/diff/14579/Doc/faq/library.rst#newcode747 Doc/faq/library.rst:747: Could probably drop this new blank line http://bugs.python.org/review/23921/diff/14579/Doc/faq/programming.rst File Doc/faq/programming.rst (right): http://bugs.python.org/review/23921/diff/14579/Doc/faq/programming.rst#newcode668 Doc/faq/programming.rst:668: >>> print(b) Why not add prompts to the lines above as well? http://bugs.python.org/review/23921/diff/14579/Doc/library/abc.rst File Doc/library/abc.rst (right): http://bugs.python.org/review/23921/diff/14579/Doc/library/abc.rst#newcode92 Doc/library/abc.rst:92: FWIW I think the existing compact form is fine. The methods don?t have any substance, so separating them doesn?t buy much. But if you want to make the style consistent with MyIterable, you need a blank line above __getitem__() as well. http://bugs.python.org/review/23921/diff/14579/Doc/whatsnew/3.2.rst File Doc/whatsnew/3.2.rst (left): http://bugs.python.org/review/23921/diff/14579/Doc/whatsnew/3.2.rst#oldcode502 Doc/whatsnew/3.2.rst:502: You could keep the blank line here to mirror the interactive interpreter better http://bugs.python.org/review/23921/diff/14579/Doc/whatsnew/3.2.rst File Doc/whatsnew/3.2.rst (right): http://bugs.python.org/review/23921/diff/14579/Doc/whatsnew/3.2.rst#newcode1107 Doc/whatsnew/3.2.rst:1107: ... b'G3805 storeroom Main chassis ' Why not a four-space indent? http://bugs.python.org/review/23921/diff/14579/Doc/whatsnew/3.2.rst#newcode1555 Doc/whatsnew/3.2.rst:1555: ... name = 'xz', I think you could drop the space around the equal signs and make it name='xz', etc. http://bugs.python.org/review/23921/diff/14579/Doc/whatsnew/3.2.rst#newcode1882 Doc/whatsnew/3.2.rst:1882: Add an extra ellipsis to imitate the interpreter better http://bugs.python.org/review/23921/ From report at bugs.python.org Wed Jan 6 20:44:45 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 07 Jan 2016 01:44:45 +0000 Subject: [docs] [issue23921] Standardize documentation whitespace, formatting In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za> Message-ID: <1452131085.83.0.644204275974.issue23921@psf.upfronthosting.co.za> Martin Panter added the comment: I do prefer extra space before a comment, otherwise it looks too much like some kind of ?x # y? binary operator. So I think those changes are worthwhile. I left some review comments, mainly minor suggestions. Most of the other changes look worthwhile. Others I don?t mind either way, but I can understand others may prefer them, such as lining up hanging indents for fixed-width fonts. David: did you end up looking this? Are there any particular bits you think are not worth it? ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 23:12:49 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 07 Jan 2016 04:12:49 +0000 Subject: [docs] [issue23921] Standardize documentation whitespace, formatting In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za> Message-ID: <1452139969.41.0.612396023767.issue23921@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: -r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 23:13:58 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 07 Jan 2016 04:13:58 +0000 Subject: [docs] [issue23921] Standardize documentation whitespace, formatting In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za> Message-ID: <1452140038.3.0.907172497845.issue23921@psf.upfronthosting.co.za> R. David Murray added the comment: Sorry, I'm not going to have time to look at it. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 23:14:17 2016 From: report at bugs.python.org (R. David Murray) Date: Thu, 07 Jan 2016 04:14:17 +0000 Subject: [docs] [issue23921] Standardize documentation whitespace, formatting In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za> Message-ID: <1452140057.42.0.691958399282.issue23921@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: -r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 23:38:52 2016 From: report at bugs.python.org (Dan Sadowski) Date: Thu, 07 Jan 2016 04:38:52 +0000 Subject: [docs] [issue26034] venv documentation out of date Message-ID: <1452141532.31.0.700374014076.issue26034@psf.upfronthosting.co.za> New submission from Dan Sadowski: The listing for the --clear option in the documentation is outdated. This is from the actual current 3.5 usage text: --clear Delete the contents of the environment directory if it already exists, before environment creation. ---------- assignee: docs at python components: Documentation messages: 257669 nosy: docs at python, dsadowski priority: normal severity: normal status: open title: venv documentation out of date versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 6 23:47:35 2016 From: report at bugs.python.org (Nicholas Chammas) Date: Thu, 07 Jan 2016 04:47:35 +0000 Subject: [docs] [issue26035] traceback.print_tb() takes `tb`, not `traceback` as a keyword argument Message-ID: <1452142055.04.0.968906484949.issue26035@psf.upfronthosting.co.za> New submission from Nicholas Chammas: Here is traceback.print_tb()'s signature [0]: ``` def print_tb(tb, limit=None, file=None): ``` However, its documentation reads [1]: ``` .. function:: print_tb(traceback, limit=None, file=None) ``` Did the keyword argument change recently, or was this particular doc always wrong? [0] https://github.com/python/cpython/blob/1fe0fd9feb6a4472a9a1b186502eb9c0b2366326/Lib/traceback.py#L43 [1] https://raw.githubusercontent.com/python/cpython/1fe0fd9feb6a4472a9a1b186502eb9c0b2366326/Doc/library/traceback.rst ---------- assignee: docs at python components: Documentation messages: 257670 nosy: Nicholas Chammas, docs at python priority: normal severity: normal status: open title: traceback.print_tb() takes `tb`, not `traceback` as a keyword argument versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 00:31:20 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 07 Jan 2016 05:31:20 +0000 Subject: [docs] [issue16544] Add external link to ast docs In-Reply-To: <1353702032.57.0.687396127567.issue16544@psf.upfronthosting.co.za> Message-ID: <20160107053117.53718.70317@psf.io> Roundup Robot added the comment: New changeset 94b0e5e9b6e8 by Senthil Kumaran in branch '3.4': Issue16544 - Add a link to an external documentation resource in ast module docs. https://hg.python.org/cpython/rev/94b0e5e9b6e8 New changeset ebf164b07be1 by Senthil Kumaran in branch '3.5': merge from 3.4 https://hg.python.org/cpython/rev/ebf164b07be1 New changeset 62e88e5a61c0 by Senthil Kumaran in branch 'default': merge from 3.5 https://hg.python.org/cpython/rev/62e88e5a61c0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 00:34:32 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 07 Jan 2016 05:34:32 +0000 Subject: [docs] [issue16544] Add external link to ast docs In-Reply-To: <1353702032.57.0.687396127567.issue16544@psf.upfronthosting.co.za> Message-ID: <1452144872.82.0.180623190016.issue16544@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Thanks for patch and the work on Green Tree Snakes, Thomas. It is a great resource. I agree that a lot could be included directly in stdlib docs, but till then, as suggested/recommended by Andrew and Ezio, a see also link is a good addition. ---------- assignee: ezio.melotti -> orsenthil nosy: +orsenthil resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 01:13:07 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 07 Jan 2016 06:13:07 +0000 Subject: [docs] [issue26035] traceback.print_tb() takes `tb`, not `traceback` as a keyword argument In-Reply-To: <1452142055.04.0.968906484949.issue26035@psf.upfronthosting.co.za> Message-ID: <1452147187.52.0.126779238402.issue26035@psf.upfronthosting.co.za> Martin Panter added the comment: According to the history, the parameter was always called ?tb? in the implementation , and the documentation always had it wrong . So I would change the documentation to ?tb?. It looks like other functions in this module have the wrong parameter names also. ---------- nosy: +martin.panter stage: -> needs patch versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 01:46:45 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 07 Jan 2016 06:46:45 +0000 Subject: [docs] [issue26030] Use PEP8 in documentation examples In-Reply-To: <1452117964.46.0.438153899324.issue26030@psf.upfronthosting.co.za> Message-ID: <1452149205.45.0.505007263481.issue26030@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > I found a lot of missing spaces around binary operators Please don't make trivial changes like this. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 02:06:16 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 07 Jan 2016 07:06:16 +0000 Subject: [docs] [issue26030] Use PEP8 in documentation examples In-Reply-To: <1452117964.46.0.438153899324.issue26030@psf.upfronthosting.co.za> Message-ID: <1452150376.46.0.526119132911.issue26030@psf.upfronthosting.co.za> Martin Panter added the comment: If it is fixing stuff like ?lambda x: x +1? (from Issue 23921), I am in favour. But if the code example is self-consistent and uses a reasonable style, it should not be changed. Julien, perhaps you should give an example to clarify. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 02:16:09 2016 From: report at bugs.python.org (INADA Naoki) Date: Thu, 07 Jan 2016 07:16:09 +0000 Subject: [docs] [issue26030] Use PEP8 in documentation examples In-Reply-To: <1452117964.46.0.438153899324.issue26030@psf.upfronthosting.co.za> Message-ID: <1452150969.03.0.744594774887.issue26030@psf.upfronthosting.co.za> INADA Naoki added the comment: No spaces around binary operator is OK in PEP8. See http://bugs.python.org/issue11425 ---------- nosy: +naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 03:45:29 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 07 Jan 2016 08:45:29 +0000 Subject: [docs] [issue26035] traceback.print_tb() takes `tb`, not `traceback` as a keyword argument In-Reply-To: <1452142055.04.0.968906484949.issue26035@psf.upfronthosting.co.za> Message-ID: <1452156329.58.0.718243047039.issue26035@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 06:01:17 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 07 Jan 2016 11:01:17 +0000 Subject: [docs] [issue22088] base64 module still ignores non-alphabet characters In-Reply-To: <1406414649.83.0.15731376973.issue22088@psf.upfronthosting.co.za> Message-ID: <1452164477.24.0.659258438229.issue22088@psf.upfronthosting.co.za> Martin Panter added the comment: This new patch applies to Python 3. As well as the above changes, I updated the doc strings based on the changes in 92760d2edc9e (Issue 1753718, Issue 20782), mainly clarifying the data types functions accept and return. Further fixes: * In Python 3, b16decode() raises binascii.Error, not TypeError * The base-85 functions? data parameter is called ?b?, not ?s? ---------- Added file: http://bugs.python.org/file41522/base64-discard.py3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 08:54:35 2016 From: report at bugs.python.org (Upendra Kumar) Date: Thu, 07 Jan 2016 13:54:35 +0000 Subject: [docs] [issue26029] Broken sentence in extending documentation In-Reply-To: <1452116648.24.0.989848174126.issue26029@psf.upfronthosting.co.za> Message-ID: <1452174875.88.0.92316971675.issue26029@psf.upfronthosting.co.za> Upendra Kumar added the comment: I am submitting the patch with small change suggested by you. Thank you. ---------- keywords: +patch nosy: +upendra-k14 Added file: http://bugs.python.org/file41524/building_additional.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 09:02:39 2016 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 07 Jan 2016 14:02:39 +0000 Subject: [docs] [issue26029] Broken sentence in extending documentation In-Reply-To: <1452116648.24.0.989848174126.issue26029@psf.upfronthosting.co.za> Message-ID: <1452175359.17.0.0259538671346.issue26029@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> patch review versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 09:09:53 2016 From: report at bugs.python.org (Neil Girdhar) Date: Thu, 07 Jan 2016 14:09:53 +0000 Subject: [docs] [issue26020] set_display evaluation order doesn't match documented behaviour In-Reply-To: <1452048141.82.0.22346371212.issue26020@psf.upfronthosting.co.za> Message-ID: <1452175793.36.0.0820627945414.issue26020@psf.upfronthosting.co.za> Neil Girdhar added the comment: If BUIlD_SET is going to be changed, it would probably be could to keep BUILD_SET_UNPACK consistent. ---------- nosy: +neil.g _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 11:46:00 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 07 Jan 2016 16:46:00 +0000 Subject: [docs] [issue5501] Update multiprocessing docs re: freeze_support In-Reply-To: <1237312904.73.0.910184118935.issue5501@psf.upfronthosting.co.za> Message-ID: <20160107164553.30364.52721@psf.io> Roundup Robot added the comment: New changeset f08d4712a055 by Berker Peksag in branch '3.5': Issue #5501: Clarify that invoking freeze_support() on non-Windows platforms has no effect https://hg.python.org/cpython/rev/f08d4712a055 New changeset 2902f32d1ae9 by Berker Peksag in branch 'default': Issue #5501: Clarify that invoking freeze_support() on non-Windows platforms has no effect https://hg.python.org/cpython/rev/2902f32d1ae9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 11:50:04 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 07 Jan 2016 16:50:04 +0000 Subject: [docs] [issue5501] Update multiprocessing docs re: freeze_support In-Reply-To: <1237312904.73.0.910184118935.issue5501@psf.upfronthosting.co.za> Message-ID: <20160107164956.69599.91479@psf.io> Roundup Robot added the comment: New changeset 8b20a606ecde by Berker Peksag in branch '2.7': Issue #5501: Clarify that invoking freeze_support() on non-Windows platforms has no effect https://hg.python.org/cpython/rev/8b20a606ecde ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 11:54:59 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 07 Jan 2016 16:54:59 +0000 Subject: [docs] [issue5501] Update multiprocessing docs re: freeze_support In-Reply-To: <1237312904.73.0.910184118935.issue5501@psf.upfronthosting.co.za> Message-ID: <1452185699.51.0.623518456984.issue5501@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks Davin and Camilla. ---------- nosy: +berker.peksag resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 19:46:20 2016 From: report at bugs.python.org (David Sterry) Date: Fri, 08 Jan 2016 00:46:20 +0000 Subject: [docs] [issue26046] Typo Message-ID: <1452213980.49.0.122824663371.issue26046@psf.upfronthosting.co.za> New submission from David Sterry: In https://docs.python.org/2/library/unittest.html#basic-example the word "details" should be "detail". ---------- assignee: docs at python components: Documentation messages: 257731 nosy: David Sterry, docs at python priority: normal severity: normal status: open title: Typo type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 19:46:28 2016 From: report at bugs.python.org (Andrew Barnert) Date: Fri, 08 Jan 2016 00:46:28 +0000 Subject: [docs] [issue26019] collections.abc documentation incomplete In-Reply-To: <1452045912.74.0.509683701942.issue26019@psf.upfronthosting.co.za> Message-ID: <1452213988.74.0.543296332085.issue26019@psf.upfronthosting.co.za> Andrew Barnert added the comment: Probably better to wait. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 7 20:15:52 2016 From: report at bugs.python.org (Emanuel Barry) Date: Fri, 08 Jan 2016 01:15:52 +0000 Subject: [docs] [issue26046] Typo in documentation of unittest In-Reply-To: <1452213980.49.0.122824663371.issue26046@psf.upfronthosting.co.za> Message-ID: <1452215739.58.0.351633191108.issue26046@psf.upfronthosting.co.za> Emanuel Barry added the comment: Think you can submit a patch? ---------- keywords: +easy nosy: +ebarry stage: -> needs patch title: Typo -> Typo in documentation of unittest _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 00:57:41 2016 From: report at bugs.python.org (Upendra Kumar) Date: Fri, 08 Jan 2016 05:57:41 +0000 Subject: [docs] [issue26046] Typo in documentation of unittest In-Reply-To: <1452213980.49.0.122824663371.issue26046@psf.upfronthosting.co.za> Message-ID: <1452232661.65.0.168872217685.issue26046@psf.upfronthosting.co.za> Upendra Kumar added the comment: I have submitted the patch for this small typo. ---------- keywords: +patch nosy: +upendra-k14 Added file: http://bugs.python.org/file41528/typo.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 01:02:30 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 08 Jan 2016 06:02:30 +0000 Subject: [docs] [issue26046] Typo in documentation of unittest In-Reply-To: <1452213980.49.0.122824663371.issue26046@psf.upfronthosting.co.za> Message-ID: <20160108060223.69623.13132@psf.io> Roundup Robot added the comment: New changeset ff3655d6c257 by Benjamin Peterson in branch '2.7': fix typo in unittest docs (closes #26046) https://hg.python.org/cpython/rev/ff3655d6c257 New changeset f24d22b44099 by Benjamin Peterson in branch '3.4': fix typo in unittest docs (closes #26046) https://hg.python.org/cpython/rev/f24d22b44099 New changeset 21567b4493c6 by Benjamin Peterson in branch '3.5': merge 3.4 (#26046) https://hg.python.org/cpython/rev/21567b4493c6 New changeset eeec6c5b5b79 by Benjamin Peterson in branch 'default': merge 3.5 (#26046) https://hg.python.org/cpython/rev/eeec6c5b5b79 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 02:47:30 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 08 Jan 2016 07:47:30 +0000 Subject: [docs] [issue26017] Update https://docs.python.org/3/installing/index.html to always quote arguments In-Reply-To: <1452015796.73.0.274069830205.issue26017@psf.upfronthosting.co.za> Message-ID: <1452239250.69.0.954169369909.issue26017@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Here is the patch with the changes suggested by Brett. Having created this patch, I had second thoughts on this change. Folks who use pip often, usually use it without any quotes, like `pip install requests`, `pip install CherryPy`. Pinned down versions are most often required by projects and they mention it in the requirements.txt in an unquoted manner Ref: https://pip.readthedocs.org/en/1.1/requirements.html It works fine as it is not the shell which is parsing this file. Since ">" thing parsed by shell on the command line is a special thing, why not address that scenario with more clarification, instead of quoting all the examples, which seem contrary to the common usage patterns? ---------- keywords: +patch nosy: +orsenthil Added file: http://bugs.python.org/file41529/Issue26017.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 03:12:54 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 08 Jan 2016 08:12:54 +0000 Subject: [docs] [issue23675] glossary entry for 'method resolution order' links to something with python 2.3 in the title In-Reply-To: <1426456234.82.0.0903487839974.issue23675@psf.upfronthosting.co.za> Message-ID: <1452240773.96.0.738629767639.issue23675@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Here is the patch with the suggested wording. ---------- keywords: +patch nosy: +orsenthil Added file: http://bugs.python.org/file41530/Issue23675.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 03:13:08 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 08 Jan 2016 08:13:08 +0000 Subject: [docs] [issue23675] glossary entry for 'method resolution order' links to something with python 2.3 in the title In-Reply-To: <1426456234.82.0.0903487839974.issue23675@psf.upfronthosting.co.za> Message-ID: <1452240788.06.0.506257466733.issue23675@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 04:03:24 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 08 Jan 2016 09:03:24 +0000 Subject: [docs] [issue20969] Author of EPUB version of Python docs is set to Unknown instead of PSF In-Reply-To: <1395153249.12.0.327856107433.issue20969@psf.upfronthosting.co.za> Message-ID: <20160108090319.30362.95000@psf.io> Roundup Robot added the comment: New changeset 7fe960f1a101 by Senthil Kumaran in branch '3.5': Issue20969 - Set the Epub Author and Epub Publisher in Python docs. https://hg.python.org/cpython/rev/7fe960f1a101 New changeset 4daffae06f64 by Senthil Kumaran in branch 'default': merge from 3.5 https://hg.python.org/cpython/rev/4daffae06f64 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 04:06:05 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 08 Jan 2016 09:06:05 +0000 Subject: [docs] [issue20969] Author of EPUB version of Python docs is set to Unknown instead of PSF In-Reply-To: <1395153249.12.0.327856107433.issue20969@psf.upfronthosting.co.za> Message-ID: <20160108090602.8281.67688@psf.io> Roundup Robot added the comment: New changeset 6b72b4b79aef by Senthil Kumaran in branch '2.7': Issue20969 - Set the Epub Author and Epub Publisher in Python docs. https://hg.python.org/cpython/rev/6b72b4b79aef ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 04:06:58 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 08 Jan 2016 09:06:58 +0000 Subject: [docs] [issue20969] Author of EPUB version of Python docs is set to Unknown instead of PSF In-Reply-To: <1395153249.12.0.327856107433.issue20969@psf.upfronthosting.co.za> Message-ID: <1452244018.36.0.666368540387.issue20969@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Fixed in all branches for which documentation will be published / updated. ---------- assignee: docs at python -> orsenthil nosy: +orsenthil resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 04:18:18 2016 From: report at bugs.python.org (Christof Hanke) Date: Fri, 08 Jan 2016 09:18:18 +0000 Subject: [docs] [issue26047] argparse.ArgumentError documentation wrong Message-ID: <1452244698.45.0.106083471244.issue26047@psf.upfronthosting.co.za> New submission from Christof Hanke: On https://docs.python.org/2/library/argparse.html (and on those of the 3.6-Version) it says at the bottom: """ ArgumentParser.error(message) This method prints a usage message including the message to the standard error and terminates the program with a status code of 2. """ In fact, the returned staus code is 1. ---------- assignee: docs at python components: Documentation messages: 257745 nosy: Christof Hanke, docs at python priority: normal severity: normal status: open title: argparse.ArgumentError documentation wrong type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 04:22:31 2016 From: report at bugs.python.org (SilentGhost) Date: Fri, 08 Jan 2016 09:22:31 +0000 Subject: [docs] [issue26047] argparse.ArgumentError documentation wrong In-Reply-To: <1452244698.45.0.106083471244.issue26047@psf.upfronthosting.co.za> Message-ID: <1452244951.54.0.780429322584.issue26047@psf.upfronthosting.co.za> SilentGhost added the comment: Christof, you'd have to demonstrate the issue in more than just words. The returned status code is hard-coded to be 2 in the error method and it does end up being 2 when i run, could you post some output that led you to believe that it is 1? ---------- nosy: +SilentGhost resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 04:58:06 2016 From: report at bugs.python.org (Upendra Kumar) Date: Fri, 08 Jan 2016 09:58:06 +0000 Subject: [docs] [issue26035] traceback.print_tb() takes `tb`, not `traceback` as a keyword argument In-Reply-To: <1452142055.04.0.968906484949.issue26035@psf.upfronthosting.co.za> Message-ID: <1452247086.49.0.163978655484.issue26035@psf.upfronthosting.co.za> Upendra Kumar added the comment: I am submitting a patch for this documentation issue. I have changed the function parameters name 'traceback' to 'tb'. Because of this I have also introduced changes in the text of the documentation to maintain coherency. I found some more inconsistent function parameter's name: I have changed them : 'type' to 'etype' in functions print_exception, format_exception_only, format_exception 'list' to 'extracted_list' in function format_list ' ---------- keywords: +patch nosy: +upendra-k14 Added file: http://bugs.python.org/file41531/func_args_name.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 09:53:31 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 08 Jan 2016 14:53:31 +0000 Subject: [docs] [issue23675] glossary entry for 'method resolution order' links to something with python 2.3 in the title In-Reply-To: <1426456234.82.0.0903487839974.issue23675@psf.upfronthosting.co.za> Message-ID: <1452264811.81.0.00100800258744.issue23675@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: -r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 12:16:47 2016 From: report at bugs.python.org (Kartikaya Gupta) Date: Fri, 08 Jan 2016 17:16:47 +0000 Subject: [docs] [issue24712] Docs page's sidebar vibrates on mouse wheel scroll on Chrome. In-Reply-To: <1437780127.19.0.0270083299372.issue24712@psf.upfronthosting.co.za> Message-ID: <1452273406.9.0.786226593727.issue24712@psf.upfronthosting.co.za> Kartikaya Gupta added the comment: Please note that this issue will affect Firefox 46 and up as well; we have enabled asynchronous scrolling as of Firefox 46. Bugzilla bug for this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=997269 Announcement for asynchronous scrolling: https://groups.google.com/d/msg/mozilla.dev.platform/X2BwGm348jI/Tl26C_1JBAAJ Also, in Firefox 46 and up, if you open the browser's web console and scroll these documentation pages, you should see a warning about scroll-linked effects with pointers to additional info on why this is happening. ---------- nosy: +kats _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 12:18:44 2016 From: report at bugs.python.org (R. David Murray) Date: Fri, 08 Jan 2016 17:18:44 +0000 Subject: [docs] [issue24712] Docs page's sidebar vibrates on mouse wheel scroll on Chrome. In-Reply-To: <1437780127.19.0.0270083299372.issue24712@psf.upfronthosting.co.za> Message-ID: <1452273524.54.0.971909319354.issue24712@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: -r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 12:34:27 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 08 Jan 2016 17:34:27 +0000 Subject: [docs] [issue26030] Use PEP8 in documentation examples In-Reply-To: <1452117964.46.0.438153899324.issue26030@psf.upfronthosting.co.za> Message-ID: <1452274467.81.0.257580373775.issue26030@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 12:35:36 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 08 Jan 2016 17:35:36 +0000 Subject: [docs] [issue26025] Document pathlib.Path.__truediv__() In-Reply-To: <1452101974.47.0.473485918535.issue26025@psf.upfronthosting.co.za> Message-ID: <1452274536.55.0.961134570804.issue26025@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +ezio.melotti type: -> enhancement versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 12:41:36 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 08 Jan 2016 17:41:36 +0000 Subject: [docs] [issue26017] Update https://docs.python.org/3/installing/index.html to always quote arguments In-Reply-To: <1452015796.73.0.274069830205.issue26017@psf.upfronthosting.co.za> Message-ID: <1452274896.35.0.624453005773.issue26017@psf.upfronthosting.co.za> Ezio Melotti added the comment: I think it's enough to add a note that says that if the argument contains > (and possibly other) special characters, then it needs to be quoted. Examples that use > should also be quoted, but not the others one. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 12:48:34 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 08 Jan 2016 17:48:34 +0000 Subject: [docs] [issue26001] Tutorial: write() does not expect string in binary mode In-Reply-To: <1451829375.45.0.0188699168911.issue26001@psf.upfronthosting.co.za> Message-ID: <1452275314.45.0.159522964469.issue26001@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> patch review type: -> enhancement versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 12:50:19 2016 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 08 Jan 2016 17:50:19 +0000 Subject: [docs] [issue25991] readline example eventually consumes all memory In-Reply-To: <1451708933.83.0.797303528676.issue25991@psf.upfronthosting.co.za> Message-ID: <1452275419.34.0.37400213977.issue25991@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +ezio.melotti stage: -> needs patch type: resource usage -> enhancement versions: +Python 2.7, Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 13:11:10 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 08 Jan 2016 18:11:10 +0000 Subject: [docs] [issue26001] Tutorial: write() does not expect string in binary mode In-Reply-To: <1451829375.45.0.0188699168911.issue26001@psf.upfronthosting.co.za> Message-ID: <1452276670.45.0.840672819312.issue26001@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Lines should be kept to about 80 chars. Both chunks needs a newline added. I think it okay to create short lines rather than re-wrapping the whole paragraph. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 16:03:51 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 08 Jan 2016 21:03:51 +0000 Subject: [docs] [issue25991] readline example eventually consumes all memory In-Reply-To: <1451708933.83.0.797303528676.issue25991@psf.upfronthosting.co.za> Message-ID: <1452287031.83.0.377386654602.issue25991@psf.upfronthosting.co.za> Martin Panter added the comment: What version of Readline are you using? Is it perhaps Editline (libedit)? When I experimented with Editline on Linux once, I think I saw the history file doubling in size every time I ran Python. Maybe that is what you are seeing. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 16:12:49 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 08 Jan 2016 21:12:49 +0000 Subject: [docs] [issue23675] glossary entry for 'method resolution order' links to something with python 2.3 in the title In-Reply-To: <1426456234.82.0.0903487839974.issue23675@psf.upfronthosting.co.za> Message-ID: <1452287569.08.0.893780322147.issue23675@psf.upfronthosting.co.za> Martin Panter added the comment: The wording looks good in spirit. I just have a couple nits to pick with the grammar: * Why change from ?See? to ?Refer?? ?Refer to? would work better I think; but ?See? was fine too IMO. * I think it is better without ?document?. Just ?See / Refer to <2.3 MRO> for details?. * I would insert ?the? in ?since the 2.3 release?. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 18:21:49 2016 From: report at bugs.python.org (Antony Lee) Date: Fri, 08 Jan 2016 23:21:49 +0000 Subject: [docs] [issue26051] Non-data descriptors in pydoc Message-ID: <1452295309.05.0.476253695659.issue26051@psf.upfronthosting.co.za> New submission from Antony Lee: Consider the following minimal example: class readonlyprop: __init__ = lambda self, func: None __get__ = lambda self, inst, cls=None: None class C: def bar(self): pass @readonlyprop def foo(self): pass def quux(self): pass the output of `pydoc modname.C` is <... cropped ...> modname.C = class C(builtins.object) | Methods defined here: | | bar(self) | | foo = None | quux(self) | | ---------------------------------------------------------------------- | Data descriptors defined here: <... cropped ...> It would be nice if 1. a newline was added after `foo = None`, and 2. foo was *also* marked as being a non-data-descriptor of class readonlyprop (basically what you'd get without invoking the __get__). ---------- assignee: docs at python components: Documentation messages: 257782 nosy: Antony.Lee, docs at python priority: normal severity: normal status: open title: Non-data descriptors in pydoc versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 18:24:46 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 08 Jan 2016 23:24:46 +0000 Subject: [docs] [issue26025] Document pathlib.Path.__truediv__() In-Reply-To: <1452101974.47.0.473485918535.issue26025@psf.upfronthosting.co.za> Message-ID: <1452295486.05.0.58271342022.issue26025@psf.upfronthosting.co.za> Brett Cannon added the comment: Turns out it is if you read the PurePath docs: https://docs.python.org/3/library/pathlib.html#operators ---------- resolution: -> not a bug stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 18:30:08 2016 From: report at bugs.python.org (Antony Lee) Date: Fri, 08 Jan 2016 23:30:08 +0000 Subject: [docs] [issue26052] pydoc for __init__ with not docstring Message-ID: <1452295807.98.0.613500169742.issue26052@psf.upfronthosting.co.za> New submission from Antony Lee: For a class whose __init__ has no docstring, e.g. class C: def __init__(self, arg): pass pydoc outputs <... cropped ...> class C(builtins.object) | Methods defined here: | | __init__(self, arg) | Initialize self. See help(type(self)) for accurate signature. <... cropped ...> The last part "See help(type(self)) for accurate signature." could arguably be cropped as the correct signature is already displayed (I see that this is the docstring of object.__init__, it's not clear to me why it needs this sentence.). ---------- assignee: docs at python components: Documentation messages: 257784 nosy: Antony.Lee, docs at python priority: normal severity: normal status: open title: pydoc for __init__ with not docstring versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 21:06:10 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 09 Jan 2016 02:06:10 +0000 Subject: [docs] [issue26052] pydoc for __init__ with not docstring In-Reply-To: <1452295807.98.0.613500169742.issue26052@psf.upfronthosting.co.za> Message-ID: <1452305170.24.0.447655213894.issue26052@psf.upfronthosting.co.za> Martin Panter added the comment: I suspect this the same side effect of 3.5?s doc string inheritance that I mentioned in Issue 15582. The solution proposed was basically ?write a custom doc string?, though I?m not sure that is always appropriate. ---------- keywords: +3.5regression nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 23:38:16 2016 From: report at bugs.python.org (YoungBoy) Date: Sat, 09 Jan 2016 04:38:16 +0000 Subject: [docs] [issue26055] sys.argv[0] is the python file, not "" Message-ID: <1452314296.6.0.563314730517.issue26055@psf.upfronthosting.co.za> New submission from YoungBoy: python tutorial 2.1.1 You can access this list by executing import sys. The length of the list is at least one; when no script and no arguments are given, sys.argv[0] is an empty string. but, when i try it, the sys.argv[0]is the filename,not empty string. ---------- assignee: docs at python components: Documentation messages: 257795 nosy: Wei, docs at python priority: normal severity: normal status: open title: sys.argv[0] is the python file, not "" versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 23:46:58 2016 From: report at bugs.python.org (random832) Date: Sat, 09 Jan 2016 04:46:58 +0000 Subject: [docs] [issue26055] sys.argv[0] is the python file, not "" In-Reply-To: <1452314296.6.0.563314730517.issue26055@psf.upfronthosting.co.za> Message-ID: <1452314818.81.0.906674360563.issue26055@psf.upfronthosting.co.za> random832 added the comment: By "when no script [is] given", it is referring to the use in the interactive interpreter, not in a python file. ---------- nosy: +random832 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 8 23:53:00 2016 From: report at bugs.python.org (YoungBoy) Date: Sat, 09 Jan 2016 04:53:00 +0000 Subject: [docs] [issue26055] sys.argv[0] is the python file, not "" In-Reply-To: <1452314296.6.0.563314730517.issue26055@psf.upfronthosting.co.za> Message-ID: <1452315180.03.0.95927451777.issue26055@psf.upfronthosting.co.za> Changes by YoungBoy : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 03:19:23 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 09 Jan 2016 08:19:23 +0000 Subject: [docs] [issue26029] Broken sentence in extending documentation In-Reply-To: <1452116648.24.0.989848174126.issue26029@psf.upfronthosting.co.za> Message-ID: <1452327563.89.0.588795596917.issue26029@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: docs at python -> terry.reedy nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 03:28:20 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 09 Jan 2016 08:28:20 +0000 Subject: [docs] [issue26029] Broken sentence in extending documentation In-Reply-To: <1452116648.24.0.989848174126.issue26029@psf.upfronthosting.co.za> Message-ID: <20160109082816.69155.27647@psf.io> Roundup Robot added the comment: New changeset 3b860ce5bb51 by Terry Jan Reedy in branch '3.5': Issue #26029: Remove extraneous word. Patch by Upendra Kumar. https://hg.python.org/cpython/rev/3b860ce5bb51 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 03:28:57 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 09 Jan 2016 08:28:57 +0000 Subject: [docs] [issue26029] Broken sentence in extending documentation In-Reply-To: <1452116648.24.0.989848174126.issue26029@psf.upfronthosting.co.za> Message-ID: <1452328137.1.0.423829367638.issue26029@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thanks for reporting. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 03:37:49 2016 From: report at bugs.python.org (Zachary Ware) Date: Sat, 09 Jan 2016 08:37:49 +0000 Subject: [docs] [issue26029] Broken sentence in extending documentation In-Reply-To: <1452116648.24.0.989848174126.issue26029@psf.upfronthosting.co.za> Message-ID: <1452328669.92.0.223222013108.issue26029@psf.upfronthosting.co.za> Zachary Ware added the comment: Terry, it doesn't look like you used Upendra's patch. What you committed just removes the "of", but doesn't change "addition" to "additional", which is also required to make that sentence make sense. ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 04:47:48 2016 From: report at bugs.python.org (Daniel Dye) Date: Sat, 09 Jan 2016 09:47:48 +0000 Subject: [docs] [issue25991] readline example eventually consumes all memory In-Reply-To: <1451708933.83.0.797303528676.issue25991@psf.upfronthosting.co.za> Message-ID: <1452332868.16.0.385849971521.issue25991@psf.upfronthosting.co.za> Daniel Dye added the comment: Add a history length of 1000 lines Default is -1 (infinite), which may grow unruly ---------- keywords: +patch nosy: +Daniel Dye Added file: http://bugs.python.org/file41544/doc_library_readline.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 07:29:18 2016 From: report at bugs.python.org (Manvi B) Date: Sat, 09 Jan 2016 12:29:18 +0000 Subject: [docs] [issue24918] Docs layout bug In-Reply-To: <1440361207.71.0.0873906255469.issue24918@psf.upfronthosting.co.za> Message-ID: <1452342558.2.0.21397885143.issue24918@psf.upfronthosting.co.za> Manvi B added the comment: Fixed by using "display:inline" in ".highlight" class. ---------- keywords: +patch nosy: +Manvi B Added file: http://bugs.python.org/file41548/issue24918.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 07:37:03 2016 From: report at bugs.python.org (Manvi B) Date: Sat, 09 Jan 2016 12:37:03 +0000 Subject: [docs] [issue24918] Docs layout bug In-Reply-To: <1440361207.71.0.0873906255469.issue24918@psf.upfronthosting.co.za> Message-ID: <1452343023.57.0.57229526947.issue24918@psf.upfronthosting.co.za> Manvi B added the comment: Fixed by using "background: none" in ".highlight" class. ---------- Added file: http://bugs.python.org/file41549/issue24918.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 07:46:38 2016 From: report at bugs.python.org (Manvi B) Date: Sat, 09 Jan 2016 12:46:38 +0000 Subject: [docs] [issue24918] Docs layout bug In-Reply-To: <1440361207.71.0.0873906255469.issue24918@psf.upfronthosting.co.za> Message-ID: <1452343598.16.0.547727794277.issue24918@psf.upfronthosting.co.za> Manvi B added the comment: Both solutions msg257821, msg257822 seems to fix the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 08:15:01 2016 From: report at bugs.python.org (Elena Oat) Date: Sat, 09 Jan 2016 13:15:01 +0000 Subject: [docs] [issue25574] 2.7 incorrectly documents objects hash as equal to id In-Reply-To: <1446849305.52.0.678156368856.issue25574@psf.upfronthosting.co.za> Message-ID: <1452345301.36.0.0583331016045.issue25574@psf.upfronthosting.co.za> Elena Oat added the comment: Updated the documentation. Now it says that the hash is derived from id, as it says already in Python 3 docs. ---------- nosy: +Elena.Oat Added file: http://bugs.python.org/file41552/issue25574.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 08:29:56 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 09 Jan 2016 13:29:56 +0000 Subject: [docs] [issue18911] minidom does not encode correctly when calling Document.writexml In-Reply-To: <1378186619.58.0.930376227557.issue18911@psf.upfronthosting.co.za> Message-ID: <1452346196.03.0.730217622485.issue18911@psf.upfronthosting.co.za> Ezio Melotti added the comment: > On Python 3 you should not only open file in text mode with specified > encoding, but also specify the "xmlcharrefreplace" error handler. Isn't this only required in case there are non encodable characters? If the encoding is utf-8, this shouldn't be necessary (unless there are lone surrogates). Specifying xmlcharrefreplace might be useful while using ascii or latin1 though. The docs of writexml don't seem to specify if the file should be opened in text or binary mode but istm that only text mode is supported. The advice of using xmlcharrefreplace could be added in a note. ---------- nosy: +ezio.melotti versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 08:50:38 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 09 Jan 2016 13:50:38 +0000 Subject: [docs] [issue25730] invisible sidebar content with code snippets In-Reply-To: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za> Message-ID: <1452347438.08.0.35452844508.issue25730@psf.upfronthosting.co.za> Ezio Melotti added the comment: This is a duplicate of #24918, which also has a couple of patches that seem to fix the problem. ---------- superseder: -> Docs layout bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 08:51:22 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 09 Jan 2016 13:51:22 +0000 Subject: [docs] [issue25730] invisible sidebar content with code snippets In-Reply-To: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za> Message-ID: <1452347482.74.0.880229878305.issue25730@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- resolution: -> duplicate stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 09:09:38 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 09 Jan 2016 14:09:38 +0000 Subject: [docs] [issue24789] ctypes doc string In-Reply-To: <1438719738.53.0.780685651956.issue24789@psf.upfronthosting.co.za> Message-ID: <20160109140935.21392.52876@psf.io> Roundup Robot added the comment: New changeset 1753a28acad4 by Ezio Melotti in branch '3.5': #24789: fix docstring of ctypes.create_string_buffer. Patch by Matheus Vieira Portela. https://hg.python.org/cpython/rev/1753a28acad4 New changeset 57964ca3ce0f by Ezio Melotti in branch 'default': #24789: merge with 3.5. https://hg.python.org/cpython/rev/57964ca3ce0f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 09:11:29 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 09 Jan 2016 14:11:29 +0000 Subject: [docs] [issue24789] ctypes doc string In-Reply-To: <1438719738.53.0.780685651956.issue24789@psf.upfronthosting.co.za> Message-ID: <1452348689.19.0.0779829950388.issue24789@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- nosy: +ezio.melotti resolution: -> fixed stage: needs patch -> resolved status: open -> closed versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 09:31:56 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 09 Jan 2016 14:31:56 +0000 Subject: [docs] [issue24786] Changes in the devguide repository are not published online in HTML In-Reply-To: <1438640887.59.0.275627512221.issue24786@psf.upfronthosting.co.za> Message-ID: <1452349916.66.0.0750568417836.issue24786@psf.upfronthosting.co.za> Ezio Melotti added the comment: This seem to be already fixed, however the copyright needs to be updated again (see #26063). ---------- nosy: +ezio.melotti resolution: -> out of date stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 09:38:20 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 09 Jan 2016 14:38:20 +0000 Subject: [docs] [issue26030] Use PEP8 in documentation examples In-Reply-To: <1452117964.46.0.438153899324.issue26030@psf.upfronthosting.co.za> Message-ID: <1452350300.55.0.416472909076.issue26030@psf.upfronthosting.co.za> Ezio Melotti added the comment: Without a list of places that don't follow the PEP8, I'm going to close this. ---------- resolution: -> not a bug status: open -> pending _______________________________________ Python tracker _______________________________________ From fawlty.coder at outlook.com Tue Jan 5 04:43:24 2016 From: fawlty.coder at outlook.com (Paul Dunnington) Date: Tue, 5 Jan 2016 09:43:24 +0000 Subject: [docs] debugging the pydoc/py module Message-ID: I have been trying to learn the language since April and after debugging the pydoc/py module I have been making progress. I am using Python 2-4-1 on Risc OS but have seen the same bugs in Raspbian and Windows. As I don't have internet access I have also altered the HTML docs that I downloaded from http://web.archive.org/web/20071223061900/http://python.acorn.de/Python-2.4-additions-2005-09-30.zip to integrate better with your HTML docs for Python 2/4/1 that I have downloaded from http://www.python.org/ftp/python/doc/2.4.1/html-2.4.1.zip I have changed the files /lib/modindex.html, index.html and modindex.html and added the directory riscos with the six altered Risc OS HTML files now with the os.extsep + 'html' extension. On Risc OS you can drag the new directory over the old directory and it will over-write the three /html files and write the riscos directory and its contents for you, I can't say what will happen on other platforms. I have added the help for the isopen() function I have added in the riscospath module because the os.fstat() function is not defined in the riscos module and st_ino = 0 for every file in Risc OS anyway I beleive so samefile() and sameopenfile() returned true for every file. I modified samefile() and sameopenfile() to return the correct result according to my tests. I have attached a zipped directory containing my pydoc/py, a text file with error line numbers for the pydoc/py files I have had access to and a directory containing my html doc changes. I hope this is of some use. Paul Dunnington fawlty.coder at outlook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pydoc.zip Type: application/zip Size: 81937 bytes Desc: not available URL: From techtonik at gmail.com Tue Jan 5 03:56:59 2016 From: techtonik at gmail.com (anatoly techtonik) Date: Tue, 5 Jan 2016 11:56:59 +0300 Subject: [docs] typo In-Reply-To: References: Message-ID: On Fri, Jan 1, 2016 at 9:25 PM, Zachary Ware wrote: > On Wed, Dec 30, 2015 at 12:59 AM, anatoly techtonik wrote: >> https://docs.python.org/2/library/ctypes.html#loading-shared-libraries >> >> - There are several ways to loaded shared libraries into the Python process. >> + There are several ways to load shared libraries into the Python process. > > Fixed, thanks for the report! No problem. Nice to see that docs@ is alive and kickin' =) -- anatoly t. From report at bugs.python.org Sat Jan 9 09:58:57 2016 From: report at bugs.python.org (Elena Oat) Date: Sat, 09 Jan 2016 14:58:57 +0000 Subject: [docs] [issue26001] Tutorial: write() does not expect string in binary mode In-Reply-To: <1451829375.45.0.0188699168911.issue26001@psf.upfronthosting.co.za> Message-ID: <1452351536.98.0.587783669489.issue26001@psf.upfronthosting.co.za> Elena Oat added the comment: Wrapped the lines to 80 chars. ---------- nosy: +Elena.Oat Added file: http://bugs.python.org/file41556/issue26001.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 11:02:58 2016 From: report at bugs.python.org (Julien) Date: Sat, 09 Jan 2016 16:02:58 +0000 Subject: [docs] [issue26030] Use PEP8 in documentation examples In-Reply-To: <1452117964.46.0.438153899324.issue26030@psf.upfronthosting.co.za> Message-ID: <1452355378.62.0.746354031634.issue26030@psf.upfronthosting.co.za> Julien added the comment: I opened this ticket mainly to know the opinions on those modifications, I'll slowly review what I see, and provide little patches from time to time, only when the PEP8 infringement look obvious. I think the most obvious PEP8 infringement ARE to be fixed, typically in the tutorial: The documentation is where people learn, let's teach them the right thing to do :-) Thanks to naoki I just learnt that no spaces around binary operators are OK when it enhance the readability (https://www.python.org/dev/peps/pep-0008/#other-recommendations) like 2*2 + 3*2. I close this ticket, I'll just mention if I propose a patch in a new one. Bests. ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 12:22:30 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 09 Jan 2016 17:22:30 +0000 Subject: [docs] [issue26029] Broken sentence in extending documentation In-Reply-To: <1452116648.24.0.989848174126.issue26029@psf.upfronthosting.co.za> Message-ID: <20160109172228.21382.67606@psf.io> Roundup Robot added the comment: New changeset 3f9b9244488d by Terry Jan Reedy in branch '3.5': Issue #26029: Finish correction. https://hg.python.org/cpython/rev/3f9b9244488d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 15:19:22 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 09 Jan 2016 20:19:22 +0000 Subject: [docs] [issue18911] minidom does not encode correctly when calling Document.writexml In-Reply-To: <1378186619.58.0.930376227557.issue18911@psf.upfronthosting.co.za> Message-ID: <1452370762.41.0.50608520995.issue18911@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: -r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 15:20:05 2016 From: report at bugs.python.org (R. David Murray) Date: Sat, 09 Jan 2016 20:20:05 +0000 Subject: [docs] [issue25730] invisible sidebar content with code snippets In-Reply-To: <1448448461.72.0.524937822108.issue25730@psf.upfronthosting.co.za> Message-ID: <1452370805.13.0.274306829393.issue25730@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: -r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 15:41:56 2016 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 09 Jan 2016 20:41:56 +0000 Subject: [docs] [issue26066] Language on the "Cryptographic Services" is out of date Message-ID: <1452372116.19.0.623367169611.issue26066@psf.upfronthosting.co.za> New submission from Alex Gaynor: https://docs.python.org/2/library/crypto.html https://docs.python.org/3/library/crypto.html This language has a number of issues: - Crypto isn't just for "Hardcore cypherpunks" anymore, it's a necessary component of a great many software projects - PyCrypto isn't maintained by A.M. Kuchling any longer - (IMO) it's no longer the recommended library for cryptography in Python - The page should probably also point people towards the ssl module. ---------- assignee: docs at python components: Documentation messages: 257857 nosy: alex, docs at python priority: normal severity: normal status: open title: Language on the "Cryptographic Services" is out of date versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 15:42:04 2016 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 09 Jan 2016 20:42:04 +0000 Subject: [docs] [issue26066] Language on the "Cryptographic Services" documentation page is out of date In-Reply-To: <1452372116.19.0.623367169611.issue26066@psf.upfronthosting.co.za> Message-ID: <1452372124.03.0.191102528358.issue26066@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- title: Language on the "Cryptographic Services" is out of date -> Language on the "Cryptographic Services" documentation page is out of date _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 16:28:30 2016 From: report at bugs.python.org (Krista Paasonen) Date: Sat, 09 Jan 2016 21:28:30 +0000 Subject: [docs] [issue24823] ctypes.create_string_buffer does not add NUL if len(init) == size In-Reply-To: <1438942688.18.0.266077254276.issue24823@psf.upfronthosting.co.za> Message-ID: <1452374910.28.0.234707091134.issue24823@psf.upfronthosting.co.za> Krista Paasonen added the comment: Patch containing checking for buffer size, so that NULL value is the last byte as C standard specifies. Raises ValueError exception if initial value does not fit into to the buffer with NULL char. This should decrease the possibility of creating security issues. ---------- keywords: +patch nosy: +krista Added file: http://bugs.python.org/file41558/create_string_buffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 17:05:10 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 09 Jan 2016 22:05:10 +0000 Subject: [docs] [issue26030] Use PEP8 in documentation examples In-Reply-To: <1452117964.46.0.438153899324.issue26030@psf.upfronthosting.co.za> Message-ID: <1452377110.0.0.651581935617.issue26030@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 18:55:18 2016 From: report at bugs.python.org (Eryk Sun) Date: Sat, 09 Jan 2016 23:55:18 +0000 Subject: [docs] [issue24823] ctypes.create_string_buffer does not add NUL if len(init) == size In-Reply-To: <1438942688.18.0.266077254276.issue24823@psf.upfronthosting.co.za> Message-ID: <1452383718.53.0.00963215008562.issue24823@psf.upfronthosting.co.za> Eryk Sun added the comment: I didn't want to change the function in lieu of breaking someone's code. If this change is accepted, then it at least needs a documentation note to indicate the new behavior. ---------- versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 9 18:56:47 2016 From: report at bugs.python.org (Eryk Sun) Date: Sat, 09 Jan 2016 23:56:47 +0000 Subject: [docs] [issue24823] ctypes.create_string_buffer does not add NUL if len(init) == size In-Reply-To: <1438942688.18.0.266077254276.issue24823@psf.upfronthosting.co.za> Message-ID: <1452383807.34.0.932202432001.issue24823@psf.upfronthosting.co.za> Changes by Eryk Sun : ---------- components: +Documentation, Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 01:30:56 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 10 Jan 2016 06:30:56 +0000 Subject: [docs] [issue23675] glossary entry for 'method resolution order' links to something with python 2.3 in the title In-Reply-To: <1426456234.82.0.0903487839974.issue23675@psf.upfronthosting.co.za> Message-ID: <1452407456.59.0.405577221599.issue23675@psf.upfronthosting.co.za> Senthil Kumaran added the comment: @Martin, thanks for the review comments. I've addressed this is version 2 of the patch. I am submitting this change. ---------- versions: +Python 2.7, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41563/Issue23675-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 01:34:55 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 10 Jan 2016 06:34:55 +0000 Subject: [docs] [issue23675] glossary entry for 'method resolution order' links to something with python 2.3 in the title In-Reply-To: <1426456234.82.0.0903487839974.issue23675@psf.upfronthosting.co.za> Message-ID: <20160110063451.47395.13108@psf.io> Roundup Robot added the comment: New changeset 9ba001cb107b by Senthil Kumaran in branch '3.5': Issue23675 - A tiny clarification in the MRO glossary term. https://hg.python.org/cpython/rev/9ba001cb107b New changeset 60d4c3a29201 by Senthil Kumaran in branch 'default': merge from 3.5 https://hg.python.org/cpython/rev/60d4c3a29201 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 01:36:20 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 10 Jan 2016 06:36:20 +0000 Subject: [docs] [issue23675] glossary entry for 'method resolution order' links to something with python 2.3 in the title In-Reply-To: <1426456234.82.0.0903487839974.issue23675@psf.upfronthosting.co.za> Message-ID: <20160110063618.27386.59050@psf.io> Roundup Robot added the comment: New changeset 99f5276e4197 by Senthil Kumaran in branch '2.7': Issue23675 - A tiny clarification in the MRO glossary term. https://hg.python.org/cpython/rev/99f5276e4197 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 01:37:15 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 10 Jan 2016 06:37:15 +0000 Subject: [docs] [issue23675] glossary entry for 'method resolution order' links to something with python 2.3 in the title In-Reply-To: <1426456234.82.0.0903487839974.issue23675@psf.upfronthosting.co.za> Message-ID: <1452407835.22.0.162749708433.issue23675@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Fixed in the active documentation branches 2.7,3.5 and 3.6. ---------- assignee: docs at python -> orsenthil resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 02:56:52 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 10 Jan 2016 07:56:52 +0000 Subject: [docs] [issue26066] Language on the "Cryptographic Services" documentation page is out of date In-Reply-To: <1452372116.19.0.623367169611.issue26066@psf.upfronthosting.co.za> Message-ID: <20160110075649.1023.68472@psf.io> Roundup Robot added the comment: New changeset 84fdbdd483a3 by Benjamin Peterson in branch '2.7': delete old crypto prose (closes #26066) https://hg.python.org/cpython/rev/84fdbdd483a3 New changeset d8944e059c7f by Benjamin Peterson in branch '3.4': delete old crypto prose (closes #26066) https://hg.python.org/cpython/rev/d8944e059c7f New changeset cc9ffb4829e7 by Benjamin Peterson in branch '3.5': merge 3.4 (#26066) https://hg.python.org/cpython/rev/cc9ffb4829e7 New changeset 8ee02ec9b634 by Benjamin Peterson in branch 'default': merge 3.5 (#26066) https://hg.python.org/cpython/rev/8ee02ec9b634 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From ghost.adh at gmail.com Sat Jan 9 10:15:44 2016 From: ghost.adh at gmail.com (ghost.adh at gmail.com) Date: Sat, 09 Jan 2016 15:15:44 -0000 Subject: [docs] Tutorial: write() does not expect string in binary mode (issue 26001) Message-ID: <20160109151544.31933.7154@psf.upfronthosting.co.za> https://bugs.python.org/review/26001/diff/16317/Doc/tutorial/inputoutput.rst File Doc/tutorial/inputoutput.rst (right): https://bugs.python.org/review/26001/diff/16317/Doc/tutorial/inputoutput.rst#newcode277 Doc/tutorial/inputoutput.rst:277: file is twice as large as your machine's memory. Otherwise, at most *size* bytes Double space needed before the start of new sentence. https://bugs.python.org/review/26001/ From ghost.adh at gmail.com Sat Jan 9 16:42:14 2016 From: ghost.adh at gmail.com (ghost.adh at gmail.com) Date: Sat, 09 Jan 2016 21:42:14 -0000 Subject: [docs] Tutorial: write() does not expect string in binary mode (issue 26001) Message-ID: <20160109214214.28043.89791@psf.upfronthosting.co.za> On 2016/01/09 22:31:45, vadmium wrote: > https://bugs.python.org/review/26001/diff/16317/Doc/tutorial/inputoutput.rst > File Doc/tutorial/inputoutput.rst (right): > > https://bugs.python.org/review/26001/diff/16317/Doc/tutorial/inputoutput.rst#newcode277 > Doc/tutorial/inputoutput.rst:277: file is twice as large as your machine's > memory. Otherwise, at most *size* bytes > On 2016/01/09 16:15:44, SilentGhost wrote: > > Double space needed before the start of new sentence. > > The single space was already there. Perhaps if you didn?t rewrap so many lines, > this would be more obvious :) It was obvious to me, I just thought that since re-wrapping is done, this might be fixed as well. https://bugs.python.org/review/26001/ From vadmium+py at gmail.com Sat Jan 9 16:31:45 2016 From: vadmium+py at gmail.com (vadmium+py at gmail.com) Date: Sat, 09 Jan 2016 21:31:45 -0000 Subject: [docs] Tutorial: write() does not expect string in binary mode (issue 26001) Message-ID: <20160109213145.28043.11325@psf.upfronthosting.co.za> https://bugs.python.org/review/26001/diff/16317/Doc/tutorial/inputoutput.rst File Doc/tutorial/inputoutput.rst (right): https://bugs.python.org/review/26001/diff/16317/Doc/tutorial/inputoutput.rst#newcode277 Doc/tutorial/inputoutput.rst:277: file is twice as large as your machine's memory. Otherwise, at most *size* bytes On 2016/01/09 16:15:44, SilentGhost wrote: > Double space needed before the start of new sentence. The single space was already there. Perhaps if you didn?t rewrap so many lines, this would be more obvious :) https://bugs.python.org/review/26001/ From report at bugs.python.org Sun Jan 10 07:09:29 2016 From: report at bugs.python.org (Elena Oat) Date: Sun, 10 Jan 2016 12:09:29 +0000 Subject: [docs] [issue25517] regex howto example in "Lookahead Assertions" In-Reply-To: <1446199646.71.0.249231376897.issue25517@psf.upfronthosting.co.za> Message-ID: <1452427769.21.0.670722674932.issue25517@psf.upfronthosting.co.za> Elena Oat added the comment: Corrected the regular expression and documented why [^.]* is used. ---------- keywords: +patch nosy: +Elena.Oat Added file: http://bugs.python.org/file41566/issue25517.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 10:59:00 2016 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 10 Jan 2016 15:59:00 +0000 Subject: [docs] [issue26030] Use PEP8 in documentation examples In-Reply-To: <1452117964.46.0.438153899324.issue26030@psf.upfronthosting.co.za> Message-ID: <1452441540.39.0.063115032176.issue26030@psf.upfronthosting.co.za> Ezio Melotti added the comment: > I'll slowly review what I see, and provide little patches from > time to time, only when the PEP8 infringement look obvious. Sounds good to me. If you are not sure you can ask on IRC (#python-dev on freenode) or the core-mentorship mailing list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 15:32:54 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 10 Jan 2016 20:32:54 +0000 Subject: [docs] [issue8810] TZ offset description is unclear in docs In-Reply-To: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za> Message-ID: <1452457974.11.0.538541996095.issue8810@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 15:33:05 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 10 Jan 2016 20:33:05 +0000 Subject: [docs] [issue9305] Don't use east/west of UTC in date/time documentation In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za> Message-ID: <1452457985.47.0.417936568436.issue9305@psf.upfronthosting.co.za> Martin Panter added the comment: Assuming you meant Issue 8810, yes these patches would collide with each other. I am yet to look at the patches, but I gess they should be merged. ---------- dependencies: +TZ offset description is unclear in docs -Don't use east/west of UTC in date/time documentation nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 15:35:59 2016 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Sun, 10 Jan 2016 20:35:59 +0000 Subject: [docs] [issue8810] TZ offset description is unclear in docs In-Reply-To: <1452457974.08.0.80360037037.issue8810@psf.upfronthosting.co.za> Message-ID: <20160110203556.GC28792@sg1> St?phane Wirtel added the comment: Hi Martin, Which patch? Thanks -- St?phane Wirtel - http://wirtel.be - @matrixise ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 10 16:31:03 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 10 Jan 2016 21:31:03 +0000 Subject: [docs] [issue1753718] base64 "legacy" functions violate RFC 3548 Message-ID: <1452461463.14.0.856811174016.issue1753718@psf.upfronthosting.co.za> Martin Panter added the comment: Uploaded a Python 3 patch to Issue 22088 which includes the doc string changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:09:29 2016 From: report at bugs.python.org (W. Trevor King) Date: Mon, 11 Jan 2016 17:09:29 +0000 Subject: [docs] [issue26080] "abandonned" -> "abandoned" in PEP 510's https://hg.python.org/peps/rev/b463c740990c Message-ID: <1452532169.85.0.59348007279.issue26080@psf.upfronthosting.co.za> New submission from W. Trevor King: In the recently-landed [1], There was also the Unladen Swallow project, but it was abandonned in 2011. Should have used ?abandoned? instead of ?abandonned?. [1]: https://hg.python.org/peps/rev/b463c740990c changeset: 6155:b463c740990c user: Victor Stinner gmail.com> date: Sun Jan 10 14:58:17 2016 +0100 summary: PEP 510: rationale for static optimize vs JIT compiler http://permalink.gmane.org/gmane.comp.python.cvs/114604 ---------- assignee: docs at python components: Documentation messages: 257974 nosy: docs at python, labrat priority: normal severity: normal status: open title: "abandonned" -> "abandoned" in PEP 510's https://hg.python.org/peps/rev/b463c740990c type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:11:03 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Jan 2016 17:11:03 +0000 Subject: [docs] [issue26080] "abandonned" -> "abandoned" in PEP 510's https://hg.python.org/peps/rev/b463c740990c In-Reply-To: <1452532169.85.0.59348007279.issue26080@psf.upfronthosting.co.za> Message-ID: <20160111171057.70893.82579@psf.io> Roundup Robot added the comment: New changeset 63151533cebf by Victor Stinner in branch 'default': PEP 510: abandonned => abandoned https://hg.python.org/peps/rev/63151533cebf ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 12:11:33 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Jan 2016 17:11:33 +0000 Subject: [docs] [issue26080] "abandonned" -> "abandoned" in PEP 510's https://hg.python.org/peps/rev/b463c740990c In-Reply-To: <1452532169.85.0.59348007279.issue26080@psf.upfronthosting.co.za> Message-ID: <1452532293.56.0.882109419313.issue26080@psf.upfronthosting.co.za> STINNER Victor added the comment: Fixed, thanks for the report. ---------- nosy: +haypo resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 15:41:40 2016 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 11 Jan 2016 20:41:40 +0000 Subject: [docs] [issue22167] iglob() has misleading documentation (does indeed store names internally) In-Reply-To: <1407460141.27.0.298063472331.issue22167@psf.upfronthosting.co.za> Message-ID: <1452544900.13.0.322440135756.issue22167@psf.upfronthosting.co.za> Guido van Rossum added the comment: Once http://bugs.python.org/issue25596 (switching glob to use scandir) is solved this issue can be closed IMO. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 16:31:51 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Jan 2016 21:31:51 +0000 Subject: [docs] [issue25991] readline example eventually consumes all memory In-Reply-To: <1451708933.83.0.797303528676.issue25991@psf.upfronthosting.co.za> Message-ID: <20160111213148.31083.81616@psf.io> Roundup Robot added the comment: New changeset 9a2c891a4333 by Ezio Melotti in branch '2.7': #25991: fix readline example to limit history size. Patch by Daniel Dye. https://hg.python.org/cpython/rev/9a2c891a4333 New changeset 416db1a2fb81 by Ezio Melotti in branch '3.5': #25991: fix readline example to limit history size. Patch by Daniel Dye. https://hg.python.org/cpython/rev/416db1a2fb81 New changeset cb08e5271cc0 by Ezio Melotti in branch 'default': #25991: merge with 3.5. https://hg.python.org/cpython/rev/cb08e5271cc0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 16:32:45 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 11 Jan 2016 21:32:45 +0000 Subject: [docs] [issue25991] readline example eventually consumes all memory In-Reply-To: <1451708933.83.0.797303528676.issue25991@psf.upfronthosting.co.za> Message-ID: <1452547965.68.0.627583498228.issue25991@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 11 16:36:37 2016 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 11 Jan 2016 21:36:37 +0000 Subject: [docs] [issue24918] Docs layout bug In-Reply-To: <1440361207.71.0.0873906255469.issue24918@psf.upfronthosting.co.za> Message-ID: <1452548197.34.0.0711503045168.issue24918@psf.upfronthosting.co.za> Ezio Melotti added the comment: Georg, do you have any opinion on this? AFAIK all the div.highlight contain a 
 with the actual code and it's own background color, so using background: none; should be fine.

----------
nosy: +georg.brandl
stage: needs patch -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 17:11:42 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Jan 2016 22:11:42 +0000
Subject: [docs] [issue25517] regex howto example in "Lookahead Assertions"
In-Reply-To: <1446199646.71.0.249231376897.issue25517@psf.upfronthosting.co.za>
Message-ID: <20160111221138.27362.76081@psf.io>


Roundup Robot added the comment:

New changeset c6b5c03183e3 by Ezio Melotti in branch '2.7':
#25517: fix regex in the regex howto.  Patch by Elena Oat.
https://hg.python.org/cpython/rev/c6b5c03183e3

New changeset 6bd4a4907f66 by Ezio Melotti in branch '3.5':
#25517: fix regex in the regex howto.  Patch by Elena Oat.
https://hg.python.org/cpython/rev/6bd4a4907f66

New changeset 48e2f5915d49 by Ezio Melotti in branch 'default':
#25517: merge with 3.5.
https://hg.python.org/cpython/rev/48e2f5915d49

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 17:12:26 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 11 Jan 2016 22:12:26 +0000
Subject: [docs] [issue25517] regex howto example in "Lookahead Assertions"
In-Reply-To: <1446199646.71.0.249231376897.issue25517@psf.upfronthosting.co.za>
Message-ID: <1452550346.24.0.0713983984687.issue25517@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 20:54:47 2016
From: report at bugs.python.org (Mike Taylor)
Date: Tue, 12 Jan 2016 01:54:47 +0000
Subject: [docs] [issue24712] Docs page's sidebar vibrates on mouse wheel
 scroll on Chrome.
In-Reply-To: <1437780127.19.0.0270083299372.issue24712@psf.upfronthosting.co.za>
Message-ID: <1452563687.0.0.500185844243.issue24712@psf.upfronthosting.co.za>


Mike Taylor added the comment:

I can reproduce on Chrome and Firefox Nightly --

Carol, if I'd like to write a patch where would I do that? I see https://github.com/python/pythondotorg, but am not sure that's the right repo. Thanks!

----------
nosy: +Mike Taylor

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 21:02:18 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 12 Jan 2016 02:02:18 +0000
Subject: [docs] [issue25991] readline example eventually consumes all memory
In-Reply-To: <1451708933.83.0.797303528676.issue25991@psf.upfronthosting.co.za>
Message-ID: <1452564138.02.0.513565147849.issue25991@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks Ezio for handling this. Ignore my previous comment; I missed the key word ?example? :)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 11 23:14:32 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Tue, 12 Jan 2016 04:14:32 +0000
Subject: [docs] [issue26087] PEP 0373 should be updated
Message-ID: <1452572071.97.0.659652590609.issue26087@psf.upfronthosting.co.za>


New submission from Chi Hsuan Yen:

Current PEP 0373 lists Python 2.7.11 as a future release, and there's no information about Python 2.7.12. Please update it, thanks!

----------
assignee: docs at python
components: Documentation
messages: 258063
nosy: Chi Hsuan Yen, docs at python
priority: normal
severity: normal
status: open
title: PEP 0373 should be updated
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 03:47:34 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2016 08:47:34 +0000
Subject: [docs] [issue24712] Docs page's sidebar vibrates on mouse wheel
 scroll on Chrome.
In-Reply-To: <1437780127.19.0.0270083299372.issue24712@psf.upfronthosting.co.za>
Message-ID: <1452588454.51.0.447460140289.issue24712@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

CSS: Doc/tools/pydoctheme/static/pydoctheme.css
JS: Doc/tools/static/sidebar.js

The repo is https://hg.python.org/cpython/, but there should be a github mirror too.  See also the devguide for more info.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 03:55:43 2016
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 12 Jan 2016 08:55:43 +0000
Subject: [docs] [issue26087] PEP 0373 should be updated
In-Reply-To: <1452572071.97.0.659652590609.issue26087@psf.upfronthosting.co.za>
Message-ID: <1452588943.34.0.043088705639.issue26087@psf.upfronthosting.co.za>


Changes by Georg Brandl :


----------
assignee: docs at python -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 03:56:15 2016
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 12 Jan 2016 08:56:15 +0000
Subject: [docs] [issue24918] Docs layout bug
In-Reply-To: <1440361207.71.0.0873906255469.issue24918@psf.upfronthosting.co.za>
Message-ID: <1452588975.24.0.0546698263574.issue24918@psf.upfronthosting.co.za>


Georg Brandl added the comment:

If it works...

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 04:04:05 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Jan 2016 09:04:05 +0000
Subject: [docs] [issue19006] UnitTest docs should have a single list of
 assertions
In-Reply-To: <1378914335.13.0.0543263347661.issue19006@psf.upfronthosting.co.za>
Message-ID: <20160112090402.59566.77271@psf.io>


Roundup Robot added the comment:

New changeset ddb8fa84a119 by Ezio Melotti in branch '2.7':
#19006: fix wording in unittest docs.
https://hg.python.org/cpython/rev/ddb8fa84a119

New changeset 84f34e8685de by Ezio Melotti in branch '3.5':
#19006: fix wording in unittest docs.
https://hg.python.org/cpython/rev/84f34e8685de

New changeset 86c8d65d188f by Ezio Melotti in branch 'default':
#19006: merge with 3.5.
https://hg.python.org/cpython/rev/86c8d65d188f

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 04:04:50 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2016 09:04:50 +0000
Subject: [docs] [issue19006] UnitTest docs should have a single list of
 assertions
In-Reply-To: <1378914335.13.0.0543263347661.issue19006@psf.upfronthosting.co.za>
Message-ID: <1452589490.46.0.896937437007.issue19006@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the review!

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 04:28:11 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Jan 2016 09:28:11 +0000
Subject: [docs] [issue26001] Tutorial: write() does not expect string in
 binary mode
In-Reply-To: <1451829375.45.0.0188699168911.issue26001@psf.upfronthosting.co.za>
Message-ID: <20160112092807.59576.42280@psf.io>


Roundup Robot added the comment:

New changeset 5a2692911a43 by Ezio Melotti in branch '3.5':
#26001: mention in the tutorial that files in binary mode expect bytes, not str.
https://hg.python.org/cpython/rev/5a2692911a43

New changeset 4b434a4770a9 by Ezio Melotti in branch 'default':
#26001: merge with 3.5.
https://hg.python.org/cpython/rev/4b434a4770a9

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 04:30:02 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2016 09:30:02 +0000
Subject: [docs] [issue26001] Tutorial: write() does not expect string in
 binary mode
In-Reply-To: <1451829375.45.0.0188699168911.issue26001@psf.upfronthosting.co.za>
Message-ID: <1452591002.08.0.639918634848.issue26001@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks Dimistri for the report, Upendra for the patch, Terry for the review, and Elena for the rewrapping!
I also rephrased the last sentence a bit to make it more readable.

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 04:36:46 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Jan 2016 09:36:46 +0000
Subject: [docs] [issue25574] 2.7 incorrectly documents objects hash as equal
 to id
In-Reply-To: <1446849305.52.0.678156368856.issue25574@psf.upfronthosting.co.za>
Message-ID: <20160112093634.11393.18562@psf.io>


Roundup Robot added the comment:

New changeset 499ee454eecc by Ezio Melotti in branch '2.7':
#25574: backport glossary doc fix about hash and id of user-defined classes.
https://hg.python.org/cpython/rev/499ee454eecc

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 04:37:14 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jan 2016 09:37:14 +0000
Subject: [docs] [issue25574] 2.7 incorrectly documents objects hash as equal
 to id
In-Reply-To: <1446849305.52.0.678156368856.issue25574@psf.upfronthosting.co.za>
Message-ID: <1452591434.6.0.634411931495.issue25574@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 19:39:59 2016
From: report at bugs.python.org (khyox)
Date: Wed, 13 Jan 2016 00:39:59 +0000
Subject: [docs] [issue26094] ConfigParser.get() doc to be updated according
 to the configparser.py header doc
Message-ID: <1452645599.68.0.959713633048.issue26094@psf.upfronthosting.co.za>


New submission from khyox:

For the sake of clarity, in https://docs.python.org/3.5/library/configparser.html#configparser.ConfigParser the ConfigParser.get() method doc could be properly updated with merging the information written in the header doc of the source file, as found in https://hg.python.org/cpython/file/3.5/Lib/configparser.py

Concretely, this sentence there, "Return a string value for the named option." could be considered quite relevant to be added to the doc of the method, as some packages are (incorrectly) expecting boolean values returned by the ConfigParser.get() method. The reality is that a "True" in the configuration file is returning the string "True" and not the boolean constant True.

To sum up, the suggested update would be:

    def get(self, section, option, *, raw=False, vars=None, fallback=_UNSET):
        """Returns a string value for the named option for a given section.

        If `vars' is provided, it must be a dictionary. The option is looked up
        in `vars' (if provided), `section', and in `DEFAULTSECT' in that order.
        If the key is not found and `fallback' is provided, it is used as
        a fallback value. `None' can be provided as a `fallback' value.

        If interpolation is enabled and the optional argument `raw' is False,
        all interpolations are expanded in the return values.

        Arguments `raw', `vars', and `fallback' are keyword only.

        The section DEFAULT is special.
        """
        (...)

----------
assignee: docs at python
components: Documentation
messages: 258124
nosy: docs at python, khyox
priority: normal
severity: normal
status: open
title: ConfigParser.get() doc to be updated according to the configparser.py header doc
type: enhancement
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 21:16:37 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 13 Jan 2016 02:16:37 +0000
Subject: [docs] [issue26095] Update porting HOWTO to special-case Python 2
 code, not Python 3
Message-ID: <1452651397.71.0.110404454924.issue26095@psf.upfronthosting.co.za>


New submission from Brett Cannon:

As pointed out by http://astrofrog.github.io/blog/2016/01/12/stop-writing-python-4-incompatible-code/, special-casing Python 3 code instead of Python 2 code when writing Python 2/3 code will lead to breakage when Python 3 comes out. There should probably be a note in the porting HOWTO mentioning that you should always special-case Python 2 code and not Python 3 code.

----------
assignee: docs at python
components: Documentation
messages: 258126
nosy: brett.cannon, docs at python
priority: normal
severity: normal
status: open
title: Update porting HOWTO to special-case Python 2 code, not Python 3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 21:17:07 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 13 Jan 2016 02:17:07 +0000
Subject: [docs] [issue26095] Update porting HOWTO to special-case Python 2
 code, not Python 3
In-Reply-To: <1452651397.71.0.110404454924.issue26095@psf.upfronthosting.co.za>
Message-ID: <1452651427.31.0.337955516485.issue26095@psf.upfronthosting.co.za>


Brett Cannon added the comment:

And suggesting feature detection is even better than version detection.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 12 23:33:37 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 13 Jan 2016 04:33:37 +0000
Subject: [docs] [issue26095] Update porting HOWTO to special-case Python 2
 code, not Python 3
In-Reply-To: <1452651397.71.0.110404454924.issue26095@psf.upfronthosting.co.za>
Message-ID: <1452659616.97.0.365873987787.issue26095@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The feature detection approach is especially important for anything covered by the security backports in PEP 466 and 476, but can also apply for things like installing the importlib2 meta_path hooks into Python 2.7.

----------
nosy: +ncoghlan

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 00:00:21 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Jan 2016 05:00:21 +0000
Subject: [docs] [issue26087] PEP 0373 should be updated
In-Reply-To: <1452572071.97.0.659652590609.issue26087@psf.upfronthosting.co.za>
Message-ID: <20160113050017.4226.14045@psf.io>


Roundup Robot added the comment:

New changeset 1046a40e086f by Benjamin Peterson in branch 'default':
update 2.7 schedule (closes #26087)
https://hg.python.org/peps/rev/1046a40e086f

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 06:07:08 2016
From: report at bugs.python.org (=?utf-8?q?Nicolas_=C3=89vrard?=)
Date: Wed, 13 Jan 2016 11:07:08 +0000
Subject: [docs] [issue26097] 2.7 documentation about TextTestRunner do not
 specify all the arguments
Message-ID: <1452683228.39.0.232346799389.issue26097@psf.upfronthosting.co.za>


New submission from Nicolas ?vrard:

Some of the arguments although specified further in the documentation do not appear in the signature of TextTestRunner.

Here's a simple patch to include them.

----------
assignee: docs at python
components: Documentation
files: unittest_doc_bug.diff
keywords: patch
messages: 258140
nosy: docs at python, nicoe
priority: normal
severity: normal
status: open
title: 2.7 documentation about TextTestRunner do not specify all the arguments
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file41600/unittest_doc_bug.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 15:08:46 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 13 Jan 2016 20:08:46 +0000
Subject: [docs] [issue23762] python.org page on new-style classes should be
 updated
In-Reply-To: <1427207285.84.0.436806674049.issue23762@psf.upfronthosting.co.za>
Message-ID: <1452715726.22.0.233763831689.issue23762@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I've now added a warning to the document.

----------
stage: needs patch -> resolved
status: pending -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 18:16:28 2016
From: report at bugs.python.org (Julien)
Date: Wed, 13 Jan 2016 23:16:28 +0000
Subject: [docs] [issue26106] Move licences to literal blocks
Message-ID: <1452726987.73.0.8328489013.issue26106@psf.upfronthosting.co.za>


New submission from Julien:

In the context of translating the documentation:

I'd like to move the licence texts in https://docs.python.org/3.5/license.html to literal blocks, so they won't pollute the po files with legal (untranslatable) stuff, and it's visually more appealing (as far as it's possible for a licence text).

Here is what it gives graphically when applying the patch (it's the translation, don't mind the french text): http://www.afpy.org/doc/python/3.5/license.html

I also took the liberty to drop a dangling "ACCEPT", while reformating centered "titles" to real titles and building paragraphs from licence text, hope it wasn't legal stuff / part of the licence (a line before the licence mention an "accept" button ...).

----------
assignee: docs at python
components: Documentation
files: literal-licence.patch
keywords: patch
messages: 258180
nosy: docs at python, sizeof
priority: normal
severity: normal
status: open
title: Move licences to literal blocks
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41612/literal-licence.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 13 18:28:27 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jan 2016 23:28:27 +0000
Subject: [docs] [issue26106] Move licences to literal blocks
In-Reply-To: <1452726987.73.0.8328489013.issue26106@psf.upfronthosting.co.za>
Message-ID: <1452727707.82.0.111128451781.issue26106@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Sounds like a reasonable request to me.
Given the content of document, special care should be taken in reviewing the patch and making sure that nothing has gone missing.

----------
nosy: +ezio.melotti
stage:  -> patch review
type:  -> enhancement

_______________________________________
Python tracker 

_______________________________________

From cd458 at cornell.edu  Wed Jan 13 21:57:46 2016
From: cd458 at cornell.edu (Christian Delacroix)
Date: Wed, 13 Jan 2016 21:57:46 -0500
Subject: [docs] bug in chap 5
Message-ID: <9070A968-395B-4B80-8846-F11205F46BDB@cornell.edu>

Your wrote : 
list.pop([i])

which doesn?t work on my ipython ; instead 
list.pop(i)

works fine.

Don?t know if it?s of any help. I?ve read all chapters from 1 to 15, and it is amazingly useful. Thanks a lot.

Christian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jon101011 at yahoo.com  Wed Jan 13 17:04:53 2016
From: jon101011 at yahoo.com (Jon Snow)
Date: Wed, 13 Jan 2016 23:04:53 +0100
Subject: [docs] PostScript
Message-ID: <5696CA05.9000000@yahoo.com>

It's said on the downloads  page, on 
the "Other useful links" section, that you can view the documentation or 
download it in HTML, PostScript, PDF and other formats. I can't find the 
PostScript format among the other download options.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From senthil at uthcode.com  Thu Jan 14 03:46:57 2016
From: senthil at uthcode.com (Senthil Kumaran)
Date: Thu, 14 Jan 2016 00:46:57 -0800
Subject: [docs] bug in chap 5
In-Reply-To: <9070A968-395B-4B80-8846-F11205F46BDB@cornell.edu>
References: <9070A968-395B-4B80-8846-F11205F46BDB@cornell.edu>
Message-ID: 

It's explained in the docs:

list.pop([i])

Remove the item at the given position in the list, and return it. If no
index is specified, a.pop() removes and returns the last item in the list.
(The square brackets around the i in the method signature denote that the
parameter is optional, not that you should type square brackets at that
position. You will see this notation frequently in the Python Library
Reference.)

On Wed, Jan 13, 2016 at 6:57 PM, Christian Delacroix 
wrote:

> Your wrote :
>
> list.pop([i])
> which doesn?t work on my ipython ; instead
>
> list.pop(i)
> works fine.
>
> Don?t know if it?s of any help. I?ve read all chapters from 1 to 15, and
> it is amazingly useful. Thanks a lot.
>
> Christian
>
>
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From report at bugs.python.org  Thu Jan 14 03:48:15 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Jan 2016 08:48:15 +0000
Subject: [docs] [issue26106] Move licences to literal blocks
In-Reply-To: <1452726987.73.0.8328489013.issue26106@psf.upfronthosting.co.za>
Message-ID: <1452761295.04.0.246639419147.issue26106@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Does the |release| substitution work in literal blocks?

----------
nosy: +brett.cannon, georg.brandl, ned.deily, serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 04:36:41 2016
From: report at bugs.python.org (Julien)
Date: Thu, 14 Jan 2016 09:36:41 +0000
Subject: [docs] [issue26106] Move licences to literal blocks
In-Reply-To: <1452726987.73.0.8328489013.issue26106@psf.upfronthosting.co.za>
Message-ID: <1452764201.44.0.186926468245.issue26106@psf.upfronthosting.co.za>


Julien added the comment:

@Serhiy Well spotted, it does not work (as we can see here http://www.afpy.org/doc/python/3.5/license.html).

Anyone having a better background than me in ReStructuredText have an idea ?

About the review of the patch, as a human review may be fastidious, here a script to check that I did NOT modified the content of the licences themselves (still need to trust the command, but it's faster to review than the whole licence text itself):

    diff -w <(grep '^-' literal-licence.patch | cut -b2-) <(grep '^+' literal-licence.patch | cut -b2- | sed 's/\(^ *\)[0-8]\./\1#./g')

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 04:45:03 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 14 Jan 2016 09:45:03 +0000
Subject: [docs] [issue26106] Move licences to literal blocks
In-Reply-To: <1452726987.73.0.8328489013.issue26106@psf.upfronthosting.co.za>
Message-ID: <1452764703.0.0.54571839281.issue26106@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Since the text does need no highlighting, a parsed-literal block should work.

----------

_______________________________________
Python tracker 

_______________________________________

From senthil at uthcode.com  Thu Jan 14 10:21:13 2016
From: senthil at uthcode.com (Senthil Kumaran)
Date: Thu, 14 Jan 2016 07:21:13 -0800
Subject: [docs] PostScript
In-Reply-To: <5696CA05.9000000@yahoo.com>
References: <5696CA05.9000000@yahoo.com>
Message-ID: 

Hi Jon,

That's a mistake. My guess is, the term is a survivor from pre-sphinx days
when the python documentation and we had ps and pdf as output.
At the moment, only pdf output is published and will remove the wording on
ps from docs.

You can get a postscript output by downloading python source.

$cd Docs
$make latex
$cd build/latex
$make all-ps  # Seems to crash

Or, you could do:

$pdf2ps on the pdf files.

HTH,
Senthil


On Wed, Jan 13, 2016 at 2:04 PM, Jon Snow via docs  wrote:

> It's said on the downloads  page, on
> the "Other useful links" section, that you can view the documentation or
> download it in HTML, PostScript, PDF and other formats. I can't find the
> PostScript format among the other download options.
>
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From report at bugs.python.org  Thu Jan 14 13:09:16 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 14 Jan 2016 18:09:16 +0000
Subject: [docs] [issue26103] Contradiction in definition of "data
 descriptor" between (dotted lookup behavior/datamodel documentation) and
 (inspect lib/descriptor how-to)
In-Reply-To: <1452718612.1.0.925403449689.issue26103@psf.upfronthosting.co.za>
Message-ID: <1452794956.6.0.286127945011.issue26103@psf.upfronthosting.co.za>


Changes by SilentGhost :


----------
assignee:  -> docs at python
components: +Documentation, Library (Lib)
nosy: +docs at python, yselivanov
stage:  -> needs patch
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 14:29:52 2016
From: report at bugs.python.org (=?utf-8?b?0JLQsNGB0LjQu9GMINCa0L7Qu9C+0LzRltGU0YbRjA==?=)
Date: Thu, 14 Jan 2016 19:29:52 +0000
Subject: [docs] [issue26112] Error on example using "dialect" parameter.
 have to be: "dialect=dialect"
Message-ID: <1452799792.3.0.65685555924.issue26112@psf.upfronthosting.co.za>


New submission from ?????? ?????????:

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

have to be:
    ...
    reader = csv.reader(csvfile, dialect=dialect)
     # ... process CSV file contents here ...

It's here:
https://docs.python.org/3.4/library/csv.html

----------
assignee: docs at python
components: Documentation
messages: 258214
nosy: docs at python, ?????? ?????????
priority: normal
severity: normal
status: open
title: Error on example using "dialect" parameter. have to be: "dialect=dialect"
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 14:34:16 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 14 Jan 2016 19:34:16 +0000
Subject: [docs] [issue26112] Error on example using "dialect" parameter.
 have to be: "dialect=dialect"
In-Reply-To: <1452799792.3.0.65685555924.issue26112@psf.upfronthosting.co.za>
Message-ID: <1452800056.42.0.315379772531.issue26112@psf.upfronthosting.co.za>


SilentGhost added the comment:

No, the shown code works just fine.

----------
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 16:35:09 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 14 Jan 2016 21:35:09 +0000
Subject: [docs] [issue26111] On Windows,
 os.scandir will keep a handle on the directory until the iterator
 is exhausted
In-Reply-To: <1452797110.0.0.310492336724.issue26111@psf.upfronthosting.co.za>
Message-ID: <1452807309.67.0.259691217819.issue26111@psf.upfronthosting.co.za>


Martin Panter added the comment:

Remy, is this the same problem described in Issue 25994? There a close() method (like on generators) and/or context manager support is proposed for the scandir() iterator. Perhaps we can keep this issue open for adding a warning to the documentation, and the other issue can be for improving the API in 3.6.

----------
assignee:  -> docs at python
components: +Documentation
dependencies: +File descriptor leaks in os.scandir()
nosy: +docs at python, martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 16:46:39 2016
From: report at bugs.python.org (Remy Roy)
Date: Thu, 14 Jan 2016 21:46:39 +0000
Subject: [docs] [issue26111] On Windows,
 os.scandir will keep a handle on the directory until the iterator
 is exhausted
In-Reply-To: <1452797110.0.0.310492336724.issue26111@psf.upfronthosting.co.za>
Message-ID: <1452807999.16.0.763152178857.issue26111@psf.upfronthosting.co.za>


Remy Roy added the comment:

I believe Eryk's explanation on how a file in Windows doesn't actually get unlinked until all handles and kernel pointer references are closed is spot on about the problem I had.

I had a complex example that could probably have been simplified to what Eryk posted.

That behavior on Windows is quite counterintuitive. I'm not sure about what can be done to help it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 16:50:32 2016
From: report at bugs.python.org (=?utf-8?b?0JLQsNGB0LjQu9GMINCa0L7Qu9C+0LzRltGU0YbRjA==?=)
Date: Thu, 14 Jan 2016 21:50:32 +0000
Subject: [docs] [issue26116] CSV-module. The example code don't work. Have
 to be: reader = csv.reader(csvfile, dialect=dialect)
Message-ID: <1452808232.54.0.345665768771.issue26116@psf.upfronthosting.co.za>


New submission from ?????? ?????????:

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

have to be:
    ...
    reader = csv.reader(csvfile, dialect=dialect)
     # ... process CSV file contents here ...

It's here:
https://docs.python.org/3.4/library/csv.html

----------
assignee: docs at python
components: Documentation
messages: 258227
nosy: Vasyl Kolomiets, docs at python
priority: normal
severity: normal
status: open
title: CSV-module. The example code don't work.    Have to be: reader = csv.reader(csvfile, dialect=dialect)
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 16:54:30 2016
From: report at bugs.python.org (Remy Roy)
Date: Thu, 14 Jan 2016 21:54:30 +0000
Subject: [docs] [issue26111] On Windows,
 os.scandir will keep a handle on the directory until the iterator
 is exhausted
In-Reply-To: <1452797110.0.0.310492336724.issue26111@psf.upfronthosting.co.za>
Message-ID: <1452808470.22.0.542554465177.issue26111@psf.upfronthosting.co.za>


Remy Roy added the comment:

This issue is not same as Issue 25994 but it is quite related. Some kind of close() method and/or context manager support could help here as well.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 16:54:33 2016
From: report at bugs.python.org (=?utf-8?b?0JLQsNGB0LjQu9GMINCa0L7Qu9C+0LzRltGU0YbRjA==?=)
Date: Thu, 14 Jan 2016 21:54:33 +0000
Subject: [docs] [issue26116] CSV-module. The example code don't work. Have
 to be: reader = csv.reader(csvfile, dialect=dialect)
In-Reply-To: <1452808232.54.0.345665768771.issue26116@psf.upfronthosting.co.za>
Message-ID: <1452808473.64.0.980121841696.issue26116@psf.upfronthosting.co.za>


?????? ????????? added the comment:

Traceback (most recent call last):
  File "F:\Program Files (x86)\Pyton3_4\=Py\NovaPoshta\View#1-check-Trojan.py", line 11, in 
    for row in readed:
  File "F:\Program Files (x86)\Pyton3_4\lib\csv.py", line 118, in __next__
    d = dict(zip(self.fieldnames, row))
TypeError: zip argument #1 must support iteration

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:11:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Jan 2016 22:11:40 +0000
Subject: [docs] [issue26111] On Windows,
 os.scandir will keep a handle on the directory until the iterator
 is exhausted
In-Reply-To: <1452797110.0.0.310492336724.issue26111@psf.upfronthosting.co.za>
Message-ID: <1452809500.76.0.782474134768.issue26111@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:18:30 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 14 Jan 2016 22:18:30 +0000
Subject: [docs] [issue26116] CSV-module. The example code don't work. Have
 to be: reader = csv.reader(csvfile, dialect=dialect)
In-Reply-To: <1452808232.54.0.345665768771.issue26116@psf.upfronthosting.co.za>
Message-ID: <1452809910.32.0.279646626793.issue26116@psf.upfronthosting.co.za>


SilentGhost added the comment:

Vasyl, this line in your code is causing the problem:

    for row in readed:

The error reasonably clear states that it's due to your `fieldnames' parameter being non-iterable. Again, this has nothing whatsoever to do with `dialect' argument and documentation of Sniffer. 

Please, do not open new issues about this. This is not a issue with csv library or its documentation. Try to use use stackoverflow or python-tutor list to get help on this.
https://mail.python.org/pipermail/tutor/

----------
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:22:09 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 14 Jan 2016 22:22:09 +0000
Subject: [docs] [issue26111] On Windows,
 os.scandir will keep a handle on the directory until the iterator
 is exhausted
In-Reply-To: <1452797110.0.0.310492336724.issue26111@psf.upfronthosting.co.za>
Message-ID: <1452810129.47.0.352333548735.issue26111@psf.upfronthosting.co.za>


Martin Panter added the comment:

Can you explain how it is different? The way I see it, both problems are about the scandir() iterator holding an open reference (file descriptor or handle) to a directory/folder, when the iterator was not exhausted, but the caller no longer needs it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:24:53 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 14 Jan 2016 22:24:53 +0000
Subject: [docs] [issue26111] On Windows,
 os.scandir will keep a handle on the directory until the iterator
 is exhausted
In-Reply-To: <1452797110.0.0.310492336724.issue26111@psf.upfronthosting.co.za>
Message-ID: <1452810293.01.0.140228530702.issue26111@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> That behavior on Windows is quite counterintuitive.

It's counter-intuitive from a POSIX point of view, in which anonymous files are allowed. In contrast, Windows allows any existing reference to unset the delete disposition, so the name cannot be unlinked until all references are closed.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:36:24 2016
From: report at bugs.python.org (=?utf-8?b?0JLQsNGB0LjQu9GMINCa0L7Qu9C+0LzRltGU0YbRjA==?=)
Date: Thu, 14 Jan 2016 22:36:24 +0000
Subject: [docs] [issue26116] CSV-module. The example code don't work. Have
 to be: reader = csv.reader(csvfile, dialect=dialect)
In-Reply-To: <1452809910.32.0.279646626793.issue26116@psf.upfronthosting.co.za>
Message-ID: 


?????? ????????? added the comment:

Thanx a lot.
And sorry.
But with ..., dialect=dialect, .... the same code is working.
.
Ok. i'll try to understand.
With best wishes - VK.

? ?????????,
??????? ????????
+38050 45 22 559

2016-01-15 0:18 GMT+02:00 SilentGhost :

>
> SilentGhost added the comment:
>
> Vasyl, this line in your code is causing the problem:
>
>     for row in readed:
>
> The error reasonably clear states that it's due to your `fieldnames'
> parameter being non-iterable. Again, this has nothing whatsoever to do with
> `dialect' argument and documentation of Sniffer.
>
> Please, do not open new issues about this. This is not a issue with csv
> library or its documentation. Try to use use stackoverflow or python-tutor
> list to get help on this.
> https://mail.python.org/pipermail/tutor/
>
> ----------
> nosy: +SilentGhost
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker 
> 
> _______________________________________
>

----------
title: CSV-module. The example code don't work.    Have to be: reader = csv.reader(csvfile, dialect=dialect) -> CSV-module. The example code don't work. Have to be: reader = csv.reader(csvfile, dialect=dialect)

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 17:38:04 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 14 Jan 2016 22:38:04 +0000
Subject: [docs] [issue26116] CSV-module. The example code don't work. Have
 to be: reader = csv.reader(csvfile, dialect=dialect)
In-Reply-To: <1452808232.54.0.345665768771.issue26116@psf.upfronthosting.co.za>
Message-ID: <1452811084.35.0.302467945014.issue26116@psf.upfronthosting.co.za>


Georg Brandl added the comment:

We'll need at least the two full examples (one not working, one working) to make a call here.

----------
nosy: +georg.brandl

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 18:13:07 2016
From: report at bugs.python.org (Remy Roy)
Date: Thu, 14 Jan 2016 23:13:07 +0000
Subject: [docs] [issue26111] On Windows,
 os.scandir will keep a handle on the directory until the iterator
 is exhausted
In-Reply-To: <1452797110.0.0.310492336724.issue26111@psf.upfronthosting.co.za>
Message-ID: <1452813187.11.0.34527379907.issue26111@psf.upfronthosting.co.za>


Remy Roy added the comment:

>From my point of view, Issue 25994 is about the potential file descriptor/handle leaks and this issue is about being unable to perform some filesystem calls because of a hidden unclosed file descriptor/handle.

I am not going to protest if you want to treat them as the same issue.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 14 18:20:31 2016
From: report at bugs.python.org (=?utf-8?b?0JLQsNGB0LjQu9GMINCa0L7Qu9C+0LzRltGU0YbRjA==?=)
Date: Thu, 14 Jan 2016 23:20:31 +0000
Subject: [docs] [issue26116] CSV-module. The example code don't work. Have
 to be: reader = csv.reader(csvfile, dialect=dialect)
In-Reply-To: <1452811084.35.0.302467945014.issue26116@psf.upfronthosting.co.za>
Message-ID: 


?????? ????????? added the comment:

I am very happy!
Thx for attention to my opinion.
Sorry for my english.

so - in attachment two codes and source csv-file.

With best wishes,
Vasyl Kolomiets.
+38050 45 22 559

2016-01-15 0:38 GMT+02:00 Georg Brandl :

>
> Georg Brandl added the comment:
>
> We'll need at least the two full examples (one not working, one working)
> to make a call here.
>
> ----------
> nosy: +georg.brandl
>
> _______________________________________
> Python tracker 
> 
> _______________________________________
>

----------
Added file: http://bugs.python.org/file41617/may_be-error_csv_exmpl.py
Added file: http://bugs.python.org/file41618/from_to_proportions.csv
Added file: http://bugs.python.org/file41619/may_be-good_csv_exmpl.py

_______________________________________
Python tracker 

_______________________________________
-------------- next part --------------
from tkinter import *
from PIL import Image
import csv

filename = "from_to_proportions.csv"
with open(filename) as csvfile:
    dialect=csv.Sniffer().sniff(csvfile.read(1024))
    csvfile.seek(0)
    print(dialect)
    readed = csv.DictReader(csvfile, dialect)
    for row in readed:
        print(row)
        print (row["from_id"],row["from_name"],row['to_id'],row['to_name'],
               row['barcodes_percentage'],row['rows_to_be'])
        
-------------- next part --------------
A non-text attachment was scrubbed...
Name: from_to_proportions.csv
Type: text/csv
Size: 764 bytes
Desc: not available
URL: 
-------------- next part --------------
from tkinter import *
from PIL import Image
import csv

filename = "from_to_proportions.csv"
with open(filename) as csvfile:
    dialect=csv.Sniffer().sniff(csvfile.read(1024))
    csvfile.seek(0)
    print(dialect)
    readed = csv.DictReader(csvfile, dialect=dialect)
    for row in readed:
        print(row)
        print (row["from_id"],row["from_name"],row['to_id'],row['to_name'],
               row['barcodes_percentage'],row['rows_to_be'])
        

From report at bugs.python.org  Thu Jan 14 18:55:04 2016
From: report at bugs.python.org (=?utf-8?b?0JLQsNGB0LjQu9GMINCa0L7Qu9C+0LzRltGU0YbRjA==?=)
Date: Thu, 14 Jan 2016 23:55:04 +0000
Subject: [docs] [issue26116] CSV-module. The example code don't work. Have
 to be: reader = csv.reader(csvfile, dialect=dialect)
In-Reply-To: <1452808232.54.0.345665768771.issue26116@psf.upfronthosting.co.za>
Message-ID: <1452815704.59.0.363651406981.issue26116@psf.upfronthosting.co.za>


Changes by ?????? ????????? :


Added file: http://bugs.python.org/file41620/CSV-ex.png

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 00:58:06 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Jan 2016 05:58:06 +0000
Subject: [docs] [issue26097] 2.7 documentation about TextTestRunner do not
 specify all the arguments
In-Reply-To: <1452683228.39.0.232346799389.issue26097@psf.upfronthosting.co.za>
Message-ID: <20160115055802.25928.10231@psf.io>


Roundup Robot added the comment:

New changeset 687f0d4bc188 by Senthil Kumaran in branch '2.7':
Issue26097 - Fix the TextTestRunner documentation, mention all the arguments of the class.
https://hg.python.org/cpython/rev/687f0d4bc188

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 00:58:28 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 15 Jan 2016 05:58:28 +0000
Subject: [docs] [issue26097] 2.7 documentation about TextTestRunner do not
 specify all the arguments
In-Reply-To: <1452683228.39.0.232346799389.issue26097@psf.upfronthosting.co.za>
Message-ID: <1452837508.43.0.50663006355.issue26097@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for the report. Fixed.

----------
nosy: +orsenthil
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 01:31:40 2016
From: report at bugs.python.org (Antony Lee)
Date: Fri, 15 Jan 2016 06:31:40 +0000
Subject: [docs] [issue26120] pydoc: move __future__ imports out of the DATA
 block
Message-ID: <1452839500.03.0.307183465285.issue26120@psf.upfronthosting.co.za>


New submission from Antony Lee:

Currently, for a module that uses __future__ imports, the DATA section of `pydoc foo` contains these imports interspersed with the "real" data from the module.

Even though it is fully-featured _Feature objects that are imported, it probably makes sense to move them out of this section.

----------
assignee: docs at python
components: Documentation
messages: 258272
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: pydoc: move __future__ imports out of the DATA block
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 02:25:16 2016
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Jan 2016 07:25:16 +0000
Subject: [docs] [issue26116] CSV-module. The example code don't work. Have
 to be: reader = csv.reader(csvfile, dialect=dialect)
In-Reply-To: <1452808232.54.0.345665768771.issue26116@psf.upfronthosting.co.za>
Message-ID: <1452842715.96.0.620611150743.issue26116@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Thanks!  Now the reason is clear: You use csv.DictReader instead of csv.reader. csv.DictReader has a different argument list - for DictReader the second argument is `fieldnames`.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 03:41:13 2016
From: report at bugs.python.org (=?utf-8?b?0JLQsNGB0LjQu9GMINCa0L7Qu9C+0LzRltGU0YbRjA==?=)
Date: Fri, 15 Jan 2016 08:41:13 +0000
Subject: [docs] [issue26116] CSV-module. The example code don't work. Have
 to be: reader = csv.reader(csvfile, dialect=dialect)
In-Reply-To: <1452808232.54.0.345665768771.issue26116@psf.upfronthosting.co.za>
Message-ID: <1452847273.1.0.344412840987.issue26116@psf.upfronthosting.co.za>


?????? ????????? added the comment:

))
Thanks!
Be happy!

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 11:21:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Jan 2016 16:21:40 +0000
Subject: [docs] [issue26124] shlex.quote and pipes.quote do not quote shell
 keywords
In-Reply-To: <1452863681.04.0.149848593597.issue26124@psf.upfronthosting.co.za>
Message-ID: <1452874900.0.0.672729664402.issue26124@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be. But only if this doesn't make the documentation too verbose.

----------
assignee:  -> docs at python
components: +Documentation
keywords: +easy
nosy: +docs at python
stage:  -> needs patch

_______________________________________
Python tracker 

_______________________________________

From rfilippi at robertofilippi.it  Fri Jan 15 12:02:17 2016
From: rfilippi at robertofilippi.it (Roberto Filippi - AHS)
Date: Fri, 15 Jan 2016 18:02:17 +0100
Subject: [docs] Perhaps True instead of False
Message-ID: <56992619.7090901@robertofilippi.it>

An HTML attachment was scrubbed...
URL: 

From georg at python.org  Fri Jan 15 12:16:22 2016
From: georg at python.org (Georg Brandl)
Date: Fri, 15 Jan 2016 18:16:22 +0100
Subject: [docs] Perhaps True instead of False
In-Reply-To: <56992619.7090901@robertofilippi.it>
References: <56992619.7090901@robertofilippi.it>
Message-ID: <56992966.9090607@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Roberto,

the current wording is actually correct.  (You can create a broken
symlink yourself to check).

The purpose of `lexists` is to find out if "something" exists at the
path without following symlinks, so it is not necessary for the symlink
to point at something that exists.

cheers,
Georg

On 01/15/2016 06:02 PM, Roberto Filippi - AHS wrote:
> Hi all,
> 
> in https://docs.python.org/2/library/os.path.html
> 
> maybe that| " os.path.||lexists|(/path/)
> 
> Return |True| if /path/ refers to an existing path. Returns |True| for 
> broken symbolic links. Equivalent to |exists()| 
>  on
> platforms lacking |os.lstat()|
> .
> 
> "
> 
> should be " |os.path.||lexists|(/path/)
> 
> Return |True| if /path/ refers to an existing path. Returns *|True|False* 
> for broken symbolic links. Equivalent to |exists()| 
>  on
> platforms lacking |os.lstat()|
> .
> 
> "
> 
> Thanks for your work!


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlaZKWYACgkQN9GcIYhpnLCPggCfXJ3eCR/BOBfVDHIPm18ZMcGT
cmIAn0Zwm++iPTODyYY2c2hZGNYxgWbW
=KMks
-----END PGP SIGNATURE-----

From report at bugs.python.org  Fri Jan 15 13:44:29 2016
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 15 Jan 2016 18:44:29 +0000
Subject: [docs] [issue26124] shlex.quote and pipes.quote do not quote shell
 keywords
In-Reply-To: <1452863681.04.0.149848593597.issue26124@psf.upfronthosting.co.za>
Message-ID: <1452883469.2.0.883998300717.issue26124@psf.upfronthosting.co.za>


Fred L. Drake, Jr. added the comment:

It's not at all obvious that the intention is to ensure such an argument should be treated only as a command external to the shell.

If an application really wants to ensure the command is not handled as a shell built-in, it should use shell=False.

Making this clear in the documentation is reasonable.

----------
nosy: +fdrake

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 13:48:20 2016
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 15 Jan 2016 18:48:20 +0000
Subject: [docs] [issue26094] ConfigParser.get() doc to be updated according
 to the configparser.py header doc
In-Reply-To: <1452645599.68.0.959713633048.issue26094@psf.upfronthosting.co.za>
Message-ID: <1452883700.64.0.343698075512.issue26094@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. :


----------
nosy: +fdrake

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 13:56:51 2016
From: report at bugs.python.org (Antony Lee)
Date: Fri, 15 Jan 2016 18:56:51 +0000
Subject: [docs] [issue26127] Broken link in docs for tokenize
Message-ID: <1452884211.95.0.164669159709.issue26127@psf.upfronthosting.co.za>


New submission from Antony Lee:

The docs for `tokenize.detect_encoding` state `Use open() to open Python source files: it uses detect_encoding() to detect the file encoding.`

Unfortunately, clicking on `open` redirects to the builtin `open` function, not to `tokenize.open` as it should.

----------
assignee: docs at python
components: Documentation
messages: 258319
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Broken link in docs for tokenize
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 14:12:45 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 15 Jan 2016 19:12:45 +0000
Subject: [docs] [issue26127] Broken link in docs for tokenize
In-Reply-To: <1452884211.95.0.164669159709.issue26127@psf.upfronthosting.co.za>
Message-ID: <1452885165.24.0.126881385288.issue26127@psf.upfronthosting.co.za>


SilentGhost added the comment:

Here is the patch. Most of the fixes are however for the tokenize function that was for whatever reason linked to the module.

----------
keywords: +patch
nosy: +SilentGhost
stage:  -> patch review
type:  -> behavior
Added file: http://bugs.python.org/file41628/issue26127.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 14:29:50 2016
From: report at bugs.python.org (Charles Daffern)
Date: Fri, 15 Jan 2016 19:29:50 +0000
Subject: [docs] [issue26124] shlex.quote and pipes.quote do not quote shell
 keywords
In-Reply-To: <1452863681.04.0.149848593597.issue26124@psf.upfronthosting.co.za>
Message-ID: <1452886190.18.0.454729273231.issue26124@psf.upfronthosting.co.za>


Charles Daffern added the comment:

>To be sure that it is existing program, you can use shutil.which()

I'd like to clear this up a little because this is worded as if shutil.which()'s success implies that the shell will not fail.

Here is the setup to demonstrate:

>>> import os, shlex, shutil, subprocess
>>> open("do", "w").write("#!/bin/sh\necho Something is being done...")
__main__:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='do' mode='w' encoding='UTF-8'>
41
>>> os.chmod("do", 0o700)


Here is the behaviour using shlex.quote:

>>> subprocess.call(shlex.quote("do"), shell=True, env={'PATH': '.'})
/bin/sh: 1: Syntax error: "do" unexpected
2


Here is the behaviour when quoting properly:

>>> subprocess.call("'do'", shell=True, env={'PATH': '.'})
Something is being done...
0


Here is the output of shutil.which:

>>> shutil.which("do", path=".")
'./do'


So checking shutil.which()'s success or failure will not guard against this case (though using its output would work around the problem).

>It's not at all obvious that the intention is to ensure such an argument should be treated only as a command external to the shell.
>
>If an application really wants to ensure the command is not handled as a shell built-in, it should use shell=False.

The shell will still search builtins if the argument is quoted, it just won't search for keywords. So, a quoted "bind", "shopt" or "jobs" will still work, but a quoted "case", "fi" or "done" will cause the shell to search for a command of that name rather than treating it as syntax.

Looking at the source, shlex.quote's refusal to quote certain arguments appears to be intentional. I would rather it quote slightly more carefully than necessary, than quote something incorrectly.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 17:49:23 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 15 Jan 2016 22:49:23 +0000
Subject: [docs] [issue26094] ConfigParser.get() doc to be updated according
 to the configparser.py header doc
In-Reply-To: <1452645599.68.0.959713633048.issue26094@psf.upfronthosting.co.za>
Message-ID: <1452898163.06.0.737650473001.issue26094@psf.upfronthosting.co.za>


Martin Panter added the comment:

Perhaps the doc string of the module should be condensed into a much shorter summary of the class and its methods, and the details should be moved to individual doc strings and the main documentation.

----------
nosy: +martin.panter
stage:  -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 18:03:03 2016
From: report at bugs.python.org (Bernie Hackett)
Date: Fri, 15 Jan 2016 23:03:03 +0000
Subject: [docs] [issue24832] Issue building viewable docs with newer sphinx
 (default theme -> classic)
In-Reply-To: <1439052495.87.0.415280083267.issue24832@psf.upfronthosting.co.za>
Message-ID: <1452898983.66.0.324524000933.issue24832@psf.upfronthosting.co.za>


Bernie Hackett added the comment:

We had the same problem with PyMongo's docs. The issue happens with Sphinx 1.3.0 and 1.3.1. It appears to be resolved in 1.3.2. The changelog includes this line (no issue number is mentioned):

Add a ?default.css? stylesheet (which imports ?classic.css?) for compatibility.

http://www.sphinx-doc.org/en/stable/changes.html#release-1-3-2-released-nov-29-2015

----------
nosy: +behackett

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 19:13:57 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Jan 2016 00:13:57 +0000
Subject: [docs] [issue13743] xml.dom.minidom.Document class is not documented
In-Reply-To: <1326114378.06.0.424770823698.issue13743@psf.upfronthosting.co.za>
Message-ID: <1452903237.62.0.150085089632.issue13743@psf.upfronthosting.co.za>


Martin Panter added the comment:

In xml.dom, the documentation suggests that there are classes called Document and others, and I was surprised to find that they don?t exist. Apparently they are more like pseudo-code names of abstract interfaces instead. However in xml.dom.minidom there is a real Python class called Document. The documentation should be clearer about this.

I don?t think we need to duplicate the descriptions already given in xml.dom. But it would be good to explicitly say what the public minidom classes are, and point out (or link) what APIs they support.

----------
components: +XML
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 20:50:55 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Jan 2016 01:50:55 +0000
Subject: [docs] [issue24832] Issue building viewable docs with newer sphinx
 (default theme -> classic)
In-Reply-To: <1439052495.87.0.415280083267.issue24832@psf.upfronthosting.co.za>
Message-ID: <1452909054.95.0.49492303585.issue24832@psf.upfronthosting.co.za>


Martin Panter added the comment:

After upgrading from 1.3.1 to 1.3.4, I no longer get the warning. Perhaps we can close this now?

----------
nosy: +martin.panter
resolution:  -> third party

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 23:48:37 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Jan 2016 04:48:37 +0000
Subject: [docs] [issue26127] Broken link in docs for tokenize
In-Reply-To: <1452884211.95.0.164669159709.issue26127@psf.upfronthosting.co.za>
Message-ID: <20160116044834.121286.48099@psf.io>


Roundup Robot added the comment:

New changeset 4b4dbc90c6a0 by Martin Panter in branch '3.5':
Issue #26127: Fix links in tokenize documentation; patch by Silent Ghost
https://hg.python.org/cpython/rev/4b4dbc90c6a0

New changeset fe360700d1ae by Martin Panter in branch 'default':
Issue #26127: Merge tokenize documentation
https://hg.python.org/cpython/rev/fe360700d1ae

New changeset 8b09d71fbb6b by Martin Panter in branch '2.7':
Issue #26127: Fix links in tokenize documentation
https://hg.python.org/cpython/rev/8b09d71fbb6b

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 15 23:50:14 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Jan 2016 04:50:14 +0000
Subject: [docs] [issue26127] Broken link in docs for tokenize
In-Reply-To: <1452884211.95.0.164669159709.issue26127@psf.upfronthosting.co.za>
Message-ID: <1452919814.03.0.721511544894.issue26127@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the report and patch. There were similar (but different) problems in the Python 2 documentation too.

----------
nosy: +martin.panter
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 00:21:43 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Jan 2016 05:21:43 +0000
Subject: [docs] [issue26127] Broken link in docs for tokenize
In-Reply-To: <1452884211.95.0.164669159709.issue26127@psf.upfronthosting.co.za>
Message-ID: <20160116052139.94208.5626@psf.io>


Roundup Robot added the comment:

New changeset 620a37dbc686 by Martin Panter in branch 'default':
Issue #26127: Merge test_gdb fix from 3.5
https://hg.python.org/cpython/rev/620a37dbc686

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 00:23:22 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Jan 2016 05:23:22 +0000
Subject: [docs] [issue26127] Broken link in docs for tokenize
In-Reply-To: <1452884211.95.0.164669159709.issue26127@psf.upfronthosting.co.za>
Message-ID: <1452921801.96.0.685939050093.issue26127@psf.upfronthosting.co.za>


Martin Panter added the comment:

Oops that last commit was for Issue #14771

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 00:41:10 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Jan 2016 05:41:10 +0000
Subject: [docs] [issue24832] Issue building viewable docs with newer sphinx
 (default theme -> classic)
In-Reply-To: <1439052495.87.0.415280083267.issue24832@psf.upfronthosting.co.za>
Message-ID: <1452922870.72.0.587412030803.issue24832@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

We build happily with 1.3.3 on docs.python.org, so looks like everything is okay.

----------
resolution: third party -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 00:46:17 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Jan 2016 05:46:17 +0000
Subject: [docs] [issue26035] traceback.print_tb() takes `tb`,
 not `traceback` as a keyword argument
In-Reply-To: <1452142055.04.0.968906484949.issue26035@psf.upfronthosting.co.za>
Message-ID: <20160116054614.96372.58022@psf.io>


Roundup Robot added the comment:

New changeset e40f6c3dc114 by Senthil Kumaran in branch '3.5':
Issue26035 - Correct the argument names used in the docs of the traceback module. Make it consistent with module args.
https://hg.python.org/cpython/rev/e40f6c3dc114

New changeset e96c1491896d by Senthil Kumaran in branch 'default':
Merge from 3.5
https://hg.python.org/cpython/rev/e96c1491896d

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 01:13:25 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Jan 2016 06:13:25 +0000
Subject: [docs] [issue26035] traceback.print_tb() takes `tb`,
 not `traceback` as a keyword argument
In-Reply-To: <1452142055.04.0.968906484949.issue26035@psf.upfronthosting.co.za>
Message-ID: <20160116061321.94196.36841@psf.io>


Roundup Robot added the comment:

New changeset daff4ced1b32 by Senthil Kumaran in branch '2.7':
Issue26035 - Correct the argument names used in the docs of the traceback module. Make it consistent with module args.
https://hg.python.org/cpython/rev/daff4ced1b32

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 01:14:51 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 16 Jan 2016 06:14:51 +0000
Subject: [docs] [issue26035] traceback.print_tb() takes `tb`,
 not `traceback` as a keyword argument
In-Reply-To: <1452142055.04.0.968906484949.issue26035@psf.upfronthosting.co.za>
Message-ID: <1452924891.63.0.946944989159.issue26035@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for the patch, Upendra Kumar. It's fixed now. Appreciate your taking care of other args and making the change meaningful.

----------
assignee: docs at python -> orsenthil
nosy: +orsenthil
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 04:42:26 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Jan 2016 09:42:26 +0000
Subject: [docs] [issue13743] xml.dom.minidom.Document class is not documented
In-Reply-To: <1326114378.06.0.424770823698.issue13743@psf.upfronthosting.co.za>
Message-ID: <1452937346.68.0.198241310807.issue13743@psf.upfronthosting.co.za>


Changes by Mark Lawrence :


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker 

_______________________________________

From bob.felice at gmail.com  Fri Jan 15 15:28:20 2016
From: bob.felice at gmail.com (Bob Felice)
Date: Fri, 15 Jan 2016 12:28:20 -0800
Subject: [docs] Documentation but in xml.etree.ElementTree.write
Message-ID: 

I was recently tripped up by a bug in the documentation for
the xml.etree.ElementTree write function that I found here:
https://docs.python.org/2.7/library/xml.etree.elementtree.html#xml.etree.ElementTree.ElementTree.write

The documentation says

>  *xml_declaration* controls if an XML declaration should be added to the
> file. Use False for never, True for always, None for only if not US-ASCII
> or UTF-8 (default is None).
>

However, setting *xml_declaration *to True does nothing unless the *encoding
*parameter is also set.

Here is the relevant code, from Python27\Lib\xml\etree\ElementTree.py:
def write(self, file_or_filename,
              # keyword arguments
              encoding=None,
              xml_declaration=None,
              default_namespace=None,
              method=None):
        # assert self._root is not None
        if not method:
            method = "xml"
        elif method not in _serialize:
            # FIXME: raise an ImportError for c14n if ElementC14N is
missing?
            raise ValueError("unknown method %r" % method)
        if hasattr(file_or_filename, "write"):
            file = file_or_filename
        else:
            file = open(file_or_filename, "wb")
        write = file.write
        *if not encoding:*
            if method == "c14n":
                encoding = "utf-8"
            else:
                encoding = "us-ascii"
        *elif xml_declaration* or (*xml_declaration *is None and
                                 encoding not in ("utf-8", "us-ascii")):
            if method == "xml":
                write("\n" % encoding)

The problem is, write does not even look at the value of the *xml_declaration
*unless the *encoding *parameter was specified. Even then, it won't write
the xml version string unless *method *is set to xml.

So, to be accurate, the documentation should say something like,

 write adds an xml declaration when *encoding *is specified and *method *equals
xml and either
*1) xml_declaration* is True, or
2) *xml_declaration *is None and *encoding *is neither utf-8 or us-ascii


Frankly, this code is overly complicated for what it is trying to do. I am
glad to see it was re-written for Python 3.

Cheers,

-- bob felice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kosvanec at gmail.com  Fri Jan 15 13:56:22 2016
From: kosvanec at gmail.com (Petr Kosvanec)
Date: Fri, 15 Jan 2016 19:56:22 +0100
Subject: [docs] documentation_suggestion
Message-ID: 

https://docs.python.org/2/reference/expressions.html#boolean-operations

Section 5.10. Boolean operations - ends with "... not ''.)"

But the sentence is meant to end with "... not '' yields True.)"

-- 
Petr

From rfilippi at robertofilippi.it  Fri Jan 15 15:18:48 2016
From: rfilippi at robertofilippi.it (Roberto Filippi - AHS)
Date: Fri, 15 Jan 2016 21:18:48 +0100
Subject: [docs] Perhaps True instead of False
In-Reply-To: <56992966.9090607@python.org>
References: <56992619.7090901@robertofilippi.it> <56992966.9090607@python.org>
Message-ID: <56995428.2050405@robertofilippi.it>

An HTML attachment was scrubbed...
URL: 

From report at bugs.python.org  Sat Jan 16 17:01:44 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 16 Jan 2016 22:01:44 +0000
Subject: [docs] [issue25759] Python 2.7.11rc1 not building with Visual
 Studio 2015
In-Reply-To: <1448741441.78.0.371130073658.issue25759@psf.upfronthosting.co.za>
Message-ID: <1452981704.26.0.629963737645.issue25759@psf.upfronthosting.co.za>


Steve Dower added the comment:

Checked PCBuild/readme.txt and it's pretty clear that you can only use VS 2010+ with the SDK and the old compiler. So I'm closing this as wontfix as we will not be merging support to build Python 2 with VC10 or later.

----------
resolution:  -> wont fix
stage: needs patch -> 
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 20:08:48 2016
From: report at bugs.python.org (Cameron Conn)
Date: Sun, 17 Jan 2016 01:08:48 +0000
Subject: [docs] [issue26135] Documentation Recommends Deprecated `imp` Module
Message-ID: <1452992928.86.0.18217536546.issue26135@psf.upfronthosting.co.za>


New submission from Cameron Conn:

The documentation detailing modules recommends using the deprecated `imp` module in section 6.1. Instead, it should recommend `importlib`, which `imp` was deprecated in favor of in Python 3.4.

The portion of the documentation that says this is in the gray aside box at the bottom of Section 6.1 immediately before Section 6.1.1.

These are the pages that have this issue:
Python 3.4: https://docs.python.org/3.4/tutorial/modules.html#more-on-modules
Python 3.5: https://docs.python.org/3.5/tutorial/modules.html#more-on-modules
Python 3.6: https://docs.python.org/3.6/tutorial/modules.html#more-on-modules

----------
assignee: docs at python
components: Documentation
messages: 258438
nosy: camconn, docs at python
priority: normal
severity: normal
status: open
title: Documentation Recommends Deprecated `imp` Module
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 21:44:06 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Jan 2016 02:44:06 +0000
Subject: [docs] [issue26135] Documentation Recommends Deprecated `imp` Module
In-Reply-To: <1452992928.86.0.18217536546.issue26135@psf.upfronthosting.co.za>
Message-ID: <20160117024402.94222.64795@psf.io>


Roundup Robot added the comment:

New changeset 31e6d4d25b8e by Senthil Kumaran in branch '3.5':
Issue26135 - In the tutorial section on modules, reference importlib.reload instead of imp.reload.
https://hg.python.org/cpython/rev/31e6d4d25b8e

New changeset 6636d688bbd3 by Senthil Kumaran in branch 'default':
merge from 3.5
https://hg.python.org/cpython/rev/6636d688bbd3

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 16 21:46:18 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 17 Jan 2016 02:46:18 +0000
Subject: [docs] [issue26135] Documentation Recommends Deprecated `imp` Module
In-Reply-To: <1452992928.86.0.18217536546.issue26135@psf.upfronthosting.co.za>
Message-ID: <1452998778.35.0.533796594414.issue26135@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thank you for the report. Fixed in the active versions of python (3.5 and 3.6). 3.4 was in security fix mode. Although, it can see important documentation bug-fixes, this isn't bug-fix as far as 3.4 version is concerned. So, I didn't make the change in 3.4.

----------
assignee: docs at python -> orsenthil
nosy: +orsenthil
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions:  -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 11:35:46 2016
From: report at bugs.python.org (Julien)
Date: Sun, 17 Jan 2016 16:35:46 +0000
Subject: [docs] [issue26106] Move licences to literal blocks
In-Reply-To: <1452726987.73.0.8328489013.issue26106@psf.upfronthosting.co.za>
Message-ID: <1453048545.82.0.163333144792.issue26106@psf.upfronthosting.co.za>


Julien added the comment:

@georg.brandl is right, a parsed-literal block should work: Does not appear in pot files, and |release| replaced: nice.

I attached a new patch.

----------
Added file: http://bugs.python.org/file41641/literal-licence.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 11:55:40 2016
From: report at bugs.python.org (Ben Darnell)
Date: Sun, 17 Jan 2016 16:55:40 +0000
Subject: [docs] [issue26141] typing module documentation incomplete
Message-ID: <1453049740.68.0.762293537242.issue26141@psf.upfronthosting.co.za>


New submission from Ben Darnell:

The typing module docs at https://docs.python.org/3/library/typing.html do not include everything that is documented in the PEP (https://www.python.org/dev/peps/pep-0484/#the-typing-module). Specifically, `AnyStr` is mentioned but not defined, the `@overload` decorator is missing, and so are the new-to-3.5 types Awaitable, AsyncIterable, AsyncIterator.

----------
assignee: docs at python
components: Documentation
messages: 258475
nosy: Ben.Darnell, docs at python
priority: normal
severity: normal
status: open
title: typing module documentation incomplete
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 16:38:21 2016
From: report at bugs.python.org (Julien)
Date: Sun, 17 Jan 2016 21:38:21 +0000
Subject: [docs] [issue26106] Move licences to literal blocks
In-Reply-To: <1452726987.73.0.8328489013.issue26106@psf.upfronthosting.co.za>
Message-ID: <1453066701.03.0.478184236351.issue26106@psf.upfronthosting.co.za>


Julien added the comment:

And uploaded the result: http://www.afpy.org/doc/python/3.5/license.html

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 18:37:34 2016
From: report at bugs.python.org (Jim Nasby)
Date: Sun, 17 Jan 2016 23:37:34 +0000
Subject: [docs] [issue26142] Formatting bug on
 https://docs.python.org/2.7/c-api/intro.html
Message-ID: <1453073854.16.0.698165135506.issue26142@psf.upfronthosting.co.za>


New submission from Jim Nasby:

The code for the set_all() example has a formatting bug:

            return -1;
    }
        Py_DECREF(index);
    }

it should be

            return -1;
        }
        Py_DECREF(index);
    }

----------
assignee: docs at python
components: Documentation
messages: 258486
nosy: Jim Nasby, docs at python
priority: normal
severity: normal
status: open
title: Formatting bug on https://docs.python.org/2.7/c-api/intro.html
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 20:05:23 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Jan 2016 01:05:23 +0000
Subject: [docs] [issue26142] Formatting bug on
 https://docs.python.org/2.7/c-api/intro.html
In-Reply-To: <1453073854.16.0.698165135506.issue26142@psf.upfronthosting.co.za>
Message-ID: <20160118010519.94202.15575@psf.io>


Roundup Robot added the comment:

New changeset 4f1ed606410b by Senthil Kumaran in branch '2.7':
Issue26142 - Fix a formatting bug in c-api intro doc.
https://hg.python.org/cpython/rev/4f1ed606410b

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 20:05:55 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 18 Jan 2016 01:05:55 +0000
Subject: [docs] [issue26142] Formatting bug on
 https://docs.python.org/2.7/c-api/intro.html
In-Reply-To: <1453073854.16.0.698165135506.issue26142@psf.upfronthosting.co.za>
Message-ID: <1453079155.06.0.374061138771.issue26142@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for reporting. Fixed.

----------
nosy: +orsenthil
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 21:43:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Jan 2016 02:43:00 +0000
Subject: [docs] [issue26017] Update
 https://docs.python.org/3/installing/index.html to always quote arguments
In-Reply-To: <1452015796.73.0.274069830205.issue26017@psf.upfronthosting.co.za>
Message-ID: <20160118024256.25908.98954@psf.io>


Roundup Robot added the comment:

New changeset 31debd0dc0dc by Senthil Kumaran in branch '3.5':
Issue26017 - Suggest enclosing command args in double quotes when using characters which get interpreted by shell.
https://hg.python.org/cpython/rev/31debd0dc0dc

New changeset 18ae23b69e08 by Senthil Kumaran in branch 'default':
Merge from 3.5
https://hg.python.org/cpython/rev/18ae23b69e08

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 21:45:17 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Jan 2016 02:45:17 +0000
Subject: [docs] [issue26017] Update
 https://docs.python.org/3/installing/index.html to always quote arguments
In-Reply-To: <1452015796.73.0.274069830205.issue26017@psf.upfronthosting.co.za>
Message-ID: <20160118024515.5435.49794@psf.io>


Roundup Robot added the comment:

New changeset 668827be66d6 by Senthil Kumaran in branch '2.7':
Issue26017 - Suggest enclosing command args in double quotes when using characters which get interpreted by shell.
https://hg.python.org/cpython/rev/668827be66d6

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 17 21:46:31 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 18 Jan 2016 02:46:31 +0000
Subject: [docs] [issue26017] Update
 https://docs.python.org/3/installing/index.html to always quote arguments
In-Reply-To: <1452015796.73.0.274069830205.issue26017@psf.upfronthosting.co.za>
Message-ID: <1453085191.83.0.846646415099.issue26017@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for the review/comment Ezio. Agree with your suggestion and made the change accordingly.

----------
assignee: docs at python -> orsenthil
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From senthil at uthcode.com  Mon Jan 18 12:11:47 2016
From: senthil at uthcode.com (Senthil Kumaran)
Date: Mon, 18 Jan 2016 09:11:47 -0800
Subject: [docs] problem with epub
In-Reply-To: <064b01d13af2$78173ae0$6845b0a0$@gmail.com>
References: <064b01d13af2$78173ae0$6845b0a0$@gmail.com>
Message-ID: 

I think, the epub generated by docs is simply broken. We have to file an
issue and fix it.
You could create a pdf and use that in your e-reader or convert pdf to epub
using external software.

-- 
Senthil


On Sat, Dec 19, 2015 at 10:48 PM, Gaston A. Giordana <
gaston.giordana at gmail.com> wrote:

> Dear all,
>
>
>
> I?m using the Windows version. I encountering problems to import the epub
> file into my reader library. In fact, the reader does not recognise the
> format. I do not know if the problem comes from the documentation or my
> reader that does not support some formats. Which epub reader would you
> recommend to use?
>
>
>
> Thanks in advance.
>
>
>
> Best regards,
>
>
>
> Gaston Giordana
>
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From report at bugs.python.org  Mon Jan 18 16:48:42 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Jan 2016 21:48:42 +0000
Subject: [docs] [issue26124] shlex.quote and pipes.quote do not quote shell
 keywords
In-Reply-To: <1452863681.04.0.149848593597.issue26124@psf.upfronthosting.co.za>
Message-ID: <1453153722.71.0.706532022296.issue26124@psf.upfronthosting.co.za>


R. David Murray added the comment:

Quote is for quoting shell special characters, not command names.  It would be fairly straightforward to add that to the docs ("Return a version of the string s will with all shell special characters (including whitespace) escaped according to shell escaping rules."  Wordier, but more accurate, and not *too* much longer.

----------
nosy: +r.david.murray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 16:48:49 2016
From: report at bugs.python.org (John Hagen)
Date: Mon, 18 Jan 2016 21:48:49 +0000
Subject: [docs] [issue26149] Suggest PyCharm Community as an editor for Unix
 platforms
Message-ID: <1453153728.95.0.733172914649.issue26149@psf.upfronthosting.co.za>


New submission from John Hagen:

The Python documentation recommends editors that can be used on Unix:
https://docs.python.org/3.5/using/unix.html#editors

If the intent is to advertise very excellent IDEs (as Geany and Komodo Edit are listed), I suggest that PyCharm Community Edition (https://www.jetbrains.com/pycharm/download/) be added to the list.

It is free, has a very powerful static analyzer, comes with PEP8 checking installed by default, supports type hinting, ... (https://www.jetbrains.com/pycharm/features/)

----------
assignee: docs at python
components: Documentation
messages: 258551
nosy: John Hagen, docs at python
priority: normal
severity: normal
status: open
title: Suggest PyCharm Community as an editor for Unix platforms
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 17:13:13 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 18 Jan 2016 22:13:13 +0000
Subject: [docs] [issue26149] Suggest PyCharm Community as an editor for Unix
 platforms
In-Reply-To: <1453153728.95.0.733172914649.issue26149@psf.upfronthosting.co.za>
Message-ID: <1453155193.12.0.0515198943312.issue26149@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report. It would be better to refer to https://wiki.python.org/moin/PythonEditors and https://wiki.python.org/moin/IntegratedDevelopmentEnvironments instead of maintaining duplicate and outdated lists.

----------
keywords: +easy
nosy: +berker.peksag
stage:  -> needs patch
versions:  -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 18:48:30 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 18 Jan 2016 23:48:30 +0000
Subject: [docs] [issue24823] ctypes.create_string_buffer does not add NUL if
 len(init) == size
In-Reply-To: <1438942688.18.0.266077254276.issue24823@psf.upfronthosting.co.za>
Message-ID: <1453160909.86.0.140990993356.issue24823@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

(Tracker notes:

I added as nosy the people listed as active 'experts' for ctypes on https://docs.python.org/devguide/experts.html#experts.  This was easily done by going to the end of the nosy list, typing a comma ',', typing 'ctypes', and then clicking the box that appeared.  This can be done for any module and the other topics listed on the page.

The Documentation component is for issues that only change the docs, and not the code.  That is why Documentation issues are auto-assigned to docs at python.  Adding 'Documentation' amounts to rejecting this patch or anything else that changes the code.

asyncio, ctypes, IDLE (idlelib), IO, and (T)tkinter are all parts of the stdlib and AFAIK, issues marked for them do not have to also be marked 'Library'.)
---

I looked at ctypes.py with hg annotate.  Create_string_buffer is part of Thomas Heller's original 2006-03-08 patch that moved ctypes from an external source into the stdlib.  The only changes are in the isinstance class checks and the raise statement; the conditional bodies, including the one in question, are unchanged.

Tom, we disagree on our reading of the current docs.  The default number of NULL bytes added is 1.  Is the second argument required to be large enough to keep the number positive?  You think yes, I think no, though I agree with Eryk that the second quoted sentence could and should be clearer.  I will not assume that T. Heller meant 'yes' when he wrote 'no' in the code.  What do the listed experts think?

If the doc matches the code, there is no implementation bug and this is not a behavior issue. It is still possible to request a design change as an enhancement.  I think this would require agreement of at least two core developers.  A deprecation notice would normally be needed.  A third possibility is to decide that this is a security issue severe enough to possibly break code in 3.6 and possibly sooner.  I think this would require pydev discussion.

One problem with changing ctypes is that it is not used in the stdlib, so we have no local examples to draw on.  In this case, the question would be how often is 'size' used to suppress the default NULL byte and how legitimate are such uses.

----------
components: +Devguide -Documentation, Library (Lib), ctypes
nosy: +amaury.forgeotdarc, belopolsky, ezio.melotti, meador.inge, terry.reedy, willingc

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 20:16:43 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 19 Jan 2016 01:16:43 +0000
Subject: [docs] [issue5626] misleading comment in socket.gethostname()
 documentation
In-Reply-To: <1238515382.33.0.784525971679.issue5626@psf.upfronthosting.co.za>
Message-ID: <1453166203.01.0.846537063491.issue5626@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Given that we have not received any more reports on users tripping up on this message, it seems to me that we could just ignore this report and close it. Thoughts?

----------
nosy: +orsenthil

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 20:52:09 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 19 Jan 2016 01:52:09 +0000
Subject: [docs] [issue5626] misleading comment in socket.gethostname()
 documentation
In-Reply-To: <1238515382.33.0.784525971679.issue5626@psf.upfronthosting.co.za>
Message-ID: <1453168329.44.0.540874710622.issue5626@psf.upfronthosting.co.za>


Ned Deily added the comment:

The point still stands that speaking of "the current machine's IP address" is misleading at best.  I'd say either apply Berker's suggested patch or expand the description to better reflect the real world of multiple interfaces.  Of course I'm biased.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 21:46:03 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Jan 2016 02:46:03 +0000
Subject: [docs] [issue23962] Incorrect TimeoutError referenced in
 concurrent.futures documentation
In-Reply-To: <1429068832.51.0.845639899608.issue23962@psf.upfronthosting.co.za>
Message-ID: <20160119024600.25920.36587@psf.io>


Roundup Robot added the comment:

New changeset 673d1ccea050 by Senthil Kumaran in branch '3.5':
issue23962 - Reference the correct TimeoutError in concurrent.futures documentation.
https://hg.python.org/cpython/rev/673d1ccea050

New changeset 2b0c7b67eca5 by Senthil Kumaran in branch 'default':
merge from 3.5
https://hg.python.org/cpython/rev/2b0c7b67eca5

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 18 21:47:40 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 19 Jan 2016 02:47:40 +0000
Subject: [docs] [issue23962] Incorrect TimeoutError referenced in
 concurrent.futures documentation
In-Reply-To: <1429068832.51.0.845639899608.issue23962@psf.upfronthosting.co.za>
Message-ID: <1453171660.28.0.30457457327.issue23962@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for the report and the patch. I have fixed that in 3.5 and 3.6 docs. I found it reasonable to include the full module path for TimeoutError makeing it consist with asyncio and multiprocessing TimeoutError.

Also, Error exception is not exposed via __all__ so, left this out in the documentation.

----------
assignee: docs at python -> orsenthil
nosy: +orsenthil
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From Richard at Hornbaker.com  Mon Jan 18 17:31:53 2016
From: Richard at Hornbaker.com (Richard D. Hornbaker)
Date: Mon, 18 Jan 2016 15:31:53 -0700
Subject: [docs] Addition to socket.connect() documentation
Message-ID: <20160118153153.ecf829a110995a36e52dec20574f2abd.c01652f594.wbe@email03.secureserver.net>

An HTML attachment was scrubbed...
URL: 

From report at bugs.python.org  Tue Jan 19 09:41:26 2016
From: report at bugs.python.org (=?utf-8?q?Chema_Cort=C3=A9s?=)
Date: Tue, 19 Jan 2016 14:41:26 +0000
Subject: [docs] [issue26156] Bad name into power operator syntax
Message-ID: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>


New submission from Chema Cort?s:

The documentation erroneously changes "primary" for "away" in the power operator syntax:

https://docs.python.org/3.6/reference/expressions.html#the-power-operator
https://docs.python.org/3.5/reference/expressions.html#the-power-operator

----------
assignee: docs at python
components: Documentation
messages: 258596
nosy: Chema Cort?s, docs at python
priority: normal
severity: normal
status: open
title: Bad name into power operator syntax
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 09:45:21 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 19 Jan 2016 14:45:21 +0000
Subject: [docs] [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1453214721.31.0.140024068225.issue26156@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

The docs are correct. See the definition of the "await" expression: https://docs.python.org/3.6/reference/expressions.html#await-expression

----------
nosy: +yselivanov
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 10:16:28 2016
From: report at bugs.python.org (Frank Millman)
Date: Tue, 19 Jan 2016 15:16:28 +0000
Subject: [docs] [issue26157] Typo in asyncio documentation
Message-ID: <1453216588.95.0.751274480755.issue26157@psf.upfronthosting.co.za>


New submission from Frank Millman:

18.5.1.15. Server

close()

"The sockets that represent existing incoming client connections are leaved open."

I think this should say 'are left open'.

----------
assignee: docs at python
components: Documentation
messages: 258599
nosy: docs at python, frankmillman
priority: normal
severity: normal
status: open
title: Typo in asyncio documentation
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 10:23:02 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 19 Jan 2016 15:23:02 +0000
Subject: [docs] [issue5626] misleading comment in socket.gethostname()
 documentation
In-Reply-To: <1238515382.33.0.784525971679.issue5626@psf.upfronthosting.co.za>
Message-ID: <1453216982.7.0.334299931765.issue5626@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I agree with Chris and Ned. I will apply issue5626_v1.diff today.

----------
stage:  -> commit review
type:  -> behavior
versions: +Python 3.5, Python 3.6 -Python 2.6, Python 3.0, Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 11:02:12 2016
From: report at bugs.python.org (Carlo Beccarini)
Date: Tue, 19 Jan 2016 16:02:12 +0000
Subject: [docs] [issue26157] Typo in asyncio documentation
In-Reply-To: <1453216588.95.0.751274480755.issue26157@psf.upfronthosting.co.za>
Message-ID: <1453219331.92.0.156710644925.issue26157@psf.upfronthosting.co.za>


Carlo Beccarini added the comment:

Absolutely.

----------
nosy: +Paradisee

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 11:12:39 2016
From: report at bugs.python.org (Carlo Beccarini)
Date: Tue, 19 Jan 2016 16:12:39 +0000
Subject: [docs] [issue26157] Typo in asyncio documentation
In-Reply-To: <1453216588.95.0.751274480755.issue26157@psf.upfronthosting.co.za>
Message-ID: <1453219959.95.0.187505431532.issue26157@psf.upfronthosting.co.za>


Changes by Carlo Beccarini :


----------
versions: +Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 11:24:52 2016
From: report at bugs.python.org (Carlo Beccarini)
Date: Tue, 19 Jan 2016 16:24:52 +0000
Subject: [docs] [issue26157] Typo in asyncio documentation
In-Reply-To: <1453216588.95.0.751274480755.issue26157@psf.upfronthosting.co.za>
Message-ID: <1453220692.95.0.358277415199.issue26157@psf.upfronthosting.co.za>


Changes by Carlo Beccarini :


----------
keywords: +patch
Added file: http://bugs.python.org/file41662/patch.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 12:24:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Jan 2016 17:24:43 +0000
Subject: [docs] [issue26158] File truncate() not defaulting to current
 position as documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453224283.82.0.40657108775.issue26158@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is because the file is buffered.

>>> open('temp.txt', 'w').write('ABCDE\nFGHIJ\nKLMNO\nPQRST\nUVWXY\nZ\n')
32
>>> f = open('temp.txt', 'r+')
>>> f.readline()
'ABCDE\n'
>>> f.tell()
6
>>> f.buffer.tell()
32
>>> f.buffer.raw.tell()
32

The documentation needs a clarification.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +benjamin.peterson, docs at python, haypo, pitrou, serhiy.storchaka, steve.dower, stutzbach
versions: +Python 2.7, Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 12:46:14 2016
From: report at bugs.python.org (Fornax)
Date: Tue, 19 Jan 2016 17:46:14 +0000
Subject: [docs] [issue26158] File truncate() not defaulting to current
 position as documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453225574.49.0.492043886443.issue26158@psf.upfronthosting.co.za>


Fornax added the comment:

To clarify... the intended behavior is for truncate to default to the current position of the buffer, rather than the current position as reported directly from the stream by tell?

That seems... surprising.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 12:46:56 2016
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 19 Jan 2016 17:46:56 +0000
Subject: [docs] [issue26158] File truncate() not defaulting to current
 position as documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453225616.37.0.137507915152.issue26158@psf.upfronthosting.co.za>


Eryk Sun added the comment:

Serhiy, why doesn't truncate do a seek(0, SEEK_CUR) to synchronize the buffer's file pointer before calling its truncate method? This also affects writing in "+" modes when the two file pointers are out of sync.

----------
nosy: +eryksun

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 13:04:26 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Jan 2016 18:04:26 +0000
Subject: [docs] [issue26158] File truncate() not defaulting to current
 position as documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453226666.56.0.308728032052.issue26158@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is not always possible. Consider following example:

>>> open('temp.txt', 'wb').write(b'+BDAEMQQyBDMENA-')
16
>>> f = open('temp.txt', 'r+', encoding='utf-7')
>>> f.read(2)
'??'

What should be the result of truncating?

I think it would be better to not implement truncate() for text files at all.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 13:23:00 2016
From: report at bugs.python.org (Fornax)
Date: Tue, 19 Jan 2016 18:23:00 +0000
Subject: [docs] [issue26158] File truncate() not defaulting to current
 position as documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453227780.66.0.0257660719865.issue26158@psf.upfronthosting.co.za>


Fornax added the comment:

Heh... building on Serhiy's example:

>>> f.tell()
680564735109527527154978616360239628288

I'm way out of my depth here. The results seem surprising, but I lack the experience to be able to say what they "should" look like. So I guess if it's working as intended and just needs clarification in the documentation, so be it.

Thanks for pointing out what's actually causing the behavior.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 14:24:28 2016
From: report at bugs.python.org (Fornax)
Date: Tue, 19 Jan 2016 19:24:28 +0000
Subject: [docs] [issue26158] File truncate() not defaulting to current
 position as documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453231468.23.0.121999934745.issue26158@psf.upfronthosting.co.za>


Fornax added the comment:

After taking a little time to let this sink in, I'm going to play Devil's Advocate just a little more.

It sounds like you're basically saying that any read-write text-based modes (e.g. r+, w+) should be used at your own peril. While I understand your UTF-7 counterexample, and it's a fair point, is it out of line to expect that for encodings that operate on full bytes, file positioning should work a bit more intuitively? (Which is to say, a write/truncate after a read should take place in the position immediately following the end of the read.)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 14:38:15 2016
From: report at bugs.python.org (Fornax)
Date: Tue, 19 Jan 2016 19:38:15 +0000
Subject: [docs] [issue26158] File truncate() not defaulting to current
 position as documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453232295.89.0.586887454079.issue26158@psf.upfronthosting.co.za>


Fornax added the comment:

Another surprising result:

>>> open('temp.txt', 'w').write('ABCDE\nFGHIJ\nKLMNO\nPQRST\nUVWXY\nZ\n')
32
>>> f = open('temp.txt', 'r+')
>>> f.write('test')
4
>>> f.close()
>>> open('temp.txt').read()
'testE\nFGHIJ\nKLMNO\nPQRST\nUVWXY\nZ\n'

>>> open('temp.txt', 'w').write('ABCDE\nFGHIJ\nKLMNO\nPQRST\nUVWXY\nZ\n')
32
>>> f = open('temp.txt', 'r+')
>>> f.write('test')
4
>>> f.read(1)
'A'
>>> f.close()
>>> open('temp.txt').read()
'ABCDE\nFGHIJ\nKLMNO\nPQRST\nUVWXY\nZ\ntest'

The position of the write in the file depends on whether or not there is a subsequent read.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 15:00:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Jan 2016 20:00:14 +0000
Subject: [docs] [issue26158] File truncate() not defaulting to current
 position as documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453233614.3.0.663923262079.issue26158@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be. Looking at the code, both Python and C implementations of TextIOWrapper look incorrect.

Python implementation:

    def truncate(self, pos=None):
        self.flush()
        if pos is None:
            pos = self.tell()
        return self.buffer.truncate(pos)

If pos is not specified, self.tell() is used as truncating position for underlying binary file. But self.tell() is not an offset in bytes, as seen from UTF-7 example. This is complex cookie that includes starting position in binary file, a number of bytes that should be read and feed to the decoder, and other decoder flags. Needed at least unpack the cookie returned by self.tell(), and raise an exception if it doesn't ambiguously point to binary file position.

C implementation is equivalent to:

    def truncate(self, pos=None):
        self.flush()
        return self.buffer.truncate(pos)

It just ignores decoder buffer.

----------
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 16:38:29 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 19 Jan 2016 21:38:29 +0000
Subject: [docs] [issue26158] File truncate() not defaulting to current
 position as documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453239509.64.0.993822204527.issue26158@psf.upfronthosting.co.za>


Martin Panter added the comment:

In theory, TextIOWrapper could rewrite the last bit of the file (or the whole file) to have the requested number of characters. But I wonder if it is worth it; maybe deprecation is better. Do you have a use case for any of these bugs, or are you just playing around to see what the methods do?

In Issue 12922, seek() and tell() were (re-)defined for TextIOBase, but the situation with truncate() was apparently not considered.

Perhaps the write()?read() bug is related to Issue 12215.

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 16:56:22 2016
From: report at bugs.python.org (Fornax)
Date: Tue, 19 Jan 2016 21:56:22 +0000
Subject: [docs] [issue26158] File truncate() not defaulting to current
 position as documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453240582.63.0.000511414294997.issue26158@psf.upfronthosting.co.za>


Fornax added the comment:

I don't have a specific use case. This spawned from a tangentially-related StackOverflow question (http://stackoverflow.com/questions/34858088), where in the answers a behavior difference between Python 2 and 3 was noted. I couldn't find any documentation to explain it, so I opened a follow-up question (http://stackoverflow.com/questions/34879318), and based on some feedback I got there, I opened up this issue.

Just to be sure I understand, you're suggesting deprecating truncate on text-mode file objects? And the interleaved read-writes are likely related to an issue that will be dealt with elsewhere?

----------
type: behavior -> 

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 17:07:34 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jan 2016 22:07:34 +0000
Subject: [docs] [issue26158] File truncate() not defaulting to current
 position as documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453241254.76.0.428480455581.issue26158@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy:  -haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 17:11:11 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 19 Jan 2016 22:11:11 +0000
Subject: [docs] [issue26158] File truncate() not defaulting to current
 position as documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453241471.21.0.211715183595.issue26158@psf.upfronthosting.co.za>


???? ????????? added the comment:

text files and seek() offset: issue25849

----------
nosy: +mmarkk

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 18:34:46 2016
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 19 Jan 2016 23:34:46 +0000
Subject: [docs] [issue26158] File truncate() not defaulting to current
 position as documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453246486.06.0.790685821146.issue26158@psf.upfronthosting.co.za>


Eryk Sun added the comment:

FYI, you can parse the cookie using struct or ctypes. For example:

    class Cookie(ctypes.Structure):
        _fields_ = (('start_pos',     ctypes.c_longlong),
                    ('dec_flags',     ctypes.c_int),
                    ('bytes_to_feed', ctypes.c_int),
                    ('chars_to_skip', ctypes.c_int),
                    ('need_eof',      ctypes.c_byte))

In the simple case only the buffer start_pos is non-zero, and the result of tell() is just the 64-bit file pointer. In Serhiy's UTF-7 example it needs to also convey the bytes_to_feed and chars_to_skip values:

    >>> f.tell()
    680564735109527527154978616360239628288
    >>> cookie_bytes = f.tell().to_bytes(ctypes.sizeof(Cookie), sys.byteorder)
    >>> state = Cookie.from_buffer_copy(cookie_bytes)
    >>> state.start_pos
    0
    >>> state.dec_flags
    0
    >>> state.bytes_to_feed
    16
    >>> state.chars_to_skip
    2
    >>> state.need_eof
    0

So a seek(0, SEEK_CUR) in this case has to seek the buffer to 0, read and decode 16 bytes, and skip 2 characters. 

Isn't this solvable at least for the case of truncating, Martin? It could do a tell(), seek to the start_pos, read and decode the bytes_to_feed, re-encode the chars_to_skip, seek back to the start_pos, write the encoded characters, and then truncate.

    >>> f = open('temp.txt', 'w+', encoding='utf-7')
    >>> f.write(b'+BDAEMQQyBDMENA-'.decode('utf-7'))
    5
    >>> _ = f.seek(0); f.read(2)
    '??'
    >>> cookie_bytes = f.tell().to_bytes(sizeof(Cookie), byteorder)
    >>> state = Cookie.from_buffer_copy(cookie_bytes)
    >>> f.buffer.seek(state.start_pos)
    0
    >>> buf = f.buffer.read(state.bytes_to_feed)
    >>> s = buf.decode(f.encoding)[:state.chars_to_skip]
    >>> f.buffer.seek(state.start_pos)
    0
    >>> f.buffer.write(s.encode(f.encoding))
    8
    >>> f.buffer.truncate()
    8
    >>> f.close()
    >>> open('temp.txt', encoding='utf-7').read()
    '??'

Rewriting the encoded bytes is necessary to properly terminate the UTF-7 sequence, which makes me doubt whether this simple approach will work for all codecs. But something like this is possible, no?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 22:04:51 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 20 Jan 2016 03:04:51 +0000
Subject: [docs] [issue26158] File truncate() not defaulting to current
 position as documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453259091.43.0.179773064756.issue26158@psf.upfronthosting.co.za>


Martin Panter added the comment:

Fornax: Yes, I was suggesting the idea of deprecating truncate() for text files! Although a blanket deprecation of all cases may not be realistic. Quickly reading the Stack Overflow pages, it seems like there is demand for this to work in some cases. Deprecating it in the more awkward situations, such as after after reading, and with specific kinds of codecs, might be an option though.

Now I think Issue 12215 (read then write) is more closely related to the read-then-truncate problem. For the write-then-read bug, it might be a separate problem with an easy fix: call flush() before changing to reader mode.

Eryk: If there is no decoder state, and the file data hasn?t changed, maybe it is solvable. But I realize now it won?t work in general. We would have to construct the encoder state from the decoder state. The same problem as Issue 12215.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 19 23:31:31 2016
From: report at bugs.python.org (random832)
Date: Wed, 20 Jan 2016 04:31:31 +0000
Subject: [docs] [issue26158] File truncate() not defaulting to current
 position as documented
In-Reply-To: <1453216784.99.0.234942868429.issue26158@psf.upfronthosting.co.za>
Message-ID: <1453264290.88.0.751417733021.issue26158@psf.upfronthosting.co.za>


random832 added the comment:

In the analogous C operations, ftell (analogous to .tell) actually causes the underlying file descriptor's position (analogous to the raw stream's position) to be reset to be at the same value that ftell has returned. Which means, yes, that you lose the benefits of buffering if you're so foolish as to call ftell after every read. But in this case the sequence "read / tell / truncate" would be analogous to "fread(f) / ftell(f) / ftruncate(fileno(f))

Though, the fact that fread operates on the FILE * whereas truncate operates on a file descriptor serves as a red flag to C programmers... arguably since this is not the case with Python, truncate on a buffered stream should implicitly include this same "reset underlying position" operation before actually performing the truncate.

----------
nosy: +random832

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 00:14:57 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Jan 2016 05:14:57 +0000
Subject: [docs] [issue26157] Typo in asyncio documentation
In-Reply-To: <1453216588.95.0.751274480755.issue26157@psf.upfronthosting.co.za>
Message-ID: <20160120051451.121304.84217@psf.io>


Roundup Robot added the comment:

New changeset 7415a9386048 by Berker Peksag in branch '3.5':
Issue #26157: Fix typos in asyncio-eventloop.rst
https://hg.python.org/cpython/rev/7415a9386048

New changeset 67f562cbd87b by Berker Peksag in branch 'default':
Issue #26157: Fix typos in asyncio-eventloop.rst
https://hg.python.org/cpython/rev/67f562cbd87b

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 00:17:36 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 20 Jan 2016 05:17:36 +0000
Subject: [docs] [issue26157] Typo in asyncio documentation
In-Reply-To: <1453216588.95.0.751274480755.issue26157@psf.upfronthosting.co.za>
Message-ID: <1453267056.01.0.314423563687.issue26157@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks! I noticed another typo in the same file and fixed it.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions:  -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 01:39:00 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 20 Jan 2016 06:39:00 +0000
Subject: [docs] [issue8519] doc: termios and ioctl reference links
In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za>
Message-ID: <1453271940.74.0.392971820614.issue8519@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

I followed the previous discussions and reviewed the patch. With respect to the patch, I see few drawbacks in providing links to references like this:

`fcntl `_
`ioctl `_
`the POSIX specification +`_

these URLs can quickly become outdated and it will be an unnecessary detail for us to maintain.

Instead, I suggest we have references like :manpage:`fcntl(2)`, :manpage:`ioctl(2)` and :manpage:`termios(2)`, a supported directive by sphinx, so that users can quickly search for those and land up on relevant and latest documentation.

----------
nosy: +orsenthil

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 01:46:01 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Jan 2016 06:46:01 +0000
Subject: [docs] [issue5626] misleading comment in socket.gethostname()
 documentation
In-Reply-To: <1238515382.33.0.784525971679.issue5626@psf.upfronthosting.co.za>
Message-ID: <20160120064558.25973.60550@psf.io>


Roundup Robot added the comment:

New changeset e1a711808cfe by Berker Peksag in branch '3.5':
Issue #5626: Remove misleading comment from socket.gethostname() documentation
https://hg.python.org/cpython/rev/e1a711808cfe

New changeset 689f881dd5d1 by Berker Peksag in branch 'default':
Issue #5626: Remove misleading comment from socket.gethostname() documentation
https://hg.python.org/cpython/rev/689f881dd5d1

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 01:46:38 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 20 Jan 2016 06:46:38 +0000
Subject: [docs] [issue5626] misleading comment in socket.gethostname()
 documentation
In-Reply-To: <1238515382.33.0.784525971679.issue5626@psf.upfronthosting.co.za>
Message-ID: <1453272398.17.0.889636582514.issue5626@psf.upfronthosting.co.za>


Changes by Berker Peksag :


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 02:02:32 2016
From: report at bugs.python.org (Kevin Norris)
Date: Wed, 20 Jan 2016 07:02:32 +0000
Subject: [docs] [issue26160] Tutorial incorrectly claims that (explicit)
 relative imports don't work in the main module
Message-ID: <1453273352.49.0.425335373136.issue26160@psf.upfronthosting.co.za>


New submission from Kevin Norris:

The tutorial contains this statement:

Note that relative imports are based on the name of the current module. Since the name of the main module is always "__main__", modules intended for use as the main module of a Python application must always use absolute imports.

See .  The wording is slightly different in the 2.7 version of the tutorial to account for the existence of implicit relative imports, but it clearly states that explicit relative imports suffer from this limitation.

As of PEP 366, this is no longer true.  You can do (explicit) relative imports in the main module just fine (though with some minor caveats w.r.t. using the -m flag vs. specifying the .py file directly).  PEP 366 has a Python-Version of 2.6, 3.0, so every sufficiently recent version of the tutorial is wrong.

It's probably not a good idea to get too far into those caveats in the tutorial.  I'd suggest wording like this:

Note that relative imports are based on the name of the current package.  If Python is invoked with the -m switch, it can determine the package name automatically, but if it is invoked directly as ``python file.py``, relative imports will not work because Python doesn't know what package file.py belongs to.

It might be worth mentioning __package__ here, too, but we don't want to get too far down the rabbit hole of trivia (e.g. PEP 366 discusses sys.path manipulation, and for that you probably want to use __file__ instead of hard-coding the path, and then you have to talk about zipimports, and then, and then, and then...!).

(For the record, is the 2.7 tutorial still under active support?  Is it okay to report bugs in it?)

----------
assignee: docs at python
components: Documentation
messages: 258650
nosy: Kevin.Norris, docs at python
priority: normal
severity: normal
status: open
title: Tutorial incorrectly claims that (explicit) relative imports don't work in the main module
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 02:27:02 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 20 Jan 2016 07:27:02 +0000
Subject: [docs] [issue19225] lack of PyExc_BufferError doc
In-Reply-To: <1381485777.95.0.364414099437.issue19225@psf.upfronthosting.co.za>
Message-ID: <1453274822.77.0.369882704873.issue19225@psf.upfronthosting.co.za>


Changes by Berker Peksag :


----------
keywords: +easy
stage:  -> needs patch
type: behavior -> enhancement
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 05:29:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 20 Jan 2016 10:29:46 +0000
Subject: [docs] [issue26160] Tutorial incorrectly claims that (explicit)
 relative imports don't work in the main module
In-Reply-To: <1453273352.49.0.425335373136.issue26160@psf.upfronthosting.co.za>
Message-ID: <1453285786.22.0.428021549097.issue26160@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yes 2.7 is open for changes to the documentation like this, as is 3.5+.

It?s been a while since I looked at the tutorial. Does it even mention the ?python -m? mode? I don?t think this is the right place to introduce it.

Perhaps it would be okay to just say relative imports are based on the _full_ name of the current module. It could be misleading saying ?the name of the current package?, because the import could be relative to the a higher level parent package if more than one dot is specified. Then point out that relative imports won?t work with ``python file.py`` or interactive mode, but don?t mention ?-m? (or the other ways to run scripts and modules).

----------
nosy: +martin.panter
versions:  -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 20 06:26:45 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 20 Jan 2016 11:26:45 +0000
Subject: [docs] [issue8519] doc: termios and ioctl reference links
In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za>
Message-ID: <1453289204.99.0.71599884431.issue8519@psf.upfronthosting.co.za>


Changes by Mark Lawrence :


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker 

_______________________________________

From keith.briggs at bt.com  Wed Jan 20 07:27:10 2016
From: keith.briggs at bt.com (keith.briggs at bt.com)
Date: Wed, 20 Jan 2016 12:27:10 +0000
Subject: [docs] doc bug at
 https://docs.python.org/3/library/zipfile.html#module-zipfile ?
Message-ID: <1453292876709.7837@bt.com>

This phrase doesn't make any sense:


> 'x' to exclusive create and write a new file


What was meant here?

Keith

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From report at bugs.python.org  Wed Jan 20 11:26:50 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 20 Jan 2016 16:26:50 +0000
Subject: [docs] [issue8519] doc: termios and ioctl reference links
In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za>
Message-ID: <1453307210.04.0.514565808439.issue8519@psf.upfronthosting.co.za>


Changes by Guido van Rossum :


----------
nosy:  -Guido.van.Rossum

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 00:48:23 2016
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 21 Jan 2016 05:48:23 +0000
Subject: [docs] [issue26172] iBook can't open ePub
Message-ID: <1453355303.75.0.605572221579.issue26172@psf.upfronthosting.co.za>


New submission from INADA Naoki:

Script cannot run in iBook is included in ePub.
Attached patch resolves the issue.

----------
assignee: docs at python
components: Documentation
files: epub.patch
keywords: patch
messages: 258734
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: iBook can't open ePub
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41678/epub.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 01:03:41 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Jan 2016 06:03:41 +0000
Subject: [docs] [issue26172] iBook can't open ePub
In-Reply-To: <1453355303.75.0.605572221579.issue26172@psf.upfronthosting.co.za>
Message-ID: <20160121060334.111052.53085@psf.io>


Roundup Robot added the comment:

New changeset 562179b7912f by Benjamin Peterson in branch '3.4':
remove script from epub (closes #26172)
https://hg.python.org/cpython/rev/562179b7912f

New changeset 56e68089ad65 by Benjamin Peterson in branch '3.5':
merge 3.4 (#26172)
https://hg.python.org/cpython/rev/56e68089ad65

New changeset 68ec50003aca by Benjamin Peterson in branch 'default':
merge 3.5 (#26172)
https://hg.python.org/cpython/rev/68ec50003aca

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From songofacandy at gmail.com  Thu Jan 21 01:12:06 2016
From: songofacandy at gmail.com (INADA Naoki)
Date: Thu, 21 Jan 2016 15:12:06 +0900
Subject: [docs] problem with epub
In-Reply-To: 
References: <064b01d13af2$78173ae0$6845b0a0$@gmail.com>
 
Message-ID: 

See http://bugs.python.org/issue26172

On Tue, Jan 19, 2016 at 2:11 AM, Senthil Kumaran 
wrote:

> I think, the epub generated by docs is simply broken. We have to file an
> issue and fix it.
> You could create a pdf and use that in your e-reader or convert pdf to
> epub using external software.
>
> --
> Senthil
>
>
> On Sat, Dec 19, 2015 at 10:48 PM, Gaston A. Giordana <
> gaston.giordana at gmail.com> wrote:
>
>> Dear all,
>>
>>
>>
>> I?m using the Windows version. I encountering problems to import the epub
>> file into my reader library. In fact, the reader does not recognise the
>> format. I do not know if the problem comes from the documentation or my
>> reader that does not support some formats. Which epub reader would you
>> recommend to use?
>>
>>
>>
>> Thanks in advance.
>>
>>
>>
>> Best regards,
>>
>>
>>
>> Gaston Giordana
>>
>> _______________________________________________
>> docs mailing list
>> docs at python.org
>> https://mail.python.org/mailman/listinfo/docs
>>
>>
>
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs
>
>


-- 
INADA Naoki  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From report at bugs.python.org  Thu Jan 21 02:58:55 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Jan 2016 07:58:55 +0000
Subject: [docs] [issue26106] Move licences to literal blocks
In-Reply-To: <1452726987.73.0.8328489013.issue26106@psf.upfronthosting.co.za>
Message-ID: <20160121075852.25900.79875@psf.io>


Roundup Robot added the comment:

New changeset a04d9589e2c4 by Victor Stinner in branch '3.5':
Issue #26106: doc: Move text of licenses to parsed literal block
https://hg.python.org/cpython/rev/a04d9589e2c4

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 03:05:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Jan 2016 08:05:00 +0000
Subject: [docs] [issue26106] Move licences to literal blocks
In-Reply-To: <1452726987.73.0.8328489013.issue26106@psf.upfronthosting.co.za>
Message-ID: <20160121080456.111038.3210@psf.io>


Roundup Robot added the comment:

New changeset f2a0a4a45292 by Victor Stinner in branch '2.7':
Issue #26106: doc: Move text of licenses to parsed literal block
https://hg.python.org/cpython/rev/f2a0a4a45292

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 03:08:58 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2016 08:08:58 +0000
Subject: [docs] [issue26106] Move licences to literal blocks
In-Reply-To: <1452726987.73.0.8328489013.issue26106@psf.upfronthosting.co.za>
Message-ID: <1453363738.04.0.388022816003.issue26106@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Thanks for your effort of translation the doc.

FYI the doc can be read at http://www.afpy.org/doc/python/ and the project (source) is at https://github.com/AFPY/python_doc_fr/

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 03:20:44 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2016 08:20:44 +0000
Subject: [docs] [issue25907] Documentation i18n: Added trans tags in sphinx
 templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1453364444.85.0.318584312142.issue25907@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The patch only changes Doc/tools/templates/indexcontent.html.

(Simplified) example of change on Doc/tools/templates/indexcontent.html:

   "
What's new in Python {{ version }}?
"

becomes

   "
{% trans %}What's new in Python {{ version }}?{% endtrans %}
"

I'm not a big fan of this option. Where does {% trans %}...{% endtrans %} format come from?

Is there an existing format to translate HTML templates?

I found html_translator_class config option in Sphinx:

http://www.sphinx-doc.org/en/stable/config.html?highlight=trans#confval-html_translator_class

Can't you avoid the new tags and use a small HTML parser to extract all strings?

----------
nosy: +ezio.melotti, haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 03:21:30 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2016 08:21:30 +0000
Subject: [docs] [issue26106] Move licences to literal blocks
In-Reply-To: <1452726987.73.0.8328489013.issue26106@psf.upfronthosting.co.za>
Message-ID: <1453364490.0.0.867469596768.issue26106@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 04:56:51 2016
From: report at bugs.python.org (Julien)
Date: Thu, 21 Jan 2016 09:56:51 +0000
Subject: [docs] [issue25907] Documentation i18n: Added trans tags in sphinx
 templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1453370211.72.0.568196619299.issue25907@psf.upfronthosting.co.za>


Julien added the comment:

@haypo I used the ``{trans}`` ``{endtrans}`` syntax because [Sphinx uses Jinja](http://www.sphinx-doc.org/en/stable/templating.html) and [``{trans}`` is the Jinja syntax for internationalisation](http://jinja.pocoo.org/docs/dev/templates/#i18n)

So ``{trans}`` is the standard syntax in this context and as you see I did not implemented a small script to parse them, Sphinx does it for me and add them in ``po`` files by itself, so Sphinx understand them, without need of some code.

It is possible to parse HTML to extract the strings to translate, but it would also fetch some false positives, and probably won't cut sentences at the right place, typically:

    
The Python Documentation


is easy to parse, extract the sentence, translate it, and, at compile-time, search and replace the sentence by its translation, nice.

    Here are more details about it.

Would be hard to parse: we'll need to introduce an heuristic to tell if we keep the HTML tag in the translation, or split it in three sentences "Here are", "more details", "about it". Sadly, splitting it in three sentences is not possible, because in some languages the order or those blocks may be swapped. So we need to get the  and  inside the sentence to allow translator to move the three part around freely.

Also, the Jinja xgettext parser handle variables inside translation, to start from a non-standard syntax ``{{ variable_name }}`` to a more standard one (normally ``%s`` so the string can be used on almost every languages, but here) ``%(variable)s``.

Those variables are obligatory, without them we'll get *code* inside translations strings, like ``pathto("whatsnew/index")``, which is even uglier than ``%(variable)s``.

Here it is:

     {% trans whatsnew_index=pathto("whatsnew/index") %}or all "What's new" documents since 2.0{% endtrans %}


Which yiels, in po files:

    "or all \"What's new\" documents since 2.0"

Which is better than:

    "or all \"What's new\" documents since 2.0"

Which itself is better (for the re-ordering problem in other languages) than:

    "or"
    "all \"What's new documents"
    "since 2.0"

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 05:05:18 2016
From: report at bugs.python.org (Julien)
Date: Thu, 21 Jan 2016 10:05:18 +0000
Subject: [docs] [issue25907] Documentation i18n: Added trans tags in sphinx
 templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1453370718.79.0.714552292507.issue25907@psf.upfronthosting.co.za>


Julien added the comment:

That's also the actual syntax used by existing Sphinx templates:

    mandark at windhowl$ grep -r '{% trans'  ~/.local/lib/python3.4/site-packages/sphinx_rtd_theme/
    footer.html:        {% trans path=pathto('copyright'), copyright=copyright|e %}© Copyright {{ copyright }}.{% endtrans %}
    footer.html:        {% trans copyright=copyright|e %}© Copyright {{ copyright }}.{% endtrans %}
    ...
    ...

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 05:19:23 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jan 2016 10:19:23 +0000
Subject: [docs] [issue25907] Documentation i18n: Added trans tags in sphinx
 templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1453371563.34.0.684296468662.issue25907@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> @haypo I used the ``{trans}`` ``{endtrans}`` syntax because [Sphinx uses Jinja](http://www.sphinx-doc.org/en/stable/templating.html) and [``{trans}`` is the Jinja syntax for internationalisation](http://jinja.pocoo.org/docs/dev/templates/#i18n)

Oh ok, fair enough :-)

Doc/tools/templates/ contains 3 HTML files, why not updating the 2 other HTML files?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 12:38:40 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Jan 2016 17:38:40 +0000
Subject: [docs] [issue25909] Incorrect documentation for PyMapping_Items and
 like
In-Reply-To: <1450525085.87.0.352365699992.issue25909@psf.upfronthosting.co.za>
Message-ID: <20160121173837.25906.36901@psf.io>


Roundup Robot added the comment:

New changeset e57949f5d0a9 by Senthil Kumaran in branch '3.5':
issue25909 - Correct the documentation of PyMapping_Items, PyMapping_Keys and
https://hg.python.org/cpython/rev/e57949f5d0a9

New changeset 739e1b0032c6 by Senthil Kumaran in branch 'default':
merge from 3.5
https://hg.python.org/cpython/rev/739e1b0032c6

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 12:41:42 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 21 Jan 2016 17:41:42 +0000
Subject: [docs] [issue25909] Incorrect documentation for PyMapping_Items and
 like
In-Reply-To: <1450525085.87.0.352365699992.issue25909@psf.upfronthosting.co.za>
Message-ID: <1453398102.42.0.154056563488.issue25909@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for the patch. I had to do some minor clarification like mention view types apply only to dict and also remove the sentence which mentioned those equivalent to list(o.values()) and list(o.items()) in the patch.

With those fixed, I have commited the change.

----------
assignee: docs at python -> orsenthil
nosy: +orsenthil
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 16:59:10 2016
From: report at bugs.python.org (=?utf-8?q?Gedai_Tam=C3=A1s_Bence?=)
Date: Thu, 21 Jan 2016 21:59:10 +0000
Subject: [docs] [issue19225] lack of PyExc_BufferError doc
In-Reply-To: <1381485777.95.0.364414099437.issue19225@psf.upfronthosting.co.za>
Message-ID: <1453413550.0.0.503017510621.issue19225@psf.upfronthosting.co.za>


Gedai Tam?s Bence added the comment:

Let me try to solve this issue. Will be back in 4 days.

----------
nosy: +beng94

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 17:00:04 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Jan 2016 22:00:04 +0000
Subject: [docs] [issue18620] multiprocessing page leaves out important part
 of Pool example
In-Reply-To: <1375389044.82.0.349700607179.issue18620@psf.upfronthosting.co.za>
Message-ID: <20160121220001.14177.82831@psf.io>


Roundup Robot added the comment:

New changeset c89f4f59872f by Berker Peksag in branch '3.5':
Issue #18620: Improve Pool examples in multiprocessing documentation
https://hg.python.org/cpython/rev/c89f4f59872f

New changeset 9f201578d8d9 by Berker Peksag in branch 'default':
Issue #18620: Improve Pool examples in multiprocessing documentation
https://hg.python.org/cpython/rev/9f201578d8d9

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 17:06:59 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Jan 2016 22:06:59 +0000
Subject: [docs] [issue18620] multiprocessing page leaves out important part
 of Pool example
In-Reply-To: <1375389044.82.0.349700607179.issue18620@psf.upfronthosting.co.za>
Message-ID: <20160121220654.41340.83184@psf.io>


Roundup Robot added the comment:

New changeset 9480e217ade0 by Berker Peksag in branch '2.7':
Issue #18620: Improve Pool examples in multiprocessing documentation
https://hg.python.org/cpython/rev/9480e217ade0

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 17:08:59 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 21 Jan 2016 22:08:59 +0000
Subject: [docs] [issue18620] multiprocessing page leaves out important part
 of Pool example
In-Reply-To: <1375389044.82.0.349700607179.issue18620@psf.upfronthosting.co.za>
Message-ID: <1453414138.96.0.916690903295.issue18620@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Davin. I tweaked code style a bit and removed trailing whitespaces.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 21 20:58:36 2016
From: report at bugs.python.org (Srujan Chaitanya)
Date: Fri, 22 Jan 2016 01:58:36 +0000
Subject: [docs] [issue26176] EmailMessage example doesn't work
Message-ID: <1453427916.73.0.91814079944.issue26176@psf.upfronthosting.co.za>


New submission from Srujan Chaitanya:

Example provided in 19.1.14.1. Examples using the Provisional API
at https://docs.python.org/3.4/library/email-examples.html?highlight=email%20example

Doesn't work. This could be a EmailMessage class issue also?

----------
assignee: docs at python
components: Documentation
messages: 258781
nosy: Srujan Chaitanya, docs at python
priority: normal
severity: normal
status: open
title: EmailMessage example doesn't work
type: behavior
versions: Python 3.4

_______________________________________
Python tracker 

_______________________________________

From senthil at uthcode.com  Thu Jan 21 23:46:31 2016
From: senthil at uthcode.com (Senthil Kumaran)
Date: Thu, 21 Jan 2016 20:46:31 -0800
Subject: [docs] doc bug at
 https://docs.python.org/3/library/zipfile.html#module-zipfile ?
In-Reply-To: <1453292876709.7837@bt.com>
References: <1453292876709.7837@bt.com>
Message-ID: 

On Wed, Jan 20, 2016 at 4:27 AM,  wrote:

> > 'x' to exclusive create and write a new file


It means always create  a new file. Don't append and if the file exists,
don't overwrite, but throw a FileExistsError Exception.

I think, it could be clarified a bit. It could be stated as "Exclusively
create and write a new file. Unlike 'w', if the file already exists, 'x'
mode will raise a FileExistsError exception."

-- 
Senthil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From report at bugs.python.org  Fri Jan 22 08:04:43 2016
From: report at bugs.python.org (=?utf-8?q?Gedai_Tam=C3=A1s_Bence?=)
Date: Fri, 22 Jan 2016 13:04:43 +0000
Subject: [docs] [issue19225] lack of PyExc_BufferError doc
In-Reply-To: <1381485777.95.0.364414099437.issue19225@psf.upfronthosting.co.za>
Message-ID: <1453467883.75.0.0394457131567.issue19225@psf.upfronthosting.co.za>


Gedai Tam?s Bence added the comment:

I've created a new table for warnings and added the missing exceptions to the exceptions table.

I did not find a link for VMSError, but I added it to the table.

Note that the exceptions table is not absolutely in alphabetical order, I can fix it as well, if it's needed.

----------
keywords: +patch
Added file: http://bugs.python.org/file41688/doc_exceptions.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 11:27:42 2016
From: report at bugs.python.org (=?utf-8?q?Gedai_Tam=C3=A1s_Bence?=)
Date: Fri, 22 Jan 2016 16:27:42 +0000
Subject: [docs] [issue21949] Document the Py_SIZE() macro.
In-Reply-To: <1404935084.68.0.420259951718.issue21949@psf.upfronthosting.co.za>
Message-ID: <1453480062.66.0.526994007171.issue21949@psf.upfronthosting.co.za>


Gedai Tam?s Bence added the comment:

Py_SIZE: https://docs.python.org/3.5/c-api/structures.html#c.Py_SIZE
PyList_New: https://docs.python.org/3.5/c-api/list.html#c.PyList_New

I think they're documented now, so I guess the issue can be closed.

----------
nosy: +beng94

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 11:43:52 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 22 Jan 2016 16:43:52 +0000
Subject: [docs] [issue21949] Document the Py_SIZE() macro.
In-Reply-To: <1404935084.68.0.420259951718.issue21949@psf.upfronthosting.co.za>
Message-ID: <1453481032.16.0.953542325.issue21949@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for triaging! The relevant commit is 760c5cfacbaa.

----------
nosy: +berker.peksag
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 11:47:21 2016
From: report at bugs.python.org (Julien)
Date: Fri, 22 Jan 2016 16:47:21 +0000
Subject: [docs] [issue25907] Documentation i18n: Added trans tags in sphinx
 templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1453481241.74.0.266807580335.issue25907@psf.upfronthosting.co.za>


Julien added the comment:

And here are the i18n tags for the sidebar, thanks @haypo it was a good idea to translate them too ^-^

----------
Added file: http://bugs.python.org/file41693/i18n-tags-in-sidebar.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 11:47:50 2016
From: report at bugs.python.org (Julien)
Date: Fri, 22 Jan 2016 16:47:50 +0000
Subject: [docs] [issue25907] Documentation i18n: Added trans tags in sphinx
 templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1453481270.29.0.324929112409.issue25907@psf.upfronthosting.co.za>


Julien added the comment:

And tags for the layout template.

----------
Added file: http://bugs.python.org/file41694/i18n-tags-in-layout.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 12:01:04 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Jan 2016 17:01:04 +0000
Subject: [docs] [issue25907] Documentation i18n: Added trans tags in sphinx
 templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <20160122170055.7348.87932@psf.io>


Roundup Robot added the comment:

New changeset b1615165fa4a by Victor Stinner in branch '3.5':
doc: i18n HTML templates
https://hg.python.org/cpython/rev/b1615165fa4a

New changeset 5af5b36c197e by Victor Stinner in branch 'default':
Merge 3.5 (i18n doc, issue #25907)
https://hg.python.org/cpython/rev/5af5b36c197e

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 12:02:17 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jan 2016 17:02:17 +0000
Subject: [docs] [issue25907] Documentation i18n: Added trans tags in sphinx
 templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1453482137.82.0.552521111199.issue25907@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I applied 3 patches to branches 3.5 and default (3.6), but the patches don't apply cleanly to Python 2.7.

Can you please cook patches for Python 2.7?

(I suggest to focus on translation of the Python 3 documentation, but for me, it's cheap to apply such patch to Python 2.7.)

----------
versions: +Python 2.7, Python 3.5, Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 16:18:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Jan 2016 21:18:00 +0000
Subject: [docs] [issue21949] Document the Py_SIZE() macro.
In-Reply-To: <1404935084.68.0.420259951718.issue21949@psf.upfronthosting.co.za>
Message-ID: <20160122211755.3708.93042@psf.io>


Roundup Robot added the comment:

New changeset 63183596db79 by Gregory P. Smith in branch '2.7':
Per issue21949 and issue1629: Document the Py_SIZE, Py_TYPE, Py_REFCNT macros.
https://hg.python.org/cpython/rev/63183596db79

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 16:18:29 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 22 Jan 2016 21:18:29 +0000
Subject: [docs] [issue21949] Document the Py_SIZE() macro.
In-Reply-To: <1404935084.68.0.420259951718.issue21949@psf.upfronthosting.co.za>
Message-ID: <1453497509.08.0.926221495256.issue21949@psf.upfronthosting.co.za>


Changes by Gregory P. Smith :


----------
resolution: out of date -> fixed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 18:30:38 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Jan 2016 23:30:38 +0000
Subject: [docs] [issue26095] Update porting HOWTO to special-case Python 2
 code, not Python 3
In-Reply-To: <1452651397.71.0.110404454924.issue26095@psf.upfronthosting.co.za>
Message-ID: <1453505438.84.0.121428764802.issue26095@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
assignee: docs at python -> brett.cannon

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 22 19:12:31 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Jan 2016 00:12:31 +0000
Subject: [docs] [issue26149] Suggest PyCharm Community as an editor for Unix
 platforms
In-Reply-To: <1453153728.95.0.733172914649.issue26149@psf.upfronthosting.co.za>
Message-ID: <1453507951.11.0.731632229294.issue26149@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Berker, I agree with you.  The doc section is woefully incomplete and unix-specific.  It probably dates back to when Python only ran on unix.

----------
nosy: +terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 03:17:37 2016
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Jan 2016 08:17:37 +0000
Subject: [docs] [issue26149] Suggest PyCharm Community as an editor for Unix
 platforms
In-Reply-To: <1453153728.95.0.733172914649.issue26149@psf.upfronthosting.co.za>
Message-ID: <1453537056.99.0.786529222958.issue26149@psf.upfronthosting.co.za>


Georg Brandl added the comment:

> The doc section is woefully incomplete and unix-specific.

That might be because the doc section is called "Using Python on Unix platforms".

----------
nosy: +georg.brandl

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 03:27:34 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Jan 2016 08:27:34 +0000
Subject: [docs] [issue26149] Suggest PyCharm Community as an editor for Unix
 platforms
In-Reply-To: <1453153728.95.0.733172914649.issue26149@psf.upfronthosting.co.za>
Message-ID: <1453537654.75.0.163669200338.issue26149@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The two links for VIM and Emacs are useful for Unix developers that happen to use these editors, but I agree that we should link to the wiki instead of having other links to specific editors.
If we want to recommend a few specific ones, we could list their names so that people can find them in the wiki.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 05:00:11 2016
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 23 Jan 2016 10:00:11 +0000
Subject: [docs] [issue25907] Documentation i18n: Added trans tags in sphinx
 templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1453543211.05.0.542453998702.issue25907@psf.upfronthosting.co.za>


INADA Naoki added the comment:

O/T

Hi, Julien.

I'm maintainer of Python Document Japanese translation project.  (http://docs.python.jp/ )
We use Transifex to ease many volunteers working on translating.

https://www.transifex.com/python-doc-ja/python-35/dashboard/

Repository of Python 3.5 Japanese document is here: https://github.com/python-doc-ja/cpython-doc-intl

----------
nosy: +naoki

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 06:12:00 2016
From: report at bugs.python.org (Julien)
Date: Sat, 23 Jan 2016 11:12:00 +0000
Subject: [docs] [issue25907] Documentation i18n: Added trans tags in sphinx
 templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1453547520.32.0.709479142127.issue25907@psf.upfronthosting.co.za>


Julien added the comment:

@haypo: And here is the patch for 2.7, and here is the result of the patch applied and new msgids translated: http://www.afpy.org/doc/python/2.7/

----------
Added file: http://bugs.python.org/file41699/trans-tags-in-2.7.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 06:23:31 2016
From: report at bugs.python.org (Julien)
Date: Sat, 23 Jan 2016 11:23:31 +0000
Subject: [docs] [issue25907] Documentation i18n: Added trans tags in sphinx
 templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1453548211.03.0.6084600295.issue25907@psf.upfronthosting.co.za>


Julien added the comment:

@naoki Not sure, but with those patches you'll may be able to translate the documentation without forking it. Like we're doing here: https://github.com/afpy/python_doc_fr

Also did you contacted the upstream to ask them if they want to cross-link your versions ? Sphinx don't natively support it, but it still doable and can be a nice way to advertise our efforts (I mean, I'm sure a lot of french people don't know we're doing it and stuck to the english version).

I heard we used transfiex too like 6 years ago, long before me being on the project, I may drop an eye on it, thanks.

It may be a bit out of the scope of this issue, so let's continue elsewhere, like by email if you want I'm julien at palard dot fr.

BTW, nice to hear we're not alone to translate the Python doc :-))).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 06:55:34 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Jan 2016 11:55:34 +0000
Subject: [docs] [issue25907] Documentation i18n: Added trans tags in sphinx
 templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <20160123115531.65051.40042@psf.io>


Roundup Robot added the comment:

New changeset 72edb81e456b by Victor Stinner in branch '2.7':
doc: i18n HTML templates
https://hg.python.org/cpython/rev/72edb81e456b

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 23 06:57:15 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Jan 2016 11:57:15 +0000
Subject: [docs] [issue25907] Documentation i18n: Added trans tags in sphinx
 templates
In-Reply-To: <1450456235.45.0.408573494248.issue25907@psf.upfronthosting.co.za>
Message-ID: <1453550235.69.0.440513344734.issue25907@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> @haypo: And here is the patch for 2.7, and here is the result of the patch applied and new msgids translated: http://www.afpy.org/doc/python/2.7/

Thanks. I also pushed this change.

@INADA Naoki, @Julien: Don't hesitate to bug me if you want to push other changes to make your work easier.

----------

_______________________________________
Python tracker 

_______________________________________

From michaelgofron2017 at u.northwestern.edu  Thu Jan 21 17:41:46 2016
From: michaelgofron2017 at u.northwestern.edu (Michael Gofron)
Date: Thu, 21 Jan 2016 16:41:46 -0600
Subject: [docs] colorsys module
Message-ID: <91B2BE9F-22D4-4D48-8AC6-71B199A9012B@u.northwestern.edu>

Hello,

The colorizes module appears to give a division by zero error when given the input (1, 2, 0). I believe providing some kind of default value spitted out in this case rather than causing an exception to be bubbled up or properly documenting that it causes an exception to be raised in some cases would be better.

-Thank you
Michael Gofron

From mike at scalora.org  Fri Jan 22 07:11:49 2016
From: mike at scalora.org (Mike Scalora)
Date: Fri, 22 Jan 2016 05:11:49 -0700
Subject: [docs] Typo in documentation
Message-ID: 

On https://docs.python.org/2/library/test.html

    This function will raise unittest.SkipTest
 *is*
the named module cannot be imported.
should be:

    This function will raise unittest.SkipTest
 *if*
the named module cannot be imported.
-Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From tyler.arbour at berkeley.edu  Fri Jan 22 10:27:23 2016
From: tyler.arbour at berkeley.edu (Tyler Arbour)
Date: Fri, 22 Jan 2016 07:27:23 -0800
Subject: [docs] Mistake in random.py documentation?
Message-ID: <69B55863-4D9A-4AC5-89F0-A12786D51317@berkeley.edu>

Hi,

I?m reporting what I think might be a mistake for the documentation of random.py. Sorry that I am short on time and have never reported a bug (new user), so apologies if the Tracker is the preferred way.

Reading the stuff below, it is unclear whether randrange(0, 5) includes 5 in the set it?s choosing integers from. Furthermore, randint(0, 5) explicitly says ?alias for randrange(a, b+1) which to me suggests randint includes the ?stop? integer and randrange does not.

I tested both (see screenshot) and see that neither consider 5 in the set. This seems wrong to me. I?m curious to know though, so I?d love a response if at all possible.

Thanks!
Tyler


##########################################
(From the docs:)
Functions for integers:

random.randrange(stop) 
random.randrange(start, stop[, step])
Return a randomly selected element from range(start, stop, step). This is equivalent to choice(range(start, stop, step)), but doesn?t actually build a range object.

The positional argument pattern matches that of range() . Keyword arguments should not be used because the function may use them in unexpected ways.

Changed in version 3.2: randrange()  is more sophisticated about producing equally distributed values. Formerly it used a style like int(random()*n) which could produce slightly uneven distributions.

random.randint(a, b) 
Return a random integer N such that a <= N <= b. Alias for randrange(a, b+1).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2016-01-22 at 7.17.33 AM.png
Type: image/png
Size: 95439 bytes
Desc: not available
URL: 

From encukou at gmail.com  Sat Jan 23 15:33:28 2016
From: encukou at gmail.com (Petr Viktorin)
Date: Sat, 23 Jan 2016 21:33:28 +0100
Subject: [docs] Mistake in random.py documentation?
In-Reply-To: <69B55863-4D9A-4AC5-89F0-A12786D51317@berkeley.edu>
References: <69B55863-4D9A-4AC5-89F0-A12786D51317@berkeley.edu>
Message-ID: <56A3E398.3040404@gmail.com>

On 01/22/2016 04:27 PM, Tyler Arbour wrote:
> Hi,
> 
> I?m reporting what I /think/ might be a mistake for the documentation of
> random.py. Sorry that I am short on time and have never reported a bug
> (new user), so apologies if the Tracker is the preferred way.

Indeed, the tracker is the preferred way; e-mails tend to get forgotten
if no one gets to them soon enough.

> Reading the stuff below, it is unclear whether *randrange(0,
> 5)* includes 5 in the set it?s choosing integers from.

It does link to `range`, where the docs are a bit more specific ? though
maybe too technical. The best place to learn about range is the
tutorial, which does say "The given end point is never part of the
generated sequence":
https://docs.python.org/3/tutorial/controlflow.html#the-range-function

> Furthermore, *randint(0, 5)* explicitly says ?alias for randrange(a,
> b+1) which to me suggests *randint* /includes/ the ?stop? integer and
> *randrange* does not.
> 
> I tested both (*/see screenshot/*) and see that neither consider 5 in
> the set. This seems wrong to me. I?m curious to know though, so I?d love
> a response if at all possible.

You forgot to change "randrange" to "randint" in your second test. With
the change, it should work as expected. (I'm using lists as I don't have
Numpy handy right now):

>>> import random
>>> [random.randrange(0, 5) for i in range(100)]
[0, 0, 0, 4, 2, 2, 2, 4, 0, 4, 1, 4, 1, 0, 3, 1, 0, 4, 0, 1, 2, 2, 3, 0,
1, 4, 2, 0, 0, 0, 2, 0, 2, 4, 0, 0, 2, 0, 2, 1, 3, 4, 0, 4, 1, 1, 2, 3,
3, 4, 3, 2, 0, 3, 4, 0, 2, 3, 2, 3, 1, 4, 0, 2, 3, 4, 3, 0, 0, 0, 1, 1,
1, 2, 1, 3, 0, 3, 3, 4, 0, 0, 2, 3, 0, 2, 0, 3, 3, 1, 0, 4, 2, 3, 4, 1,
1, 1, 3, 0]
>>> [random.randint(0, 5) for i in range(100)]
[0, 2, 3, 2, 1, 5, 2, 0, 4, 5, 2, 1, 0, 1, 4, 4, 4, 0, 3, 0, 3, 0, 3, 0,
1, 2, 4, 3, 5, 2, 4, 2, 5, 2, 3, 3, 3, 0, 2, 4, 0, 1, 5, 0, 4, 0, 5, 0,
3, 3, 3, 1, 4, 1, 0, 3, 4, 0, 1, 5, 2, 4, 0, 0, 2, 1, 1, 1, 5, 0, 2, 4,
5, 5, 2, 4, 5, 1, 1, 2, 3, 1, 3, 4, 1, 3, 4, 4, 3, 2, 3, 0, 1, 1, 1, 4,
4, 4, 3, 5]
>>>


Thanks for taking the time to write, though! It was an easy mistake to
make, so don't let it discourage you from reporting any future bugs you
might spot ? after you double-check, of course.


From report at bugs.python.org  Sat Jan 23 19:45:27 2016
From: report at bugs.python.org (Kevin Norris)
Date: Sun, 24 Jan 2016 00:45:27 +0000
Subject: [docs] [issue26160] Tutorial incorrectly claims that (explicit)
 relative imports don't work in the main module
In-Reply-To: <1453273352.49.0.425335373136.issue26160@psf.upfronthosting.co.za>
Message-ID: <1453596327.77.0.270797600669.issue26160@psf.upfronthosting.co.za>


Kevin Norris added the comment:

>It could be misleading saying ?the name of the current package?, because the import could be relative to the a higher level parent package if more than one dot is specified.

While this is correct, Python still uses __package__ to determine what to import in that case.  I simply replaced "__package__" with "the name of the current package" to make it easier to read, much as the original text replaces "__name__" with "the name of the current module."

>Then point out that relative imports won?t work with ``python file.py`` or interactive mode, but don?t mention ?-m? (or the other ways to run scripts and modules).

SGTM if you can find a reasonable way of phrasing that.

----------

_______________________________________
Python tracker 

_______________________________________

From tyler.arbour at berkeley.edu  Sat Jan 23 21:45:30 2016
From: tyler.arbour at berkeley.edu (Tyler J. Arbour)
Date: Sat, 23 Jan 2016 18:45:30 -0800
Subject: [docs] Mistake in random.py documentation?
In-Reply-To: <56A3E398.3040404@gmail.com>
References: <69B55863-4D9A-4AC5-89F0-A12786D51317@berkeley.edu>
 <56A3E398.3040404@gmail.com>
Message-ID: 

Thanks so much for the reply! Sorry for the mistake on my part.

Cheers,
Tyler

On Saturday, January 23, 2016, Petr Viktorin  wrote:

> On 01/22/2016 04:27 PM, Tyler Arbour wrote:
> > Hi,
> >
> > I?m reporting what I /think/ might be a mistake for the documentation of
> > random.py. Sorry that I am short on time and have never reported a bug
> > (new user), so apologies if the Tracker is the preferred way.
>
> Indeed, the tracker is the preferred way; e-mails tend to get forgotten
> if no one gets to them soon enough.
>
> > Reading the stuff below, it is unclear whether *randrange(0,
> > 5)* includes 5 in the set it?s choosing integers from.
>
> It does link to `range`, where the docs are a bit more specific ? though
> maybe too technical. The best place to learn about range is the
> tutorial, which does say "The given end point is never part of the
> generated sequence":
> https://docs.python.org/3/tutorial/controlflow.html#the-range-function
>
> > Furthermore, *randint(0, 5)* explicitly says ?alias for randrange(a,
> > b+1) which to me suggests *randint* /includes/ the ?stop? integer and
> > *randrange* does not.
> >
> > I tested both (*/see screenshot/*) and see that neither consider 5 in
> > the set. This seems wrong to me. I?m curious to know though, so I?d love
> > a response if at all possible.
>
> You forgot to change "randrange" to "randint" in your second test. With
> the change, it should work as expected. (I'm using lists as I don't have
> Numpy handy right now):
>
> >>> import random
> >>> [random.randrange(0, 5) for i in range(100)]
> [0, 0, 0, 4, 2, 2, 2, 4, 0, 4, 1, 4, 1, 0, 3, 1, 0, 4, 0, 1, 2, 2, 3, 0,
> 1, 4, 2, 0, 0, 0, 2, 0, 2, 4, 0, 0, 2, 0, 2, 1, 3, 4, 0, 4, 1, 1, 2, 3,
> 3, 4, 3, 2, 0, 3, 4, 0, 2, 3, 2, 3, 1, 4, 0, 2, 3, 4, 3, 0, 0, 0, 1, 1,
> 1, 2, 1, 3, 0, 3, 3, 4, 0, 0, 2, 3, 0, 2, 0, 3, 3, 1, 0, 4, 2, 3, 4, 1,
> 1, 1, 3, 0]
> >>> [random.randint(0, 5) for i in range(100)]
> [0, 2, 3, 2, 1, 5, 2, 0, 4, 5, 2, 1, 0, 1, 4, 4, 4, 0, 3, 0, 3, 0, 3, 0,
> 1, 2, 4, 3, 5, 2, 4, 2, 5, 2, 3, 3, 3, 0, 2, 4, 0, 1, 5, 0, 4, 0, 5, 0,
> 3, 3, 3, 1, 4, 1, 0, 3, 4, 0, 1, 5, 2, 4, 0, 0, 2, 1, 1, 1, 5, 0, 2, 4,
> 5, 5, 2, 4, 5, 1, 1, 2, 3, 1, 3, 4, 1, 3, 4, 4, 3, 2, 3, 0, 1, 1, 1, 4,
> 4, 4, 3, 5]
> >>>
>
>
> Thanks for taking the time to write, though! It was an easy mistake to
> make, so don't let it discourage you from reporting any future bugs you
> might spot ? after you double-check, of course.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From report at bugs.python.org  Sun Jan 24 18:35:57 2016
From: report at bugs.python.org (Katie McLaughlin)
Date: Sun, 24 Jan 2016 23:35:57 +0000
Subject: [docs] [issue25296] Simple End-of-life guide covering all
 unsupported versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1453678556.84.0.20600047667.issue25296@psf.upfronthosting.co.za>


Katie McLaughlin added the comment:

Hello!

I recently saw an announcement[0] about the adding of the lifecycle status right at the top of the devguide[1]. I believe this was added as part of Issue 26165[2]

Given this, can this issue be marked as Resolved?

0 - https://twitter.com/gvanrossum/status/690227337015590912
1 - https://docs.python.org/devguide/#status-of-python-branches
2 - https://bugs.python.org/issue26165

----------
nosy: +Katie McLaughlin

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 24 20:55:22 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 25 Jan 2016 01:55:22 +0000
Subject: [docs] [issue25296] Simple End-of-life guide covering all
 unsupported versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1453686922.11.0.392003015898.issue25296@psf.upfronthosting.co.za>


Changes by Berker Peksag :


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From berker.peksag at gmail.com  Mon Jan 25 01:26:19 2016
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Mon, 25 Jan 2016 08:26:19 +0200
Subject: [docs] Typo in documentation
In-Reply-To: 
References: 
Message-ID: 

On Fri, Jan 22, 2016 at 2:11 PM, Mike Scalora  wrote:
> On https://docs.python.org/2/library/test.html
>
>     This function will raise unittest.SkipTest is the named module cannot be
> imported.
>
> should be:
>
>     This function will raise unittest.SkipTest if the named module cannot be
> imported.

Hi Mike,

Thanks for your email. I've fixed it in
https://hg.python.org/cpython/rev/18c5c68b6075

--Berker

From report at bugs.python.org  Mon Jan 25 11:13:08 2016
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Mon, 25 Jan 2016 16:13:08 +0000
Subject: [docs] [issue26198] PyArg_ParseTuple with format "et#" and "es#"
 detects overflow by raising TypeError instead of ValueError
Message-ID: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>


New submission from Hrvoje Nik?i?:

The documentation for the "es#" format (and the "et#" that derives from it) documents the possibility of providing an already allocated buffer. Buffer overflow is detected and handled as follows: "If the buffer is not large enough, a ValueError will be set."

However, the actual behavior is to raise a TypeError. Inspecting the code in getargs.c reveals that convertsimple() handles buffer overflow by returning a formatted message to its caller, convertitem(). Calls to convertitem() that return an error call seterror() to set the error, and seterror() unconditionally sets the PyExc_TypeError.

This is not a big issue in practice, and since the behavior is not new, it might be best to simply update the documentation to match the existing practice instead of changing the behavior and risking breaking working code.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 258905
nosy: docs at python, hniksic
priority: normal
severity: normal
status: open
title: PyArg_ParseTuple with format "et#" and "es#" detects overflow by raising TypeError instead of ValueError
type: behavior
versions: Python 2.7, Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 11:20:52 2016
From: report at bugs.python.org (Raphael Das Gupta)
Date: Mon, 25 Jan 2016 16:20:52 +0000
Subject: [docs] [issue26199] fix broken link to
 hamcrest.library.integration.match_equality in unittest.mock "getting
 started" documentation
Message-ID: <1453738852.52.0.691213360087.issue26199@psf.upfronthosting.co.za>


New submission from Raphael Das Gupta:

On

* https://docs.python.org/3.3/library/unittest.mock-examples.html#more-complex-argument-matching
* https://docs.python.org/3.4/library/unittest.mock-examples.html#more-complex-argument-matching
* https://docs.python.org/3.5/library/unittest.mock-examples.html#more-complex-argument-matching
* https://docs.python.org/3.6/library/unittest.mock-examples.html#more-complex-argument-matching

the link to hamcrest.library.integration.match_equality documentation at the very end of the page is broken.

(Earlier versions didn't have this documentation page.)

----------
assignee: docs at python
components: Documentation
hgrepos: 332
messages: 258906
nosy: das-g, docs at python
priority: normal
severity: normal
status: open
title: fix broken link to hamcrest.library.integration.match_equality in unittest.mock "getting started" documentation
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 11:24:48 2016
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Mon, 25 Jan 2016 16:24:48 +0000
Subject: [docs] [issue26198] PyArg_ParseTuple with format "et#" and "es#"
 detects overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <1453739088.32.0.119323532622.issue26198@psf.upfronthosting.co.za>


Hrvoje Nik?i? added the comment:

The problem can be encountered and easily reproduced by calling os.path functions, such as os.path.abspath, with a sufficiently large string on Windows:

>>> os.path.abspath("a" * 1024)
Traceback (most recent call last):
  File "", line 1, in 
  File "P:\...\lib\ntpath.py", line 471, in abspath
TypeError: must be (buffer overflow), not str

The error message is somewhat confusing, making it look like the "must be" and "not" arguments are swapped. Ideally, the message could be along the lines of "must be a string of no more than X characters".

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 11:42:31 2016
From: report at bugs.python.org (Raphael Das Gupta)
Date: Mon, 25 Jan 2016 16:42:31 +0000
Subject: [docs] [issue26199] fix broken link to
 hamcrest.library.integration.match_equality in unittest.mock "getting
 started" documentation
In-Reply-To: <1453738852.52.0.691213360087.issue26199@psf.upfronthosting.co.za>
Message-ID: <1453740150.74.0.751369932793.issue26199@psf.upfronthosting.co.za>


Changes by Raphael Das Gupta :


----------
keywords: +patch
Added file: http://bugs.python.org/file41709/0d413f60cc23.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 11:56:06 2016
From: report at bugs.python.org (Raphael Das Gupta)
Date: Mon, 25 Jan 2016 16:56:06 +0000
Subject: [docs] [issue26199] fix broken link to
 hamcrest.library.integration.match_equality in unittest.mock "getting
 started" documentation
In-Reply-To: <1453738852.52.0.691213360087.issue26199@psf.upfronthosting.co.za>
Message-ID: <1453740966.37.0.455161397933.issue26199@psf.upfronthosting.co.za>


Raphael Das Gupta added the comment:

0d413f60cc23.diff generated with the 'Create Patch' button of this bug tracker is crap. (I guess it's a diff of upstream's tip to my repo's tip, thus reverting all changes of upstream that this daggy fix isn't based on.)

Use fix-broken-link-to-pyhamcrest-match_equality.diff instead. (Created with hg export.)

----------
Added file: http://bugs.python.org/file41711/fix-broken-link-to-pyhamcrest-match_equality.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 13:10:19 2016
From: report at bugs.python.org (Barun Parruck)
Date: Mon, 25 Jan 2016 18:10:19 +0000
Subject: [docs] [issue26198] PyArg_ParseTuple with format "et#" and "es#"
 detects overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <1453745419.87.0.139232073712.issue26198@psf.upfronthosting.co.za>


Barun Parruck added the comment:

I just changed the ValueError to TypeError. This is my first attempt at fixing anything, so let me know if I've screwed up anywhere.

----------
keywords: +patch
nosy: +Barun Parruck
Added file: http://bugs.python.org/file41712/typeerror.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 14:05:45 2016
From: report at bugs.python.org (Barun Parruck)
Date: Mon, 25 Jan 2016 19:05:45 +0000
Subject: [docs] [issue26198] PyArg_ParseTuple with format "et#" and "es#"
 detects overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <1453748745.86.0.0822819679579.issue26198@psf.upfronthosting.co.za>


Barun Parruck added the comment:

Added a patch that changes the documentation to reflect TypeError instead of ValueError*

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jan 25 21:16:27 2016
From: report at bugs.python.org (Roscoe R.Higgins)
Date: Tue, 26 Jan 2016 02:16:27 +0000
Subject: [docs] [issue26205] Inconsistency concerning nested scopes
Message-ID: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>


New submission from Roscoe R.Higgins:

In chapter 9. Classes of the Python3.5 documentation it says: 

"At any time during execution, there are at least three nested scopes whose namespaces are directly accessible:",

followed by a list containing 4 items.
Further down a middle scope is mentioned (although mentioned by name). This was confusing for a while.

----------
assignee: docs at python
components: Documentation
messages: 258941
nosy: Roscoe R. Higgins, docs at python
priority: normal
severity: normal
status: open
title: Inconsistency concerning nested scopes
type: behavior
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From chinaxun827 at 163.com  Mon Jan 25 10:10:08 2016
From: chinaxun827 at 163.com (chinaxun827)
Date: Mon, 25 Jan 2016 23:10:08 +0800 (CST)
Subject: [docs] 21.21.4.1. socketserver.TCPServer
Message-ID: <1cc9155c.c6e3.1527955c042.Coremail.chinaxun827@163.com>

importsocketserverclassMyTCPHandler(socketserver.BaseRequestHandler):"""    The RequestHandler class for our server.    It is instantiated once per connection to the server, and must    override the handle() method to implement communication to the    client.    """defhandle(self):# self.request is the TCP socket connected to the clientself.data=self.request.recv(1024).strip()https://docs.python.org/3.4/library/socketserver.html


Excuse me.


 I have not found the request method in socketserver.BaseRequestHandler or socketserver.BaseRequestHandler.handle
by <.__dict__>


I don't know how this example worked. Maybe this is just a "hidden" usage?


Is there a way to look up every attributes and methods of a class or a method? Please tell me if you know how to.


    Thanks in advance.


            George, Yan





-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From report at bugs.python.org  Tue Jan 26 09:08:31 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Jan 2016 14:08:31 +0000
Subject: [docs] [issue26198] PyArg_ParseTuple with format "et#" and "es#"
 detects overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <1453817310.99.0.912695925173.issue26198@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patch fixes minor bugs in Python/getargs.c:

1. Replaces TypeError with confusing error message for buffer overflow for "es#" and "et#" format units to ValueError with correct error message. Due to the risk to break working code, may be we will left TypeError in maintained releases, but error message should be fixed in any case.

2. Replaces all other TypeError with confusing error message to SystemError with correct error message. All this errors are programming errors (incorrect use of PyArg_Parse* functions) and aren't occurred in valid extensions.

3. Fixes error messages for "k" and "K" format units.

4. Fixes error messages for "es" and "et" format units.

5. Fixes error messages for "compat" mode (looks as this mode is not used and can be freely removed in Python 3).

----------
assignee: docs at python -> serhiy.storchaka
nosy: +serhiy.storchaka
stage:  -> patch review
versions: +Python 3.6
Added file: http://bugs.python.org/file41720/pyarg_parse_encoded_string.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 09:29:23 2016
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Tue, 26 Jan 2016 14:29:23 +0000
Subject: [docs] [issue26198] PyArg_ParseTuple with format "et#" and "es#"
 detects overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <1453818562.99.0.0301241636143.issue26198@psf.upfronthosting.co.za>


Hrvoje Nik?i? added the comment:

Barun, Serhiy, thanks for picking this up so quickly.

I would further suggest to avoid using a fixed buffer in abspath (_getfullpathname, but only abspath seems to call it). Other filesystem calls are using the interface where PyArg_ParseTuple allocates the buffer. This makes it easier to handling errors from the native layer by catching OSError or similar, instead of the very generic TypeError (or ValueError).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 12:14:46 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 26 Jan 2016 17:14:46 +0000
Subject: [docs] [issue19698] Implement _imp.exec_builtin and exec_dynamic
In-Reply-To: <1385137675.64.0.235823443194.issue19698@psf.upfronthosting.co.za>
Message-ID: <1453828486.04.0.92277403838.issue19698@psf.upfronthosting.co.za>


Brett Cannon added the comment:

At this point both FrozenImporter and BuiltinImporter support exec_module(), so the only thing left to do is to document when FrozenImporter and WindowsRegistryFinder gained their exec_module() implementations (BuiltinImporter already has a note about it).

----------
assignee:  -> docs at python
keywords: +easy
nosy: +docs at python
priority: critical -> low
stage: test needed -> needs patch
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 12:37:16 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 26 Jan 2016 17:37:16 +0000
Subject: [docs] [issue26205] Inconsistency concerning nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1453829836.18.0.766099149415.issue26205@psf.upfronthosting.co.za>


Brett Cannon added the comment:

https://docs.python.org/3/tutorial/classes.html for the docs that Roscoe is talking about.

So the sentence is technically correct, it just takes careful reading to grasp what's being said. There are "at least three nested scopes", but there can be *up to* four scopes. Since "the scopes of any enclosing functions" is not necessarily true for all code scopes, you end up with at least three, but possibly four scopes.

Obviously the wording could be clearer, so if you want to sign the CLA, Roscoe, and propose a rewording that would be appreciated!

----------
nosy: +brett.cannon

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 17:07:13 2016
From: report at bugs.python.org (=?utf-8?q?Yannick_Duch=C3=AAne?=)
Date: Tue, 26 Jan 2016 22:07:13 +0000
Subject: [docs] [issue26205] Inconsistency concerning nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1453846033.76.0.995363799979.issue26205@psf.upfronthosting.co.za>


Yannick Duch?ne added the comment:

Better at least two, if I'm not wrong: the innermost scope may be the module's scope. So there is always at least the module scope and the built?ins scope, at least two up to four.

(if I have not overlooked something)

----------
nosy: +Hibou57

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 17:21:50 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 26 Jan 2016 22:21:50 +0000
Subject: [docs] [issue26205] Inconsistency concerning nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1453846910.85.0.615159782017.issue26205@psf.upfronthosting.co.za>


Brett Cannon added the comment:

It depends on how you want to view things as to whether you can claim there are two or three scopes for module-level code. While it's true that the local scope operates just like global scope, to Python it's more like local == global rather than the local scope simply doesn't exist (hence why `locals()` never throws an exception saying the scope doesn't exist but instead is the same as `globals()`).

The "three scope" phrasing also predates nested scopes from back when Python had its LGB scoping rules: Local-Global-Builtin. Back then we just said Python had three scopes and left it at that since it was basically always true and didn't confuse anyone.

At this point I'm fine with just removing the number from the sentence and saying something like "At any time during execution, there are various nested scopes whose namespaces are directly accessible:".

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 17:22:08 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 26 Jan 2016 22:22:08 +0000
Subject: [docs] [issue26205] Inconsistency concerning nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1453846928.97.0.737101793731.issue26205@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
stage:  -> needs patch
type: behavior -> 
versions: +Python 2.7, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 18:40:45 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 26 Jan 2016 23:40:45 +0000
Subject: [docs] [issue26213] Document BUILD_LIST_UNPACK & BUILD_TUPLE_UNPACK
Message-ID: <1453851645.07.0.698993321818.issue26213@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Turns out the BUILD_TUPLE_UNPACK and BUILD_LIST_UNPACK opcodes are undocumented in the dis module.

----------
assignee: docs at python
components: Documentation
messages: 258985
nosy: benjamin.peterson, brett.cannon, docs at python
priority: low
severity: normal
stage: needs patch
status: open
title: Document BUILD_LIST_UNPACK & BUILD_TUPLE_UNPACK
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 18:59:01 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 26 Jan 2016 23:59:01 +0000
Subject: [docs] [issue26213] Document BUILD_*_UNPACK opcodes
In-Reply-To: <1453851645.07.0.698993321818.issue26213@psf.upfronthosting.co.za>
Message-ID: <1453852741.16.0.50606359406.issue26213@psf.upfronthosting.co.za>


Brett Cannon added the comment:

There are also BUILD_SET_UNPACK and BUILD_MAP_UNPACK as well.

----------
title: Document BUILD_LIST_UNPACK & BUILD_TUPLE_UNPACK -> Document BUILD_*_UNPACK opcodes

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jan 26 20:45:08 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 27 Jan 2016 01:45:08 +0000
Subject: [docs] [issue19225] lack of PyExc_BufferError doc
In-Reply-To: <1381485777.95.0.364414099437.issue19225@psf.upfronthosting.co.za>
Message-ID: <1453859108.16.0.583878854158.issue19225@psf.upfronthosting.co.za>


Martin Panter added the comment:

General approach looks good. I left some review comments.

VMSError: I think this is Python 2 only, where it seems to be in a similar situation to WindowsError. According to Issue 16136 it was removed in Python 3.4. But it looks like your patch is against Python 3.

If you want to fix the alphabetical order, I think that is okay to do in the same patch. Otherwise, the current state is okay, but please put your BufferError in the right place :)

----------
nosy: +martin.panter
stage: needs patch -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 04:27:38 2016
From: report at bugs.python.org (tony gaetani)
Date: Wed, 27 Jan 2016 09:27:38 +0000
Subject: [docs] [issue9694] argparse required arguments displayed under
 "optional arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1453886858.91.0.294865977125.issue9694@psf.upfronthosting.co.za>


Changes by tony gaetani :


----------
nosy: +tonygaetani

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 08:25:53 2016
From: report at bugs.python.org (Julien Baley)
Date: Wed, 27 Jan 2016 13:25:53 +0000
Subject: [docs] [issue25314] Documentation: argparse's actions store_{true,
 false} default to False/True (undocumented)
In-Reply-To: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>
Message-ID: <1453901153.07.0.0375724502377.issue25314@psf.upfronthosting.co.za>


Julien Baley added the comment:

This issue has now been open for nearly three months. I think my patch is an improvement over the current documentation. If people want to improve the documentation further, they can probably submit a patch for that.

What can I do to get this accepted?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 10:06:17 2016
From: report at bugs.python.org (=?utf-8?q?Gedai_Tam=C3=A1s_Bence?=)
Date: Wed, 27 Jan 2016 15:06:17 +0000
Subject: [docs] [issue19225] lack of PyExc_BufferError doc
In-Reply-To: <1381485777.95.0.364414099437.issue19225@psf.upfronthosting.co.za>
Message-ID: <1453907177.25.0.616118646129.issue19225@psf.upfronthosting.co.za>


Gedai Tam?s Bence added the comment:

Thanks Martin for the review!

I tried to fix the problems, I hope now it'll be good.

Changes:
- fixed uppercase 'B'
- removed VMSError
- moved notes after versionchanged
- added two indices for the different tables
* put BufferError in it's place

I didn't fix the alphabetical order to keep the patch clean. If you find this patch good, I'll fix that as well if it's needed.

----------
Added file: http://bugs.python.org/file41727/doc_exceptions_v1.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 12:15:09 2016
From: report at bugs.python.org (Quentin Pradet)
Date: Wed, 27 Jan 2016 17:15:09 +0000
Subject: [docs] [issue26220] Unicode HOWTO references a question mark that
 isn't in snippet
Message-ID: <1453914908.97.0.691892593639.issue26220@psf.upfronthosting.co.za>


New submission from Quentin Pradet:

>From https://docs.python.org/3.6/howto/unicode.html#the-string-type:

> The following examples show the differences::
>
>     >>> b'\x80abc'.decode("utf-8", "strict")  #doctest: +NORMALIZE_WHITESPACE
>     Traceback (most recent call last):
>         ...
>     UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 0:
>       invalid start byte
>     >>> b'\x80abc'.decode("utf-8", "replace")
>     '\ufffdabc'
>     >>> b'\x80abc'.decode("utf-8", "backslashreplace")
>     '\\x80abc'
>     >>> b'\x80abc'.decode("utf-8", "ignore")
>     'abc'
>
> (In this code example, the Unicode replacement character has been replaced by
> a question mark because it may not be displayed on some systems.)

I think the whole sentence after the snippet can be removed because this is exactly what Python 3.2+ outputs. It looks like the commit which added this sentence dates from Python 3.1: https://github.com/python/cpython/commit/34d4c82af56ebc1b65514a118f0ec7feeb8e172f, but another commit around Python 3.3 removed it: https://github.com/python/cpython/commit/63172c46706ae9b2a3bc80d639504a57fff4e716.

----------
assignee: docs at python
components: Documentation
messages: 259034
nosy: Quentin.Pradet, docs at python
priority: normal
severity: normal
status: open
title: Unicode HOWTO references a question mark that isn't in snippet
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 18:02:49 2016
From: report at bugs.python.org (Udi Oron)
Date: Wed, 27 Jan 2016 23:02:49 +0000
Subject: [docs] [issue26224] Add "version added" for documentation of
 asyncio.timeout for documentation of python 3.4, 3.5, 3.6
Message-ID: <1453935768.98.0.383268297204.issue26224@psf.upfronthosting.co.za>


New submission from Udi Oron:

It seems like `asyncio.timeout` is going to be added in 3.4.5, 3.5.2 and 3.6.

The current live documentation of python 3.4 and python 3.5.1 does not include a comment regarding it is not yet available in the current released versions of python.

The documentation should include a `.. versionadded:: 3.4.5`, `.. versionadded:: 3.5.2` or `.. versionadded:: 3.6` according to the branch.

----------
assignee: docs at python
components: Documentation, asyncio
files: asyncio-timeout.patch
keywords: patch
messages: 259071
nosy: Udi Oron, docs at python, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Add "version added" for documentation of asyncio.timeout for documentation of python 3.4, 3.5, 3.6
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41731/asyncio-timeout.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 19:01:28 2016
From: report at bugs.python.org (Andrew Barnert)
Date: Thu, 28 Jan 2016 00:01:28 +0000
Subject: [docs] [issue26225] New misleading wording in execution model
 documenation
Message-ID: <1453939288.53.0.211010759952.issue26225@psf.upfronthosting.co.za>


New submission from Andrew Barnert:

In #24129, the wording describing class local bindings in 4.2.2 "Resolution of names" was changed for Python 3.4, 3.5, and 3.6. The new version is a lot clearer for classes--but now it's misleading for `exec`/`eval`.

---

> Class definition blocks and arguments to exec() and eval() are
> special in the context of name resolution. A class definition is...

... and then proceeds to explain how class lookup works, without ever mentioning `exec` and `eval`. This implies that they work the same way as classes, but of course that's not true:

    i = 'global'
    def f():
        i = 'nonlocal'
        class C:
            print(i)
            i = 'local'
            print(i)
    f()

That prints `global`, then `local`. But with `exec`:

    i = 'global'
    def f():
        i = 'nonlocal'
        exec("print(i)\ni = 'local'\nprint(i)\n")
    f()

That prints `nonlocal` then `local`.

I think just putting a paragraph break between the first sentence and the rest of the paragraph might be sufficient to avoid the confusion here. Or just removing any mention of `eval` and `exec`. If not, this probably needs a new one-liner paragraph saying something like "Arguments to `exec()` and `eval()` are also special, as described later."

---

Meanwhile, if you keep reading, you'll eventually find that `exec` is described in a later section, 4.2.4 "Interaction with dynamic features", but that's _also_ misleading:

> The eval() and exec() functions do not have access to the full
> environment for resolving names. Names may be resolved in the
> local and global namespaces of the caller. Free variables are not
> resolved in the nearest enclosing namespace, but in the global
> namespace.

If that were true, the `exec` example would have printed `global`, right?

I'm pretty sure that what's going on here is that `exec` implicitly calls `locals()` (or, rather, the C-API equivalent), which constructs a locals dict on demand, which, only if you're inside a function block, includes not just the currently-bound fast locals, but _also_ the cell_contents of the currently-bound free variables. So, as far as `exec` is concerned, `i` is not an unbound local, or a free variable, but a local, which is bound to the `'nonlocal'` cell value of `i` at the time `exec` was called.

Which means the following actually _does_ print `global`:

    i = 'global'
    def f():
        exec("print(i)\ni = 'local'\nprint(i)\n")
        i = 'nonlocal'
    f()

I have no idea how to make this clear. Maybe the simplest is to not try to give a full explanation here, and instead punt to the `locals()` function definition? Maybe something like this:

> The `eval()` and `exec()` functions do not have access to the full environment for resolving names, but rather to the approximation of that environment as constructed by the `locals()` function. Free variables that are not captured as locals are not resolved in the nearest enclosing namespace, but in the global...

... and from there, the same as the current paragraph.

----------
assignee: docs at python
components: Documentation
messages: 259073
nosy: abarnert, docs at python
priority: normal
severity: normal
status: open
title: New misleading wording in execution model documenation

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 19:01:40 2016
From: report at bugs.python.org (Andrew Barnert)
Date: Thu, 28 Jan 2016 00:01:40 +0000
Subject: [docs] [issue26225] New misleading wording in execution model
 documenation
In-Reply-To: <1453939288.53.0.211010759952.issue26225@psf.upfronthosting.co.za>
Message-ID: <1453939300.98.0.174022972262.issue26225@psf.upfronthosting.co.za>


Changes by Andrew Barnert :


----------
type:  -> enhancement

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 20:29:15 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 28 Jan 2016 01:29:15 +0000
Subject: [docs] [issue26225] New misleading wording in execution model
 documenation
In-Reply-To: <1453939288.53.0.211010759952.issue26225@psf.upfronthosting.co.za>
Message-ID: <1453944555.49.0.579877434499.issue26225@psf.upfronthosting.co.za>


Eryk Sun added the comment:

The class example defines "i" as a local variable, which means the CPython operation used for unoptimized code (class or module/exec) is LOAD_NAME, which searches locals, globals, and builtins. The result differs from the exec example because a class is executed with a new locals dict to capture the class namespace. 

I think a more interesting case to explain is code that uses LOAD_CLASSDEREF. This operation tries locals and nonlocals, but not globals or builtins.

    i = 'global'
    def f():
        i = 'nonlocal'
        class C:
            print(i)

    >>> f()
    nonlocal

    i = 'global'
    def f():
        class C:
            print(i)
        i = 'nonlocal'

    >>> f()
    Traceback (most recent call last):
      File "", line 1, in 
      File "", line 2, in f
      File "", line 3, in C
    NameError: free variable 'i' referenced before assignment in enclosing scope

    i = 'global'
    def f():
        class C:
            locals()['i'] = 'local'
            print(i)
        i = 'nonlocal'

    >>> f()
    local

    i = 'global'
    def f():
        i = 'nonlocal'
        class C:
            nonlocal i
            print(i)
            i = 'new nonlocal'
            print(i)
        print(i)

    >>> f()
    nonlocal
    new nonlocal
    new nonlocal

----------
nosy: +eryksun

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 23:13:23 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jan 2016 04:13:23 +0000
Subject: [docs] [issue26220] Unicode HOWTO references a question mark that
 isn't in snippet
In-Reply-To: <1453914908.97.0.691892593639.issue26220@psf.upfronthosting.co.za>
Message-ID: <20160128041320.30766.20232@psf.io>


Roundup Robot added the comment:

New changeset 63c1c7cdad0f by Martin Panter in branch '3.5':
Issue #26220: Remove outdated comment about a question mark
https://hg.python.org/cpython/rev/63c1c7cdad0f

New changeset dbf90175ea50 by Martin Panter in branch 'default':
Issue #26220: Merge Unicode how-to from 3.5
https://hg.python.org/cpython/rev/dbf90175ea50

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jan 27 23:18:43 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Jan 2016 04:18:43 +0000
Subject: [docs] [issue26220] Unicode HOWTO references a question mark that
 isn't in snippet
In-Reply-To: <1453914908.97.0.691892593639.issue26220@psf.upfronthosting.co.za>
Message-ID: <1453954723.73.0.0177005887047.issue26220@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the report Quentin.

----------
nosy: +martin.panter
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions:  -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 01:26:15 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 28 Jan 2016 06:26:15 +0000
Subject: [docs] [issue25314] Documentation: argparse's actions store_{true,
 false} default to False/True (undocumented)
In-Reply-To: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>
Message-ID: <1453962375.67.0.244403412264.issue25314@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Hi Julien, thanks for your patch and sorry for the lack of reviews. I find the new wording in the second hunk confusing:

``'store_true'`` and ``'store_false'`` - These store the values ``False`` respectively (Note that these default to ``False`` and ``True``  respectively).  These are special cases of ``'store_const'``.

On first read, It seems to contradict itself.  I know what is meant, but I think it should be expanded a bit.

Also, the part about ``store_const`` should still mention the default for its value (not for the const). I suppose it's ``None``?

----------
nosy: +georg.brandl

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 01:40:24 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jan 2016 06:40:24 +0000
Subject: [docs] [issue26199] fix broken link to
 hamcrest.library.integration.match_equality in unittest.mock "getting
 started" documentation
In-Reply-To: <1453738852.52.0.691213360087.issue26199@psf.upfronthosting.co.za>
Message-ID: <20160128064021.30752.15436@psf.io>


Roundup Robot added the comment:

New changeset e4b0f003ad13 by Berker Peksag in branch '3.5':
Issue #26199: Fix broken link in unittest.mock-examples.rst
https://hg.python.org/cpython/rev/e4b0f003ad13

New changeset 7c38a47fd4d5 by Berker Peksag in branch 'default':
Issue #26199: Fix broken link in unittest.mock-examples.rst
https://hg.python.org/cpython/rev/7c38a47fd4d5

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 01:41:58 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 28 Jan 2016 06:41:58 +0000
Subject: [docs] [issue26199] fix broken link to
 hamcrest.library.integration.match_equality in unittest.mock "getting
 started" documentation
In-Reply-To: <1453738852.52.0.691213360087.issue26199@psf.upfronthosting.co.za>
Message-ID: <1453963318.09.0.657114508711.issue26199@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Raphael!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions:  -Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 01:51:28 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Jan 2016 06:51:28 +0000
Subject: [docs] [issue20598] argparse docs: '7'.split() is confusing magic
In-Reply-To: <1392132505.16.0.864715722344.issue20598@psf.upfronthosting.co.za>
Message-ID: <1453963887.05.0.422753468386.issue20598@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a patch changing all the '. . .'.split() calls to lists of strings. I think the illustrations are actually less complicated to understand when you see the list directly, and they more consistent with the remaining illustrations that already use lists, but I see Benjamin disagrees.

----------
keywords: +patch
nosy: +martin.panter
stage:  -> patch review
versions: +Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41739/arg-list.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 02:01:54 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jan 2016 07:01:54 +0000
Subject: [docs] [issue26034] venv documentation out of date
In-Reply-To: <1452141532.31.0.700374014076.issue26034@psf.upfronthosting.co.za>
Message-ID: <20160128070148.62668.55561@psf.io>


Roundup Robot added the comment:

New changeset d2a32b78be96 by Berker Peksag in branch '3.5':
Issue #26034: Sync documentation of --clear with its behavior
https://hg.python.org/cpython/rev/d2a32b78be96

New changeset 5764cc02244d by Berker Peksag in branch 'default':
Issue #26034: Sync documentation of --clear with its behavior
https://hg.python.org/cpython/rev/5764cc02244d

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 02:03:28 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 28 Jan 2016 07:03:28 +0000
Subject: [docs] [issue20598] argparse docs: '7'.split() is confusing magic
In-Reply-To: <1392132505.16.0.864715722344.issue20598@psf.upfronthosting.co.za>
Message-ID: <1453964608.94.0.0858474957939.issue20598@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I don't feel that strongly about it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 02:03:52 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 28 Jan 2016 07:03:52 +0000
Subject: [docs] [issue26034] venv documentation out of date
In-Reply-To: <1452141532.31.0.700374014076.issue26034@psf.upfronthosting.co.za>
Message-ID: <1453964632.67.0.276837783796.issue26034@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report, Dan. Most of the docs has already been updated in c3c188a0325a. I've updated the remaining ones.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 02:13:34 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jan 2016 07:13:34 +0000
Subject: [docs] [issue26034] venv documentation out of date
In-Reply-To: <1452141532.31.0.700374014076.issue26034@psf.upfronthosting.co.za>
Message-ID: <20160128071331.30746.45632@psf.io>


Roundup Robot added the comment:

New changeset 9c5370405393 by Berker Peksag in branch '3.5':
Issue #26034: Improve wording of clear parameter
https://hg.python.org/cpython/rev/9c5370405393

New changeset 0fb96a43d381 by Berker Peksag in branch 'default':
Issue #26034: Improve wording of clear parameter
https://hg.python.org/cpython/rev/0fb96a43d381

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 04:00:20 2016
From: report at bugs.python.org (Julien Baley)
Date: Thu, 28 Jan 2016 09:00:20 +0000
Subject: [docs] [issue25314] Documentation: argparse's actions store_{true,
 false} default to False/True (undocumented)
In-Reply-To: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>
Message-ID: <1453971619.98.0.369273051909.issue25314@psf.upfronthosting.co.za>


Julien Baley added the comment:

Hi Georg,

thanks for your answer. I think maybe you're missing a bit in there?

"``'store_true'`` and ``'store_false'`` - These store the values ``True`` and ``False`` respectively (Note that these default to ``False`` and ``True``  respectively).  These are special cases of ``'store_const'``."  (added "``True`` andd")

But if I'm correct, you're talking of the parenthesis which would be confusing? Can we come up with a better wording?

"(and default to False and True if the action is not triggered)" ?

As for `store_const`, R. David Murray says it has no default. It is technically correct: store_const behaves like any other action in that it defaults to whatever the argument `default` in `add_argument` is set to.
The fact that `default` defaults to None is indicated in 16.4.3.5. default:
"The default keyword argument of add_argument(), whose value defaults to None,"
Therefore, I believe it is more correct the way R. David Murray suggested.

What do you think?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 04:54:36 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 28 Jan 2016 09:54:36 +0000
Subject: [docs] [issue20598] argparse docs: '7'.split() is confusing magic
In-Reply-To: <1392132505.16.0.864715722344.issue20598@psf.upfronthosting.co.za>
Message-ID: <1453974875.99.0.999408394585.issue20598@psf.upfronthosting.co.za>


SilentGhost added the comment:

I think it's worth saying that this wasn't a random choice intended to confuse beginners. Strings used represent input that is identical to the command-line input: if one wants to test it, one can just copy that string directly into the propmpt, it might be harder to reconstruct it from a list of strings.

----------
nosy: +SilentGhost

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 05:07:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Jan 2016 10:07:00 +0000
Subject: [docs] [issue20598] argparse docs: '7'.split() is confusing magic
In-Reply-To: <1392132505.16.0.864715722344.issue20598@psf.upfronthosting.co.za>
Message-ID: <1453975620.65.0.540213975078.issue20598@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Using str.split() for splitting full command line on arguments is anti-idiom. More correct way is to use shlex. But this is overkill for argparse examples (and in most cases we already have a list sys.argv). Explicit lists look clear enough.

The patch LGTM.

----------
assignee: docs at python -> martin.panter
nosy: +serhiy.storchaka
stage: patch review -> commit review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 05:35:10 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jan 2016 10:35:10 +0000
Subject: [docs] [issue19023] ctypes docs: Unimplemented and undocumented
 features
In-Reply-To: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za>
Message-ID: <20160128103507.24402.79270@psf.io>


Roundup Robot added the comment:

New changeset 732fdd03e708 by Martin Panter in branch '3.5':
Issue #19023: Document ctypes array and pointer classes
https://hg.python.org/cpython/rev/732fdd03e708

New changeset a78cbb2125a8 by Martin Panter in branch 'default':
Issue #19023: Merge ctypes doc and tests from 3.5
https://hg.python.org/cpython/rev/a78cbb2125a8

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 05:53:23 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 28 Jan 2016 10:53:23 +0000
Subject: [docs] [issue16731] xxlimited/xxmodule docstrings ambiguous
In-Reply-To: <1355946646.69.0.259699636535.issue16731@psf.upfronthosting.co.za>
Message-ID: <1453978402.76.0.661964246727.issue16731@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I think the difference between xxlimited and xxmodule is still a bit ambiguous. I would expect a mention of PEP 384 or a link to https://docs.python.org/3/c-api/stable.html to explain what Py_LIMITED_API really is.

+#ifndef Py_LIMITED_API
+# error "This file requires Py_LIMITED_API"
+#endif

I don't have a strong opinion about this, but I think the error message could be more informative (e.g. you must define a Py_LIMITED_API macro) Or we can improve https://docs.python.org/3/c-api/stable.html to give an example there.

----------
nosy: +berker.peksag, serhiy.storchaka
stage:  -> patch review
type:  -> enhancement

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 07:48:36 2016
From: report at bugs.python.org (Raphael Das Gupta)
Date: Thu, 28 Jan 2016 12:48:36 +0000
Subject: [docs] [issue26199] fix broken link to
 hamcrest.library.integration.match_equality in unittest.mock "getting
 started" documentation
In-Reply-To: <1453738852.52.0.691213360087.issue26199@psf.upfronthosting.co.za>
Message-ID: <1453985316.61.0.165835943906.issue26199@psf.upfronthosting.co.za>


Raphael Das Gupta added the comment:

You're welcome. Thanks for applying the patch.

Shouldn't it be applied to other affected versions (3.3 and 3.4), too, though?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 08:07:32 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 28 Jan 2016 13:07:32 +0000
Subject: [docs] [issue26160] Tutorial incorrectly claims that (explicit)
 relative imports don't work in the main module
In-Reply-To: <1453273352.49.0.425335373136.issue26160@psf.upfronthosting.co.za>
Message-ID: <1453986452.71.0.191492966521.issue26160@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 08:07:59 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 28 Jan 2016 13:07:59 +0000
Subject: [docs] [issue26199] fix broken link to
 hamcrest.library.integration.match_equality in unittest.mock "getting
 started" documentation
In-Reply-To: <1453738852.52.0.691213360087.issue26199@psf.upfronthosting.co.za>
Message-ID: <1453986479.88.0.0825323742125.issue26199@psf.upfronthosting.co.za>


Berker Peksag added the comment:

3.3 and 3.4 are in security-fix-only mode, which means they won't get bugfix and documentation updates anymore. See https://docs.python.org/devguide/devcycle.html for details.

----------

_______________________________________
Python tracker 

_______________________________________

From Abhaya.Ghatkar at ecs.co.uk  Thu Jan 28 02:33:30 2016
From: Abhaya.Ghatkar at ecs.co.uk (Abhaya Ghatkar)
Date: Thu, 28 Jan 2016 07:33:30 +0000
Subject: [docs] Support and compatibility against Win Server 2008R2 and Win
 Server 2012R2
Message-ID: <34927D6DD339A5418BC9976CB5A7BF764AC64458@ECSEXCH01.ecsemea.com>

Hi ,

I am seeking some information like support and Compatibility of below products for platforms Win Server 2008R2 and Win Server 2012R2

Software Name

Software Version

Python 2.5

2.5.150

Python 2.6

2.6.0

Python 2.7.2 (64-bit)

2.7.2

Python 2.6 soaplib-0.8.1

0.8.1

Python 2.6 mockito-0.5.1

0.5.1

Python 2.6 suds-0.3.9

0.3.9

Python 2.7 pycrypto-2.3

2.3.0



Please provide the support and compatibility results for above mentioned OS platforms , Also you can provide us the details if any other support/contact channels are available.

Thanks in advance.


Regards,

Abhaya Ghatkar
Trainee Engineer

Email:  Abhaya.Ghatkar at ecs.co.uk

[cid:image742afc.PNG at 92ddf7b3.418c1d38]        [cid:image8a1a8a.GIF at bc191efd.4784de21]   [LinkedIn]   [Twitter] 

Glasgow     .     London     .     Leeds     .     Edinburgh     .     Manchester     .     Pune     .     Johannesburg

This message may contain privileged/confidential information. If you are not the intended recipient, please inform ECS and delete this message immediately.

Note: This message has been virus scanned by ECS before sending. Neither ECS, nor the sender, accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. Any views, opinions, conclusions or other information in this message that do not relate to the business of ECS are not authorised by us. In addition, ECS does not accept responsibility for any changes made to this message after it was originally sent.

ECS is a group of limited companies incorporated in Scotland with Head Offices registered at Parkview House, 6 Woodside Place, Glasgow G3 7QF.

ECS Europe Ltd Reg No. SC357435    ECS Global Ltd Reg No. SC348886    ECS Security Ltd Reg No. SC418589    ECS Consultancy Ltd Reg No.SC436053

P Please consider the environment before printing this e-mail.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image742afc.PNG
Type: image/png
Size: 20774 bytes
Desc: image742afc.PNG
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image8a1a8a.GIF
Type: image/gif
Size: 679 bytes
Desc: image8a1a8a.GIF
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imagefea8f6.GIF
Type: image/gif
Size: 805 bytes
Desc: imagefea8f6.GIF
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image2dca3d.GIF
Type: image/gif
Size: 714 bytes
Desc: image2dca3d.GIF
URL: 

From chris.heald at darktrace.com  Wed Jan 27 11:21:20 2016
From: chris.heald at darktrace.com (Chris Heald)
Date: Wed, 27 Jan 2016 16:21:20 +0000
Subject: [docs] https://docs.python.org/2/library/urllib.html [DTL0]
Message-ID: <0BAF4C49-C8A9-4D0B-B679-E5E1A65100BB@darktrace.com>

The warning about HTTPS verification is no longer true (see https://www.python.org/dev/peps/pep-0476/ ) and rather confusing.
This needs clarifying including which exact versions of python do or do not verify by default, with a link for how to restore the old, unverified behaviour.

Thanks
--
Chris Heald
Senior Cyber Security Specialist, Darktrace
mobile +44 (0) 7799 902092 |  21 JJ Thomson Av, Cambridge, CB3 0FA
Linkedin 	Twitter 	Darktrace.com 
Confidentiality Note: This email may contain confidential and/or private information. If you received this email in error please delete and notify sender.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3853 bytes
Desc: not available
URL: 

From vadmium+py at gmail.com  Tue Jan 26 20:44:21 2016
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Wed, 27 Jan 2016 01:44:21 -0000
Subject: [docs] lack of PyExc_BufferError doc (issue 19225)
Message-ID: <20160127014421.19689.6942@psf.upfronthosting.co.za>


https://bugs.python.org/review/19225/diff/16404/Doc/c-api/exceptions.rst
File Doc/c-api/exceptions.rst (right):

https://bugs.python.org/review/19225/diff/16404/Doc/c-api/exceptions.rst#newcode829
Doc/c-api/exceptions.rst:829: | :c:data:`PyExc_UnBoundLocalError`      
| :exc:`UnboundLocalError`        |          |
Lowercase B

https://bugs.python.org/review/19225/diff/16404/Doc/c-api/exceptions.rst#newcode885
Doc/c-api/exceptions.rst:885: These aliases used to be separate
exception types.
I think it might be better to keep the versionchanged close to the table
of aliases, and then the notes. The version changed only applies to the
aliases, but the notes apply to both tables.

https://bugs.python.org/review/19225/diff/16404/Doc/c-api/exceptions.rst#newcode933
Doc/c-api/exceptions.rst:933: single: PyExc_BufferError
IMO these index entries should go _before_ the appropriate table, not
after. But I guess that is a separate problem.

https://bugs.python.org/review/19225/

From report at bugs.python.org  Thu Jan 28 12:58:01 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jan 2016 17:58:01 +0000
Subject: [docs] [issue26198] PyArg_ParseTuple with format "et#" and "es#"
 detects overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <20160128175758.16754.99031@psf.io>


Roundup Robot added the comment:

New changeset 1c690cb4def8 by Serhiy Storchaka in branch '3.5':
Issue #26198: Added tests for "es", "et", "es#", "et#" and "C" format units
https://hg.python.org/cpython/rev/1c690cb4def8

New changeset 745ad3010384 by Serhiy Storchaka in branch 'default':
Issue #26198: Added tests for "es", "et", "es#", "et#" and "C" format units
https://hg.python.org/cpython/rev/745ad3010384

New changeset 60a2d67dacb3 by Serhiy Storchaka in branch '2.7':
Issue #26198: Added tests for string-related format units of PyArg_Parse*()
https://hg.python.org/cpython/rev/60a2d67dacb3

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 13:38:50 2016
From: report at bugs.python.org (paul j3)
Date: Thu, 28 Jan 2016 18:38:50 +0000
Subject: [docs] [issue20598] argparse docs: '7'.split() is confusing magic
In-Reply-To: <1392132505.16.0.864715722344.issue20598@psf.upfronthosting.co.za>
Message-ID: <1454006330.06.0.729408874328.issue20598@psf.upfronthosting.co.za>


paul j3 added the comment:

I can understand changing 

    '7'.split()

but this change is IMO ugly:

-     >>> print(parser.parse_args('--foo B cmd --arg1 XX ZZ'.split()))
+     >>> print(parser.parse_args(['--foo', 'B', 'cmd', '--arg1', 'XX', 'ZZ']))

I've answered a lot of argparse questions on Stackoverflow, and don't recall anyone being confused by the use of 'split' in the documentation.  The documentation as a whole is overwealming to many users.  But not this detail.

Many SO answers use the split idiom.  Being aware of this issue I have edited some of my answers to use lists, even if I used split when creating them in Ipython.   But only in the short cases.

Other times I copy-n-paste a complete (short) script, along with one or more sample runs (bash line plus printout).  That kind of display is closer to what most new users expect and see.  But it does not fit with the doctest format used in the argparse documentation.

Come to think of it, the doctest example format might be a greater hindrance to understanding than the split idiom.  New users tend to construct complete scripts, and then complain that it doesn't do what they want.  Often I have to ask them to print sys.argv to see what the shell is giving the parser.  And to print args to see what parser is giving back.  New users aren't in habit of using interactive test inputs as illustrated in the docs.

The patch proposed here may be nice in terms of consistency, but I don't think it improves readability.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 15:54:26 2016
From: report at bugs.python.org (paul j3)
Date: Thu, 28 Jan 2016 20:54:26 +0000
Subject: [docs] [issue25314] Documentation: argparse's actions store_{true,
 false} default to False/True (undocumented)
In-Reply-To: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>
Message-ID: <1454014466.44.0.455339759237.issue25314@psf.upfronthosting.co.za>


paul j3 added the comment:

How about:

    These store the values True and False respectively (and default to False and True if absent).

The reference to `store_const` is confusing, since almost no one uses that action.

The `store_const` paragraph has:

    (Note that the const keyword argument defaults to the rather unhelpful None.) 

But the most common `store` action also defaults to the default default None.  In fact most action types do that.

With 'store' action, None is a useful default, since its impossible to provide in the commandline.  Thus

     if args.foo is None:

is a clear test that 'foo' was not present in the commandline.  I can imagine using the same test on a 'store_const' argument (though I've never had the need to use it or recommend it).

I'm almost of the opinion that we should remove that parenthetical remark.

The 'const' parameter is used most often with 'store' and "nargs='?'", as illustrated in that 'nargs' subsection.

To complicate things, if I provide a "argument_default='boo'" parameter in the parser definition, it overrides all of these default defaults, including for 'store_true'.  In that case an explicit 'default=False' is *required*, not superfluous.

To further complicate things, 'parser.set_defaults' can override all of these.

We've almost given users too many ways of setting 'default'. :)  Fortunately in practice they don't use most of them.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 16:37:40 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Jan 2016 21:37:40 +0000
Subject: [docs] [issue20598] argparse docs: '7'.split() is confusing magic
In-Reply-To: <1392132505.16.0.864715722344.issue20598@psf.upfronthosting.co.za>
Message-ID: <1454017060.46.0.818574523162.issue20598@psf.upfronthosting.co.za>


Martin Panter added the comment:

I don?t want to make any controversial changes. Half the purpose of the patch was to let people see what it would look like. Another option would be to only do the single or empty list changes, and leave most of the longer lists as they are with split().

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 16:53:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Jan 2016 21:53:46 +0000
Subject: [docs] [issue26198] PyArg_ParseTuple with format "et#" and "es#"
 detects overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <1454018026.43.0.930755786706.issue26198@psf.upfronthosting.co.za>


Martin Panter added the comment:

One review comment

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 17:06:17 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Jan 2016 22:06:17 +0000
Subject: [docs] [issue25314] Documentation: argparse's actions store_{true,
 false} default to False/True (undocumented)
In-Reply-To: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>
Message-ID: <1454018777.89.0.383535198063.issue25314@psf.upfronthosting.co.za>


Martin Panter added the comment:

I definitely agree with removing the remark about the ?const? value with store_const. People here seem to be overloading the terms ?default? and ?argument?. When using store_const, it seems the programmer must also specify a value for the ?const? parameter to add_argument(). It is incorrect to say it is None if not explicitly set.

On the other hand, I think if the end user omits a CLI argument configured with store_const, then the argparse module will substitute None, or the value of the ?default? parameter to add_argument().

For the original report about store_true/false, perhapse it would be sufficient to port revision 49677cc6d83a to Python 3. Although there is a stray ?using? that should probably be fixed.

----------
nosy: +martin.panter
versions: +Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 17:34:27 2016
From: report at bugs.python.org (Julien Baley)
Date: Thu, 28 Jan 2016 22:34:27 +0000
Subject: [docs] [issue25314] Documentation: argparse's actions store_{true,
 false} default to False/True (undocumented)
In-Reply-To: <1443992693.14.0.504421256983.issue25314@psf.upfronthosting.co.za>
Message-ID: <1454020467.57.0.183459271184.issue25314@psf.upfronthosting.co.za>


Julien Baley added the comment:

I like paul.j3's suggestion, but it would probably make more sense to have it consistent with python2 and port the change Martin pointed to.

How does one do that?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 17:36:37 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Jan 2016 22:36:37 +0000
Subject: [docs] [issue26198] PyArg_ParseTuple with format "et#" and "es#"
 detects overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <1454020597.46.0.463538351091.issue26198@psf.upfronthosting.co.za>


Martin Panter added the comment:

Also, test_getargs2 seems faulty on 2.7. I am seeing MemoryError; some of the buildbots are segfaulting.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 17:56:45 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jan 2016 22:56:45 +0000
Subject: [docs] [issue26198] PyArg_ParseTuple with format "et#" and "es#"
 detects overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <20160128225642.24917.53785@psf.io>


Roundup Robot added the comment:

New changeset d0b4be7d2134 by Serhiy Storchaka in branch '2.7':
Fixed a crash in new tests in test_getargs2 added in 60a2d67dacb3 (issue #26198).
https://hg.python.org/cpython/rev/d0b4be7d2134

----------

_______________________________________
Python tracker 

_______________________________________

From storchaka at gmail.com  Thu Jan 28 18:02:12 2016
From: storchaka at gmail.com (storchaka at gmail.com)
Date: Thu, 28 Jan 2016 23:02:12 -0000
Subject: [docs] PyArg_ParseTuple with format "et#" and "es#" detects
 overflow by raising TypeError instead of ValueError (issue 26198)
Message-ID: <20160128230212.27952.97479@psf.upfronthosting.co.za>


https://bugs.python.org/review/26198/diff/16428/Python/getargs.c
File Python/getargs.c (right):

https://bugs.python.org/review/26198/diff/16428/Python/getargs.c#newcode546
Python/getargs.c:546: strncpy(msgbuf, expected, bufsize);
On 2016/01/28 22:40:53, vadmium wrote:
> The strncpy() makes snprintf() redundant, doesn?t it?

Oh, true.

https://bugs.python.org/review/26198/

From report at bugs.python.org  Thu Jan 28 18:03:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Jan 2016 23:03:04 +0000
Subject: [docs] [issue26198] PyArg_ParseTuple with format "et#" and "es#"
 detects overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <1454022184.85.0.106170326701.issue26198@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Martin. This was 64-bit specific bug.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 18:08:09 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Jan 2016 23:08:09 +0000
Subject: [docs] [issue26198] PyArg_ParseTuple with format "et#" and "es#"
 detects overflow by raising TypeError instead of ValueError
In-Reply-To: <1453738388.34.0.790534194643.issue26198@psf.upfronthosting.co.za>
Message-ID: <1454022489.58.0.0973287282689.issue26198@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is updated patch.

----------
Added file: http://bugs.python.org/file41746/pyarg_parse_encoded_string_2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 18:21:49 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jan 2016 23:21:49 +0000
Subject: [docs] [issue19023] ctypes docs: Unimplemented and undocumented
 features
In-Reply-To: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za>
Message-ID: <20160128232139.45903.51181@psf.io>


Roundup Robot added the comment:

New changeset 034b077d3015 by Martin Panter in branch '2.7':
Issue #19023: Document ctypes array and pointer classes
https://hg.python.org/cpython/rev/034b077d3015

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 18:31:03 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Jan 2016 23:31:03 +0000
Subject: [docs] [issue19023] ctypes docs: Unimplemented and undocumented
 features
In-Reply-To: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za>
Message-ID: <1454023863.83.0.934427250707.issue19023@psf.upfronthosting.co.za>


Martin Panter added the comment:

Okay I have committed the Array and _Pointer stuff. I suggest if anyone wants to work on the Union classes, they open a separate report. (I never understood what they are for. C doesn?t have much little or big endian stuff; byte order mostly depends on the ABI, so why is ctypes different?)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jan 28 19:16:38 2016
From: report at bugs.python.org (paul j3)
Date: Fri, 29 Jan 2016 00:16:38 +0000
Subject: [docs] [issue26235] argparse docs: Positional * argument in
 mutually exclusive group requires a default parameter
Message-ID: <1454026598.04.0.15054739834.issue26235@psf.upfronthosting.co.za>


New submission from paul j3:

The documentation for Mutual exclusion

https://docs.python.org/3/library/argparse.html#mutual-exclusion

needs a note that a mutually exclusive group may contain one positional argument.  But that argument must be either nargs='?', or nargs='*'.  If '*' it must also have a default parameter (other than None).

(this issue came up recently on stackoverflow.  It may have also been raised in the past as a bug/issue, but I don't have time at moment to search.  I had to search through several layers of code to remember all the details.)

http://stackoverflow.com/questions/35044288/how-can-i-create-an-argparse-mutually-exclusive-group-with-multiple-positional-p

----------
assignee: docs at python
components: Documentation
messages: 259179
nosy: docs at python, paul.j3
priority: normal
severity: normal
status: open
title: argparse docs: Positional * argument in mutually exclusive group requires a default parameter
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From vadmium+py at gmail.com  Thu Jan 28 16:40:53 2016
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Thu, 28 Jan 2016 21:40:53 -0000
Subject: [docs] PyArg_ParseTuple with format "et#" and "es#" detects
 overflow by raising TypeError instead of ValueError (issue 26198)
Message-ID: <20160128214053.27952.2570@psf.upfronthosting.co.za>


https://bugs.python.org/review/26198/diff/16428/Python/getargs.c
File Python/getargs.c (right):

https://bugs.python.org/review/26198/diff/16428/Python/getargs.c#newcode546
Python/getargs.c:546: strncpy(msgbuf, expected, bufsize);
The strncpy() makes snprintf() redundant, doesn?t it?

https://bugs.python.org/review/26198/

From report at bugs.python.org  Fri Jan 29 20:39:41 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Jan 2016 01:39:41 +0000
Subject: [docs] [issue26205] Inconsistency concerning nested scopes
In-Reply-To: <1453774587.84.0.143729632402.issue26205@psf.upfronthosting.co.za>
Message-ID: <1454117980.9.0.295620738317.issue26205@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Would 'three or more' be any clearer than 'at least three'?  They mean the same, but the first seems better to me in this context.

The real problem with this section are a) the use of Guido's first person 'I' and b) statements that were not changed when nested scope were added, but should have been.

"If a name is declared global, then all references and assignments go directly to the middle scope containing the module?s global names."

The global scope is no longer the middle scope.  Roscoe pointed at this.  With that removed, the sentence says that if a name is declared global, assignments go to global scope.  This would be more meaningful if prefixed by a revised version of the following, which is several paragraphs down.

"A special quirk of Python is that ? if no global statement is in effect ? assignments to names always go into the innermost scope."

The special quirk part should go; 'global' would now have to be 'global or nonlocal', but I now think the following, preceeding the revised 'global' sentence above, would be better.

"By default, assignments to names always go into the innermost, local, namespace."

In other words, I think the sentence Roscoe flagged is the least of the problems with this section.

----------
nosy: +terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jan 29 21:42:42 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Jan 2016 02:42:42 +0000
Subject: [docs] [issue26235] argparse docs: Positional * argument in
 mutually exclusive group requires a default parameter
In-Reply-To: <1454026598.04.0.15054739834.issue26235@psf.upfronthosting.co.za>
Message-ID: <1454121762.13.0.495255879241.issue26235@psf.upfronthosting.co.za>


Changes by Terry J. Reedy :


----------
nosy: +bethard

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 00:14:19 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 30 Jan 2016 05:14:19 +0000
Subject: [docs] [issue26225] New misleading wording in execution model
 documenation
In-Reply-To: <1453939288.53.0.211010759952.issue26225@psf.upfronthosting.co.za>
Message-ID: <1454130859.83.0.483569917515.issue26225@psf.upfronthosting.co.za>


Martin Panter added the comment:

Calling exec() with only one argument is equivalent to exec(..., globals(), locals()). It does not create a new scope for names. So an equivalent of your three-level example is more like

>>> i = 'global'
>>> def f():
...     i = 'nonlocal'
...     class_locals = dict()
...     exec("print(i)\ni = 'local'\nprint(i)\n", globals(), class_locals)
... 
>>> f()
global
local

If exec() worked like a function rather than a class, the first print(i) would trigger an UnboundLocalError instead:

>>> i = 'global'
>>> def f():
...     i = 'nonlocal'
...     def g():
...         print(i)
...         i = 'local'
...     g()
... 
>>> f()
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 6, in f
  File "", line 4, in g
UnboundLocalError: local variable 'i' referenced before assignment

In your first exec() example, i='nonlocal' is passed to exec() via the default locals parameter, and the exec() uses that value rather than deferring to its globals. To be a free variable, ?i? has to be used but not defined. Even if you dropped the ?i = 'local' ? assignment, it is still defined via the implicit locals parameter.

Your proposal for ?Interaction with dynamic features? sounds reasonable.

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 00:18:03 2016
From: report at bugs.python.org (Antony Lee)
Date: Sat, 30 Jan 2016 05:18:03 +0000
Subject: [docs] [issue26240] Docstring of the subprocess module should be
 cleaned up
Message-ID: <1454131083.41.0.870668221205.issue26240@psf.upfronthosting.co.za>


New submission from Antony Lee:

subprocess.__doc__ currently contains copies for the docstrings of a bunch of functions in the module (... but not subprocess.run).  The docs for the Popen class should be moved into that class' docstring.  The module's docstring also mentions the list2cmdline "method" (actually a function, and the qualifier "method"/"function" is missing the second time this function is mentioned ("The list2cmdline is designed ...")), but that function doesn't appear in `__all__` and thus not in the official HTML docs (yes, I know pydoc subprocess.list2cmdline works).

----------
assignee: docs at python
components: Documentation
messages: 259238
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Docstring of the subprocess module should be cleaned up
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 02:02:34 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 30 Jan 2016 07:02:34 +0000
Subject: [docs] [issue26240] Docstring of the subprocess module should be
 cleaned up
In-Reply-To: <1454131083.41.0.870668221205.issue26240@psf.upfronthosting.co.za>
Message-ID: <1454137354.88.0.550610978725.issue26240@psf.upfronthosting.co.za>


Martin Panter added the comment:

IMO the doc strings should be reduced down so that it is a concise summary, and divided or merged into doc strings of each class, method, function. Less important details should be moved to the main RST documentation (if they aren?t already there).

Regarding list2cmdline(), see the comment next to __all__ in the source code, and Issue 11827. BTW modifying __all__ would not automatically affect what is written in the RST files, which is where the ?official? HTML docs come from :)

----------
nosy: +martin.panter
stage:  -> needs patch
versions: +Python 2.7, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 04:43:12 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 30 Jan 2016 09:43:12 +0000
Subject: [docs] [issue26241] repr() and str() are identical for floats in 3.5
In-Reply-To: <1454145724.12.0.226148276857.issue26241@psf.upfronthosting.co.za>
Message-ID: <1454146992.27.0.512758296312.issue26241@psf.upfronthosting.co.za>


Martin Panter added the comment:

This discrepancy was supposed to be eliminated in 3.2; see Issue 9337. So assuming you are looking at the right version, it is the documentation that is at fault.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python, martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 04:58:55 2016
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 30 Jan 2016 09:58:55 +0000
Subject: [docs] [issue26241] repr() and str() are identical for floats in 3.5
In-Reply-To: <1454145724.12.0.226148276857.issue26241@psf.upfronthosting.co.za>
Message-ID: <1454147935.53.0.495553783626.issue26241@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> A test with a 100 million random and selected IEEE 64-bit values 
> returned no differences

The float type's tp_str and tp_repr both call float_repr in Objects/floatobject.c. See the 3.5.1 PyFloat_Type definition [1].

Perhaps you were reading something in reference to Python 2, which has separate float_str and float_repr functions. See the 2.7.11 PyFloat_Type definition [2] and the header file where PyFloat_STR_PRECISION is defined to be 12 digits [3].

[1]: https://hg.python.org/cpython/file/v3.5.1/Objects/floatobject.c#l1839
[2]: https://hg.python.org/cpython/file/v2.7.11/Objects/floatobject.c#l2118
[3]: https://hg.python.org/cpython/file/v2.7.11/Include/floatobject.h#l24

----------
nosy: +eryksun

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 05:19:32 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 30 Jan 2016 10:19:32 +0000
Subject: [docs] [issue26241] repr() and str() are identical for floats in 3.5
In-Reply-To: <1454145724.12.0.226148276857.issue26241@psf.upfronthosting.co.za>
Message-ID: <1454149172.48.0.365175398229.issue26241@psf.upfronthosting.co.za>


Changes by Mark Dickinson :


----------
nosy: +mark.dickinson

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 05:31:53 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 30 Jan 2016 10:31:53 +0000
Subject: [docs] [issue26241] repr() and str() are identical for floats in 3.5
In-Reply-To: <1454145724.12.0.226148276857.issue26241@psf.upfronthosting.co.za>
Message-ID: <1454149912.97.0.422988153887.issue26241@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Closing: as Martin pointed out, the behaviour is intentional, and without a reference to a particular part of the documentation this issue isn't useful. (Anders: if you find a part of the 3.5 documentation that does state that str and repr are different for floats, please feel free to re-open and link to that section of the documentation so that it can be fixed.)

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 09:23:20 2016
From: report at bugs.python.org (Anders Rundgren)
Date: Sat, 30 Jan 2016 14:23:20 +0000
Subject: [docs] [issue26241] repr() and str() are identical for floats in 3.5
In-Reply-To: <1454145724.12.0.226148276857.issue26241@psf.upfronthosting.co.za>
Message-ID: <1454163799.98.0.523943905762.issue26241@psf.upfronthosting.co.za>


Anders Rundgren added the comment:

Apparently the docs have changed since 2.7:
https://docs.python.org/3.5/tutorial/floatingpoint.html

However, the documentation still "sort of" mentions repr() as the most accurate form which isn't entirely correct since it nowadays is identical to str() for floats.

No big deal, I just thought I was doing something wrong :-)

related: http://bugs.python.org/issue26229

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 12:19:35 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 30 Jan 2016 17:19:35 +0000
Subject: [docs] [issue26209] TypeError in smtpd module with string arguments
In-Reply-To: <1453840478.59.0.371405366995.issue26209@psf.upfronthosting.co.za>
Message-ID: <1454174375.14.0.324756385558.issue26209@psf.upfronthosting.co.za>


Berker Peksag added the comment:

There is a strong change that smtpd is going to be deprecated in Python 3.6. See issue 25008 for details.

+1 for improving documentation.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
keywords: +easy
nosy: +berker.peksag, docs at python
stage:  -> needs patch
type: behavior -> enhancement
versions: +Python 2.7, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 12:26:28 2016
From: report at bugs.python.org (Alex Gaynor)
Date: Sat, 30 Jan 2016 17:26:28 +0000
Subject: [docs] [issue26242] reST formatting error in
 Doc/library/importlib.rst
Message-ID: <1454174788.27.0.0600197935954.issue26242@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

https://hg.python.org/cpython/file/default/Doc/library/importlib.rst#l1124

the spacing is wrong, it should be:

.. versionchanged:: 3.5

----------
assignee: docs at python
components: Documentation
messages: 259263
nosy: alex, docs at python, eric.araujo, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: reST formatting error in Doc/library/importlib.rst
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 12:30:09 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Jan 2016 17:30:09 +0000
Subject: [docs] [issue26242] reST formatting error in
 Doc/library/importlib.rst
In-Reply-To: <1454174788.27.0.0600197935954.issue26242@psf.upfronthosting.co.za>
Message-ID: <20160130173006.24931.87118@psf.io>


Roundup Robot added the comment:

New changeset 9a31895a1c9d by Berker Peksag in branch '3.5':
Issue #26242: Fix another one in importlib.rst
https://hg.python.org/cpython/rev/9a31895a1c9d

New changeset 5452e4b5c007 by Berker Peksag in branch 'default':
Issue #26242: Fix another one in importlib.rst
https://hg.python.org/cpython/rev/5452e4b5c007

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 12:32:39 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 30 Jan 2016 17:32:39 +0000
Subject: [docs] [issue26242] reST formatting error in
 Doc/library/importlib.rst
In-Reply-To: <1454174788.27.0.0600197935954.issue26242@psf.upfronthosting.co.za>
Message-ID: <1454175159.39.0.972352836185.issue26242@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I just fixed a similar one in 23cc4b894caf :) Thanks!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 13:48:48 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 30 Jan 2016 18:48:48 +0000
Subject: [docs] [issue26244] zlib.compressobj level default value
 documentation
Message-ID: <1454179728.88.0.137425597988.issue26244@psf.upfronthosting.co.za>


New submission from Aviv Palivoda:

In the zlib.compressobj documentation the default value of the compress level is -1 while it is actually 6.

patch is included

----------
assignee: docs at python
components: Documentation, Extension Modules
files: zlib-compressobj-level-doc.patch
keywords: patch
messages: 259267
nosy: docs at python, nadeem.vawda, palaviv, twouters
priority: normal
severity: normal
status: open
title: zlib.compressobj level default value documentation
versions: Python 3.6
Added file: http://bugs.python.org/file41761/zlib-compressobj-level-doc.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 16:00:40 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 30 Jan 2016 21:00:40 +0000
Subject: [docs] [issue26244] zlib.compressobj level default value
 documentation
In-Reply-To: <1454179728.88.0.137425597988.issue26244@psf.upfronthosting.co.za>
Message-ID: <1454187640.38.0.836688032273.issue26244@psf.upfronthosting.co.za>


Martin Panter added the comment:

I?m not sure that is perfectly correct. It really does default to -1, and that is passed to the underlying zlib library (-1 = Z_DEFAULT_COMPRESSION). It is the zlib library that decides that this means 6, but in theory I guess it could be configured or modified in the future with a different default. Perhaps we should clarify the text in the documentation (including the doc string) to say this instead?

At the very least, the documentation should continue to say that -1 is acceptable, and what it means.

----------
nosy: +martin.panter
stage:  -> patch review
versions: +Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 17:33:57 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 30 Jan 2016 22:33:57 +0000
Subject: [docs] [issue26241] repr() and str() are identical for floats in 3.5
In-Reply-To: <1454145724.12.0.226148276857.issue26241@psf.upfronthosting.co.za>
Message-ID: <1454193237.61.0.367095472821.issue26241@psf.upfronthosting.co.za>


Changes by Eric V. Smith :


----------
nosy: +eric.smith

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jan 30 21:07:41 2016
From: report at bugs.python.org (Patrik Dufresne)
Date: Sun, 31 Jan 2016 02:07:41 +0000
Subject: [docs] [issue24110] zipfile.ZipFile.write() does not accept bytes
 arcname
In-Reply-To: <1430515803.94.0.193757537296.issue24110@psf.upfronthosting.co.za>
Message-ID: <1454206061.09.0.894529134407.issue24110@psf.upfronthosting.co.za>


Patrik Dufresne added the comment:

Manage to work around this issue by using surrogateescape for arcname and filename. For me it's no longer an issue.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 05:05:17 2016
From: report at bugs.python.org (Liang Bo Wang)
Date: Sun, 31 Jan 2016 10:05:17 +0000
Subject: [docs] [issue26246] Code output toggle button uses removed jQuery
 method
Message-ID: <1454234717.37.0.159058452495.issue26246@psf.upfronthosting.co.za>


New submission from Liang Bo Wang:

The code output toggle button (the `>>>` button on the top right) has been disappeared and not functional on the current online documentation (both 3.4+ and 2.7). 


For example, see any doc page that has interpreter outputs:

    https://docs.python.org/3/tutorial/introduction.html#numbers
    https://docs.python.org/3.5/tutorial/introduction.html#numbers
    https://docs.python.org/3.4/tutorial/introduction.html#numbers
    https://docs.python.org/2/tutorial/introduction.html#numbers


These toggle buttons are created dynamically using jQuery by the script at Doc/tools/static/copybutton.js. However, the method .toggle() it used for click event handling has been deprecated since jQuery 1.8 and removed since jQuery 1.9.

    https://api.jquery.com/toggle-event/


Current Python documentation ships with jQuery v1.11.1 and it has a new .toggle() method with totally different behavior, which controls animation and hide the element. Therefore those buttons are invisible and has no effect.

    https://api.jquery.com/toggle/


To achieve the old behavior, one now needs to create this toggle event on one's own. The most popular way to store the toggle state is by jQuery's .data() data storage.

A patch is attached to make the button functional again.

----------
assignee: docs at python
components: Documentation
files: copybutton_js.patch
keywords: patch
messages: 259279
nosy: Liang Bo Wang, docs at python, eric.araujo, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: Code output toggle button uses removed jQuery method
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41764/copybutton_js.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 09:23:21 2016
From: report at bugs.python.org (Ismail s)
Date: Sun, 31 Jan 2016 14:23:21 +0000
Subject: [docs] [issue26247] Document Chrome/Chromium for python2.7
Message-ID: <1454250201.34.0.379638558981.issue26247@psf.upfronthosting.co.za>


New submission from Ismail s:

The table of browser types in https://docs.python.org/2.7/library/webbrowser.html?highlight=webbrowser#webbrowser.register does not say that Google Chrome/Chromium is available on python2.7, even though it is (https://hg.python.org/cpython/file/2.7/Lib/webbrowser.py#l307).

Also, according to the docs for python.3.5 (https://docs.python.org/3.5/library/webbrowser.html?highlight=webbrowser#webbrowser.register , just below the table), support for google chrome/chromium was added in python3.3, so maybe this was backported to python2.7 and the docs not updated?

----------
assignee: docs at python
components: Documentation
messages: 259280
nosy: Ismail s, docs at python
priority: normal
severity: normal
status: open
title: Document Chrome/Chromium for python2.7
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 09:37:52 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 31 Jan 2016 14:37:52 +0000
Subject: [docs] [issue26247] Document Chrome/Chromium for python2.7
In-Reply-To: <1454250201.34.0.379638558981.issue26247@psf.upfronthosting.co.za>
Message-ID: <1454251072.5.0.0175937518888.issue26247@psf.upfronthosting.co.za>


SilentGhost added the comment:

It's due to issue 17536 and particularly 5a1429e9b621
I presume doko would be happy to follow up on that.

----------
nosy: +SilentGhost, doko

_______________________________________
Python tracker 

_______________________________________

From founder at ten3.org  Fri Jan 29 23:03:03 2016
From: founder at ten3.org (Anthony Petrillo)
Date: Fri, 29 Jan 2016 23:03:03 -0500
Subject: [docs] making a python doc build available in Africa where there is
 no internet
Message-ID: 

Greetings,

I've been working with African educators teaching computers since the late
1980s. We work in areas that often do not have internet and even when it is
available most of the schools and students can't afford extensive use. (FYI
we use Wary Puppy Linux on old machines so more machines can be provided.)

We are developing a Python course and would like to do intersphinx with
your documentation on a local copy.

Would it be possible to get a copy of one of your build directories (or
whatever you call them) for Python 3.3, 3.4 or 3.5. We do not need them
all. Just one.

Thank you for considering this request.

Best regards,
Anthony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From senthil at uthcode.com  Sun Jan 31 10:05:02 2016
From: senthil at uthcode.com (Senthil Kumaran)
Date: Sun, 31 Jan 2016 07:05:02 -0800
Subject: [docs] making a python doc build available in Africa where
 there is no internet
In-Reply-To: 
References: 
Message-ID: 

On Fri, Jan 29, 2016 at 8:03 PM, Anthony Petrillo  wrote:

> Would it be possible to get a copy of one of your build directories (or
> whatever you call them) for Python 3.3, 3.4 or 3.5. We do not need them
> all. Just one.


Here you can download these:

https://docs.python.org/3/download.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From report at bugs.python.org  Sun Jan 31 11:43:42 2016
From: report at bugs.python.org (Ben Hoyt)
Date: Sun, 31 Jan 2016 16:43:42 +0000
Subject: [docs] [issue26248] Improve scandir DirEntry docs,
 especially re symlinks and caching
Message-ID: <1454258622.6.0.285150622743.issue26248@psf.upfronthosting.co.za>


New submission from Ben Hoyt:

Per Guido's comment about DirEntry documentation on Issue 26032, especially http://bugs.python.org/issue26032#msg257665, it'd be good to improve the docs of the scandir DirEntry methods with regard to symlinks and caching.

Attaching my stab at a documentation fix. Changes here are:

1) Clarify that the return values of is_dir()/is_file()/etc are cached separately for follow_symlinks True and False.
2) Be more specific about when the functions require a system call, and how it relates to caching and follow_symlinks.
3) DRY up common stuff between is_dir and is_file by saying "Caching, system calls made, and exceptions raised are as per is_dir" in is_file.
4) Tweak to the first paragraph of docs for is_dir/is_file to simplify: assume the follow_symlinks=True default, then note the follow_symlinks=False non-default case after.

I think they're all improvements, though I'm not sure about #3. Is it better to just repeat those couple of paragraphs verbatim?

I'm also not 100% sure about mentioning the DT_UNKNOWN thing. But you really can't get more specific about when system calls are required on Unix without mentioning it.

----------
assignee: docs at python
components: Documentation
files: direntry_doc_improvements.patch
keywords: patch
messages: 259282
nosy: benhoyt, docs at python, gvanrossum, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Improve scandir DirEntry docs, especially re symlinks and caching
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41765/direntry_doc_improvements.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 12:37:46 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 31 Jan 2016 17:37:46 +0000
Subject: [docs] [issue26248] Improve scandir DirEntry docs,
 especially re symlinks and caching
In-Reply-To: <1454258622.6.0.285150622743.issue26248@psf.upfronthosting.co.za>
Message-ID: <20160131173741.58302.64076@psf.io>


Roundup Robot added the comment:

New changeset f2c68cb17e31 by Victor Stinner in branch '3.5':
Enhance os.scandir() doc
https://hg.python.org/cpython/rev/f2c68cb17e31

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 12:40:25 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2016 17:40:25 +0000
Subject: [docs] [issue26248] Improve scandir DirEntry docs,
 especially re symlinks and caching
In-Reply-To: <1454258622.6.0.285150622743.issue26248@psf.upfronthosting.co.za>
Message-ID: <1454262025.73.0.584824408725.issue26248@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The change looks good to me. I pushed it to 3.5 & 3.6. It will be online in a few hours at:
https://docs.python.org/dev/library/os.html#os.DirEntry

I keep the issue open a few days to see if some others have other suggestions.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 12:43:24 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sun, 31 Jan 2016 17:43:24 +0000
Subject: [docs] [issue26244] zlib.compressobj level default value
 documentation
In-Reply-To: <1454179728.88.0.137425597988.issue26244@psf.upfronthosting.co.za>
Message-ID: <1454262204.27.0.596350751521.issue26244@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

I think that we can leave the level=-1 as the default in the documentation. What should be added is what Z_DEFAULT_COMPRESSION means.
I tried to be as close as possible to the zlib module documentation.

----------
Added file: http://bugs.python.org/file41766/zlib-compressobj-level-doc2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jan 31 17:00:18 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 31 Jan 2016 22:00:18 +0000
Subject: [docs] [issue26244] zlib.compressobj level default value
 documentation
In-Reply-To: <1454179728.88.0.137425597988.issue26244@psf.upfronthosting.co.za>
Message-ID: <1454277618.44.0.110881336818.issue26244@psf.upfronthosting.co.za>


Martin Panter added the comment:

This version looks great to me.

----------
versions: +Python 2.7

_______________________________________
Python tracker 

_______________________________________