From report at bugs.python.org Fri Apr 1 00:53:44 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 01 Apr 2016 04:53:44 +0000 Subject: [docs] [issue26683] Questionable terminology for describing what locals() does In-Reply-To: <1459474292.87.0.515226107717.issue26683@psf.upfronthosting.co.za> Message-ID: <1459486424.89.0.597390584648.issue26683@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > A national variable maybe :) I would think that "nonlocal" is exactly the right term given that that is how you would declare it if you wanted to write to it. >>> w = 5 >>> def f(x): def g(y): nonlocal x global w z = x + y x += 1 print(locals()) print(globals()) return g >>> f(10)(20) {'y': 20, 'x': 11, 'z': 30} {'w': 5, ...} ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 1 05:14:57 2016 From: report at bugs.python.org (Andy Maier) Date: Fri, 01 Apr 2016 09:14:57 +0000 Subject: [docs] [issue26678] Incorrect linking to elements in datetime package In-Reply-To: <1459445799.81.0.161788997927.issue26678@psf.upfronthosting.co.za> Message-ID: <1459502097.3.0.909175874189.issue26678@psf.upfronthosting.co.za> Andy Maier added the comment: Hi Martin! The intersphinx stuff is simply linking from a Sphinx RST documentation to a different Sphinx RST documentation, using support from the intersphinx extension of Sphinx. I think the name comes from the interwiki links in MediaWiki. It only comes into play here because my particular documentation is outside of the Python documentation. The same issues would arise when linking from other places in the Python documentation. Your explanation about :noindex: hits the nail on the head, I think. It seems to me that a minimal variant for fixing this would be: * add :noindex: to the class markup for the short descriptions of tzinfo and timezone. * add a class markup for tzinfo at its long description. I don't know whether that solves the method linking issue, though, but its worth a try. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 1 07:45:09 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 01 Apr 2016 11:45:09 +0000 Subject: [docs] [issue26678] Incorrect linking to elements in datetime package In-Reply-To: <1459445799.81.0.161788997927.issue26678@psf.upfronthosting.co.za> Message-ID: <1459511109.1.0.18463087272.issue26678@psf.upfronthosting.co.za> Martin Panter added the comment: I?m happy to make those two minimal changes (:noindex: and tzinfo class), but I have a feeling they won?t help your problem linking to datetime.tzinfo.utcoffset() and dst(). The markup for those methods already generates index entries, see for instance. ---------- _______________________________________ Python tracker _______________________________________ From g.brandl at gmx.net Fri Apr 1 08:11:19 2016 From: g.brandl at gmx.net (Georg Brandl) Date: Fri, 1 Apr 2016 14:11:19 +0200 Subject: [docs] Submitting an article/paper on CPython's Private Heap In-Reply-To: References: Message-ID: <56FE6567.2030405@gmx.net> On 03/31/2016 05:44 PM, J.E. Ogden wrote: > Recently I had to dig into cpython's private memory heap (there wasn't much > current, detailed information I could find outside of the the source) and > decided to put what I learned into an article/paper on the topic. > > I was wondering: a) where's the appropriate place to contribute it, and b) could > someone with cpython development experience proof/review it? > > (Because it has a number of diagrams, formated text, footnotes etc. it's > currently only presentable in pdf format.) > > thanks, > jon Hi Jon, please discuss this on the python-dev list; it has all the experts who might be able to review. Once you are in agreement about including it into the docs, we'll see how to adapt the format, which shouldn't be too hard (diagrams and footnotes are fine, even if they aren't used much). cheers, Georg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From report at bugs.python.org Fri Apr 1 11:39:33 2016 From: report at bugs.python.org (Andy Maier) Date: Fri, 01 Apr 2016 15:39:33 +0000 Subject: [docs] [issue26678] Incorrect linking to elements in datetime package In-Reply-To: <1459445799.81.0.161788997927.issue26678@psf.upfronthosting.co.za> Message-ID: <1459525173.75.0.316832616541.issue26678@psf.upfronthosting.co.za> Andy Maier added the comment: Ok. If these methods generate index entries, maybe the problem is on my side by not linking them correctly. So let's try with the other two changes. Unfortunately, I cannot easily build cpython at the moment to verify, I moved to Linux and when trying to build cpython, bash rejects the configure script because of trailing CR characters. This is a freshly installed hg package on Ubuntu 14.04, against a fresh clone of the cpython repo. Any idea what is happening there? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 1 11:43:47 2016 From: report at bugs.python.org (SilentGhost) Date: Fri, 01 Apr 2016 15:43:47 +0000 Subject: [docs] [issue26679] curses: Descripton of KEY_NPAGE and KEY_PPAGE inverted In-Reply-To: <1459452822.7.0.402599297468.issue26679@psf.upfronthosting.co.za> Message-ID: <1459525427.89.0.323277832251.issue26679@psf.upfronthosting.co.za> SilentGhost added the comment: Here is the patch. ---------- nosy: +SilentGhost stage: -> patch review type: enhancement -> behavior Added file: http://bugs.python.org/file42344/issue26679.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 1 14:24:59 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 01 Apr 2016 18:24:59 +0000 Subject: [docs] [issue26683] Questionable terminology for describing what locals() does In-Reply-To: <1459474292.87.0.515226107717.issue26683@psf.upfronthosting.co.za> Message-ID: <1459535099.79.0.193181068981.issue26683@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I requested that we stop (mis)using 'free variable' in the docs years ago. A strong +1 from me. The 'locals' function what named when 'local' and 'non-global' were synonyms. When non-local, non-global names were added, nonlocals were included with 'locals' as 'non-global'. (This must have been thought to be more useful than adding nonlocals() or excluding them.) They are, of course, local in some surrounding non-global context. And for most purposes, their entries in locals() should also be treated as read-only. I think the doc should say that function locals() includes the locals of surrounding function contexts, even though they are called 'nonlocal' within the nested function. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 1 16:39:29 2016 From: report at bugs.python.org (Ashley Anderson) Date: Fri, 01 Apr 2016 20:39:29 +0000 Subject: [docs] [issue26688] unittest2 referenced in unittest.mock documentation Message-ID: <1459543169.0.0.250942982333.issue26688@psf.upfronthosting.co.za> New submission from Ashley Anderson: I noticed a few references to `unittest2` in the documentation in the `unittest.mock` "getting started" section: https://docs.python.org/3.6/library/unittest.mock-examples.html#patch-decorators I am attaching a patch that just changes these occurrences from `unittest2` to `unittest`. ---------- assignee: docs at python components: Documentation files: unittest2.patch keywords: patch messages: 262767 nosy: aganders3, docs at python priority: normal severity: normal status: open title: unittest2 referenced in unittest.mock documentation versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file42346/unittest2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 1 20:03:30 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 Apr 2016 00:03:30 +0000 Subject: [docs] [issue26678] Incorrect linking to elements in datetime package In-Reply-To: <1459445799.81.0.161788997927.issue26678@psf.upfronthosting.co.za> Message-ID: <20160402000327.28271.12111.9679B7B4@psf.io> Roundup Robot added the comment: New changeset 30e077f886cc by Martin Panter in branch '3.5': Issue #26678: Fix indexing of datetime.tzinfo and timezone classes https://hg.python.org/cpython/rev/30e077f886cc New changeset 854db1a2cd98 by Martin Panter in branch 'default': Issue #26678: Merge datetime doc fixes from 3.5 https://hg.python.org/cpython/rev/854db1a2cd98 New changeset 4cad272cec82 by Martin Panter in branch '2.7': Issue #26678: Fix datetime.tzinfo indexing and ?tzinfo? attribute links https://hg.python.org/cpython/rev/4cad272cec82 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 1 20:24:16 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 02 Apr 2016 00:24:16 +0000 Subject: [docs] [issue26678] Incorrect linking to elements in datetime package In-Reply-To: <1459445799.81.0.161788997927.issue26678@psf.upfronthosting.co.za> Message-ID: <1459556655.96.0.309797999635.issue26678@psf.upfronthosting.co.za> Martin Panter added the comment: Can you link to other methods? E.g. try io.IOBase.close(), which is done the normal way as a method indented under its class, and nntplib.NNTP.quit(), which is listed separately from its class definition. Regarding CRLFs in ?configure?, all I can guess is some strange Mercurial user configuration. Maybe you can work around it by using the ?dos2unix? command, or rebuilding the script with ?autoreconf?. ---------- versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 1 21:32:27 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 Apr 2016 01:32:27 +0000 Subject: [docs] [issue26688] unittest2 referenced in unittest.mock documentation In-Reply-To: <1459543169.0.0.250942982333.issue26688@psf.upfronthosting.co.za> Message-ID: <20160402013223.9986.14540.43FCA12C@psf.io> Roundup Robot added the comment: New changeset 73279e4a1107 by Berker Peksag in branch '3.5': Issue #26688: Fix module name in mock docs https://hg.python.org/cpython/rev/73279e4a1107 New changeset 24efe844e598 by Berker Peksag in branch 'default': Issue #26688: Fix module name in mock docs https://hg.python.org/cpython/rev/24efe844e598 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 1 21:34:19 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 02 Apr 2016 01:34:19 +0000 Subject: [docs] [issue26688] unittest2 referenced in unittest.mock documentation In-Reply-To: <1459543169.0.0.250942982333.issue26688@psf.upfronthosting.co.za> Message-ID: <1459560859.41.0.43386437561.issue26688@psf.upfronthosting.co.za> Berker Peksag added the comment: Good catch, thanks Ashley! 3.3 and 3.4 are in security-fix-only mode so we don't fix documentation issues in those branches. ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 1 21:48:48 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 02 Apr 2016 01:48:48 +0000 Subject: [docs] [issue26679] curses: Descripton of KEY_NPAGE and KEY_PPAGE inverted In-Reply-To: <1459452822.7.0.402599297468.issue26679@psf.upfronthosting.co.za> Message-ID: <20160402014844.9980.29226.7416B3E6@psf.io> Roundup Robot added the comment: New changeset f41d3321007f by Berker Peksag in branch '3.5': Issue #26679: Fix description of KEY_PPAGE and KEY_NPAGE constants https://hg.python.org/cpython/rev/f41d3321007f New changeset 23d986228c6b by Berker Peksag in branch 'default': Issue #26679: Fix description of KEY_PPAGE and KEY_NPAGE constants https://hg.python.org/cpython/rev/23d986228c6b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 1 21:50:38 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 02 Apr 2016 01:50:38 +0000 Subject: [docs] [issue26679] curses: Descripton of KEY_NPAGE and KEY_PPAGE inverted In-Reply-To: <1459452822.7.0.402599297468.issue26679@psf.upfronthosting.co.za> Message-ID: <1459561838.66.0.943453023172.issue26679@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks, Robert and SilentGhost. I verified the patch with the following script: import curses def main(stdscr): while True: c = stdscr.getch() if c == curses.KEY_PPAGE: stdscr.addstr('Page Up') elif c == curses.KEY_NPAGE: stdscr.addstr('Page Down') else: stdscr.addstr('Another key') curses.wrapper(main) ---------- nosy: +berker.peksag resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 2 01:45:19 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 02 Apr 2016 05:45:19 +0000 Subject: [docs] [issue5901] missing meta-info in documentation pdf In-Reply-To: <1241246578.79.0.771794251259.issue5901@psf.upfronthosting.co.za> Message-ID: <1459575919.82.0.443678822367.issue5901@psf.upfronthosting.co.za> Berker Peksag added the comment: I get the following output when I try Python 3.5.1 docs: $ pdfinfo using.pdf Title: Subject: Keywords: Author: Creator: LaTeX with hyperref package Producer: pdfTeX-1.40.14 CreationDate: Sat Apr 2 00:17:54 2016 ModDate: Sat Apr 2 00:17:54 2016 Tagged: no Pages: 69 Encrypted: no Page size: 595.276 x 841.89 pts (A4) File size: 368343 bytes Optimized: no PDF version: 1.5 ---------- nosy: +berker.peksag stage: -> needs patch type: resource usage -> behavior versions: +Python 3.5, Python 3.6 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 2 07:16:19 2016 From: report at bugs.python.org (Andy Maier) Date: Sat, 02 Apr 2016 11:16:19 +0000 Subject: [docs] [issue26678] Incorrect linking to elements in datetime package In-Reply-To: <1459445799.81.0.161788997927.issue26678@psf.upfronthosting.co.za> Message-ID: <1459595779.74.0.757769213297.issue26678@psf.upfronthosting.co.za> Andy Maier added the comment: Martin, I can now link to the two methods e.g. via :meth:`py:datetime.tzinfo.utcoffset`, and it resolves nicely. See here (linking to Python 2): https://pywbem.readthedocs.org/en/latest/#pywbem.MinutesFromUTC Don't know why it now works, probably user error I would say. Your change is still appreciated, and it would be great if it could also go into Python 2.7 :-) Hope I'm not asking for too much. On Python build: hg config problem sounds like a good path. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 2 07:29:18 2016 From: report at bugs.python.org (Andy Maier) Date: Sat, 02 Apr 2016 11:29:18 +0000 Subject: [docs] [issue26678] Incorrect linking to elements in datetime package In-Reply-To: <1459445799.81.0.161788997927.issue26678@psf.upfronthosting.co.za> Message-ID: <1459596558.34.0.193481848571.issue26678@psf.upfronthosting.co.za> Andy Maier added the comment: Martin, I just noticed that your fix must already be active. My link to tzinfo now lands on the long description. So maybe it was not a user error of mine that resolved the problem with the two methods (I was pretty sure I had tried the same syntax I use now), but whatever did the trick in your change. Anyway, thanks much for this quick turnaround!! Andy ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 2 19:29:15 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 02 Apr 2016 23:29:15 +0000 Subject: [docs] [issue26678] Incorrect linking to elements in datetime package In-Reply-To: <1459445799.81.0.161788997927.issue26678@psf.upfronthosting.co.za> Message-ID: <1459639755.38.0.234120226378.issue26678@psf.upfronthosting.co.za> Martin Panter added the comment: That?s good news. I did not expect it, but I seem to have fixed the problem anyway. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 3 06:35:01 2016 From: report at bugs.python.org (Samuel Colvin) Date: Sun, 03 Apr 2016 10:35:01 +0000 Subject: [docs] [issue26479] Init documentation typo "may be return" > "may NOT be returned" In-Reply-To: <1457097258.8.0.064409213234.issue26479@psf.upfronthosting.co.za> Message-ID: <1459679701.69.0.400503142333.issue26479@psf.upfronthosting.co.za> Samuel Colvin added the comment: Sorry, I'm going mad, misread it. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 3 22:16:05 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 04 Apr 2016 02:16:05 +0000 Subject: [docs] [issue24911] Context manager of socket.socket is not documented In-Reply-To: <1440189246.69.0.0632097129757.issue24911@psf.upfronthosting.co.za> Message-ID: <1459736164.74.0.472084672536.issue24911@psf.upfronthosting.co.za> Martin Panter added the comment: FWIW I discovered that socket.close() or __exit__() does not actually raise exceptions for cases like EBADF, see Issue 26685. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 5 03:27:03 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 05 Apr 2016 07:27:03 +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: <1459841221.82.0.624229794419.issue9694@psf.upfronthosting.co.za> Martin Panter added the comment: Posting argparse_option.v2.patch, which is minimally complete version of Ryan?s patch. I have dropped all the nonessential code and documentation tweaks. I also added a What?s New entry. I?d like to know if people think this is the right direction to move in. ---------- versions: -Python 2.7, Python 3.5 Added file: http://bugs.python.org/file42370/argparse_option.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 5 06:31:45 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 05 Apr 2016 10:31:45 +0000 Subject: [docs] [issue10796] Improve doc for readline.set_completer_delims() In-Reply-To: <1293714489.48.0.717157988045.issue10796@psf.upfronthosting.co.za> Message-ID: <20160405103134.94590.49662.9C9A0E48@psf.io> Roundup Robot added the comment: New changeset 6137c46cb8df by Martin Panter in branch '2.7': Issue #6953: Rearrange and expand Readline module documentation https://hg.python.org/cpython/rev/6137c46cb8df New changeset b1acd6cf15b6 by Martin Panter in branch '3.5': Issue #6953: Rearrange and expand Readline module documentation https://hg.python.org/cpython/rev/b1acd6cf15b6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 5 11:01:46 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 05 Apr 2016 15:01:46 +0000 Subject: [docs] [issue26695] pickle and _pickle accelerator have different behavior when unpickling an object with falsy __getstate__ return Message-ID: <1459868506.3.0.857595967516.issue26695@psf.upfronthosting.co.za> New submission from Josh Rosenberg: According to a note on the pickle docs ( https://docs.python.org/3/library/pickle.html#object.__getstate__ ): "If __getstate__() returns a false value, the __setstate__() method will not be called upon unpickling." The phrasing is a little odd (since according to the __setstate__ docs, there is a behavior for classes without __setstate__ where it just assigns the contents of the pickled state dict to the __dict__ of the object), but to me, this means that any falsy value should prevent any __setstate__-like behavior. But this is not how it works. Both the C accelerator and Python code treat None specially (they don't pickle state at all if it's None), which prevents __setstate__ or the __setstate__-like fallback from being executed. But if it's any other falsy value, the behaviors differ, and diverge from the docs. Specifically, on load of a pickle with a non-None falsy state (say, False itself, or 0, or () or []): Without __setstate__: Pure Python pickle: Does not execute fallback code, behaves as expected (it just stored state it will never use), matching spirit of docs C accelerated _pickle: Fails on anything but the empty dict with an UnpicklingError: state is not a dictionary, violating spirit of docs With __setstate__: Both versions call __setstate__ even though the documentation explicitly says they will not. Seems like if nothing else, the docs should agree with the code, and the C and Python modules should agree on behavior. I would not be at all surprised if outside code depends on being able to pickle falsy state and have its __setstate__ receive the falsy state (if nothing else, when the state is a container or number, being empty or 0 would be reasonable; failing to call __setstate__ in that case would be surprising). So it's probably not a good idea to make the implementation match the docs. My proposal would be that at pickle time, if the class lacks __setstate__, treat any falsy return value as None. This means: 1. pickles are smaller (no storing junk that the default __setstate__-like behavior can't use) 2. pickles are valid (no UnpicklingError from the default __setstate__-like behavior) The docs would also have to change, to indicate that, if defined, __setstate__ will be called even if __getstate__ returned a falsy (but not None) value. Downside is the description of what happens is a little complex, since the behavior for non-None falsy values differs depending on the presence of a real __setstate__. Upside is that any code depending on the current behavior of falsy state being passed to __setstate__ keeps working, CPython and other interpreters will match behavior, and classes without __setstate__ will have smaller pickles. ---------- assignee: docs at python components: Documentation messages: 262908 nosy: docs at python, josh.r priority: normal severity: normal status: open title: pickle and _pickle accelerator have different behavior when unpickling an object with falsy __getstate__ return 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 Apr 5 14:39:13 2016 From: report at bugs.python.org (Brett Cannon) Date: Tue, 05 Apr 2016 18:39:13 +0000 Subject: [docs] [issue26696] Document collections.abc.ByteString In-Reply-To: <1459881544.79.0.834895685887.issue26696@psf.upfronthosting.co.za> Message-ID: <1459881553.12.0.984241410408.issue26696@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> docs at python components: +Documentation -Library (Lib) nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 5 18:23:53 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 05 Apr 2016 22:23:53 +0000 Subject: [docs] [issue10796] Improve doc for readline.set_completer_delims() In-Reply-To: <1293714489.48.0.717157988045.issue10796@psf.upfronthosting.co.za> Message-ID: <1459895033.77.0.905339278962.issue10796@psf.upfronthosting.co.za> Martin Panter added the comment: My update includes a new section called Completion, with the following text: By default, Readline is set up to be used by ?rlcompleter? to complete Python identifiers for the interactive interpreter. If the ?readline? module is to be used with a custom completer, a different set of word delimiters should be set. I hope that is enough to call this fixed :) ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed versions: +Python 3.5, Python 3.6 -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 6 03:29:49 2016 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 06 Apr 2016 07:29:49 +0000 Subject: [docs] [issue26699] locale.str docstring is incorrect: "Convert float to integer" Message-ID: <1459927789.02.0.138982751213.issue26699@psf.upfronthosting.co.za> New submission from Mark Dickinson: [Observed by one of my colleagues] The locale.str docstring currently looks like this (and apparently has been this way since the dawn of time): def str(val): """Convert float to integer, taking the locale into account.""" The output of str doesn't *look* like an integer on my machine. :-) Python 2.7.10 |Master 2.1.0.dev1829 (64-bit)| (default, Oct 21 2015, 09:09:19) [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.6)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.setlocale(locale.LC_NUMERIC, 'fr_FR') 'fr_FR' >>> locale.str(34.56) '34,56' ---------- assignee: docs at python components: Documentation keywords: easy messages: 262936 nosy: docs at python, mark.dickinson priority: normal severity: normal stage: needs patch status: open title: locale.str docstring is incorrect: "Convert float to integer" type: behavior versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 6 05:01:52 2016 From: report at bugs.python.org (Robert Smallshire) Date: Wed, 06 Apr 2016 09:01:52 +0000 Subject: [docs] [issue26701] Documentation for int constructor mentions __int__ but not __trunc__ Message-ID: <1459933312.1.0.479151701513.issue26701@psf.upfronthosting.co.za> New submission from Robert Smallshire: The documentation for the int(x) constructor explains that if possible, it delegates to x.__int__(). The documentation does not explain that there is a fallback to x.__trunc__() if x.__int__() is not available. The only mention of __trunc__ in the Python documentation is in the entry for math.trunc; the documentation for the numbers module does not describe the underlying special methods. Given that all Real numbers are required to implement __trunc__ but only Integral subclasses are required to implement __int__ this could be important to implementers of other Real types, although in practice I imagine that most Real types will implement __int__ as float does. ---------- assignee: docs at python components: Documentation messages: 262941 nosy: Robert Smallshire2, docs at python priority: normal severity: normal status: open title: Documentation for int constructor mentions __int__ but not __trunc__ type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From andrew.mcfarland at outlook.com Wed Apr 6 06:42:16 2016 From: andrew.mcfarland at outlook.com (Andrew McFarland) Date: Wed, 6 Apr 2016 12:42:16 +0200 Subject: [docs] Possible typo in docs Message-ID: page in question: https://docs.python.org/2/library/heapq.html section: 8.4.2. Priority Queue Implementation Notes Currently: def remove_task(task): 'Mark an existing task as REMOVED. Raise KeyError if not found.' entry = entry_finder.pop(task) entry[-1] = REMOVED As it stands, 'task' is removed from dictionary 'entry_finder' and never replaced which is not the intention in my opinion. Possible fixes: 1.def remove_task(task): 'Mark an existing task as REMOVED. Raise KeyError if not found.' entry = entry_finder.pop(task) entry[-1] = REMOVED entry_finder[task] = entry 2.def remove_task(task): 'Mark an existing task as REMOVED. Raise KeyError if not found.' entry_finder[task][-1] = REMOVED Sincerely,AM -------------- next part -------------- An HTML attachment was scrubbed... URL: From report at bugs.python.org Wed Apr 6 09:53:46 2016 From: report at bugs.python.org (R. David Murray) Date: Wed, 06 Apr 2016 13:53:46 +0000 Subject: [docs] [issue26701] Documentation for int constructor mentions __int__ but not __trunc__ In-Reply-To: <1459933312.1.0.479151701513.issue26701@psf.upfronthosting.co.za> Message-ID: <1459950826.6.0.641384950146.issue26701@psf.upfronthosting.co.za> R. David Murray added the comment: It is documented in the relevant PEP (pep 3141), but should indeed be added to the appropriate places in the regular documentation. ---------- nosy: +r.david.murray versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 6 16:36:27 2016 From: report at bugs.python.org (Shaun Walbridge) Date: Wed, 06 Apr 2016 20:36:27 +0000 Subject: [docs] [issue26706] Update OpenSSL version in readme Message-ID: <1459974987.74.0.0926215654006.issue26706@psf.upfronthosting.co.za> New submission from Shaun Walbridge: Sync documentation with the OpenSSL version update (1.0.2g vs 1.0.2f). Mismatch present in both head and 3.5 branch. ---------- assignee: docs at python components: Documentation files: readme-openssl.diff keywords: patch messages: 262964 nosy: docs at python, scw priority: normal severity: normal status: open title: Update OpenSSL version in readme type: enhancement versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file42383/readme-openssl.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 6 18:12:00 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 06 Apr 2016 22:12:00 +0000 Subject: [docs] [issue26703] Socket state corrupts when original socket object goes out of scope in a different thread In-Reply-To: <1459966025.84.0.875779742702.issue26703@psf.upfronthosting.co.za> Message-ID: <1459980720.64.0.263892201581.issue26703@psf.upfronthosting.co.za> Martin Panter added the comment: The documentation already says ?Sockets are automatically closed when they are garbage-collected?. If for some reason you want to release a socket object but keep the file descriptor open, I suggest socket.detach(). Otherwise, pass the original socket, not the fileno. I think this is at best a documentation issue, if you have any suggestions. ---------- assignee: -> docs at python components: +Documentation -IO nosy: +docs at python, martin.panter type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 6 18:15:24 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 06 Apr 2016 22:15:24 +0000 Subject: [docs] [issue26703] Socket state corrupts when original socket object goes out of scope in a different thread In-Reply-To: <1459966025.84.0.875779742702.issue26703@psf.upfronthosting.co.za> Message-ID: <1459980924.87.0.555219016932.issue26703@psf.upfronthosting.co.za> Martin Panter added the comment: Also, if you enable warnings (e.g. python -Wall), you should see that the socket is being closed: -c:22: ResourceWarning: unclosed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 6 20:32:36 2016 From: report at bugs.python.org (JoshN) Date: Thu, 07 Apr 2016 00:32:36 +0000 Subject: [docs] [issue26703] Socket state corrupts when original socket object goes out of scope in a different thread In-Reply-To: <1459966025.84.0.875779742702.issue26703@psf.upfronthosting.co.za> Message-ID: <1459989155.42.0.380872594554.issue26703@psf.upfronthosting.co.za> JoshN added the comment: I do understand that the docs are a bit strange on the issue. For example, actually testing the line you referenced ("...fileno will return the same socket and not a duplicate.") by creating 2 sockets and testing sameness with the 'is' operator returns false. I tried to trim the example code as much as possible - I did test disabling the garbage collector, playing with inheritance, etc, but trimmed them out as they didn't have any effect on my system. I think my main issue was, when this occurs, the socket 'breaks' as you mentioned instead of closing. Was almost sure it was a bug. Using detach works for this UDP example, but I wasn't sure if detaching the socket actually closes it (e.g. in a stream oriented connection). So this is considered normal behavior then? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 6 22:24:45 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 07 Apr 2016 02:24:45 +0000 Subject: [docs] [issue26703] Socket state corrupts when original socket object goes out of scope in a different thread In-Reply-To: <1459966025.84.0.875779742702.issue26703@psf.upfronthosting.co.za> Message-ID: <1459995885.51.0.139925107129.issue26703@psf.upfronthosting.co.za> Martin Panter added the comment: Yes, I think this is the expected behaviour, and I can?t think of any improvements that could be made. If you call fileno(), you have to ensure that you don?t close the file descriptor until you have finished using it. It is a bit like accessing memory after it has been freed. Python doesn?t make raw memory addresses easily accessible, but it does make fileno() accessible without much protection. Perhaps there is some confusion about the term socket. Normally (without using the fileno=... parameter), Python?s socket() constructor does two things. First, it creates a new OS socket using the socket() system call (or Winsock equivalent), which returns a file descriptor or handle (an integer). Then, it creates a Python socket object, which wraps the file descriptor. When you use socket(fileno=...), only the second step is taken. You get a _new_ socket object, which wraps the given existing OS socket file descriptor. So when it says ?the same socket?, I think it means the same OS-level socket. It still creates a new Python object. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 7 02:44:52 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 07 Apr 2016 06:44:52 +0000 Subject: [docs] [issue26703] Socket state corrupts when original socket object goes out of scope in a different thread In-Reply-To: <1459966025.84.0.875779742702.issue26703@psf.upfronthosting.co.za> Message-ID: <1460011492.71.0.393410043354.issue26703@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The general answer here is you should avoid mixing calls to different abstraction layers. Either use only the file descriptor or only the socket object. This is not limited to lifetime issues, other issues can occur. For example, setting a timeout on a socket puts the underlying file descriptor in non-blocking mode. So code using the file descriptor can fail with EAGAIN. If you really want to use *both* a file descriptor and a socket object, you can use os.dup() on the file descriptor, so that the OS resources are truly independent. ---------- _______________________________________ Python tracker _______________________________________ From senthil at uthcode.com Thu Apr 7 23:40:17 2016 From: senthil at uthcode.com (Senthil Kumaran) Date: Thu, 7 Apr 2016 20:40:17 -0700 Subject: [docs] Possible typo in docs In-Reply-To: References: Message-ID: Hello Andrew, You are right. The task should not be pop'ed out of the entry_finder dictionary. I prefer the 2nd approach over the 1st one where the task is re-added back to the dictionary. def remove_task(task): 'Mark an existing task as REMOVED. Raise KeyError if not found.' entry_finder[task][-1] = REMOVED I will correct it in the docs. -- Senthil On Wed, Apr 6, 2016 at 3:42 AM, Andrew McFarland < andrew.mcfarland at outlook.com> wrote: > page in question: https://docs.python.org/2/library/heapq.html > > section: * 8.4.2. Priority Queue Implementation Notes* > > Currently: > > > def remove_task(task): > 'Mark an existing task as REMOVED. Raise KeyError if not found.' > entry = entry_finder.pop(task) > entry[-1] = REMOVED > > > As it stands, 'task' is removed from dictionary 'entry_finder' and never > replaced which is not the intention in my opinion. > > Possible fixes: > > 1. > def remove_task(task): > 'Mark an existing task as REMOVED. Raise KeyError if not found.' > entry = entry_finder.pop(task) > entry[-1] = REMOVED > entry_finder[task] = entry > > > 2. > def remove_task(task): > 'Mark an existing task as REMOVED. Raise KeyError if not found.' > entry_finder[task][-1] = REMOVED > > > Sincerely, > AM > > > > > _______________________________________________ > docs mailing list > docs at python.org > https://mail.python.org/mailman/listinfo/docs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From senthil at uthcode.com Fri Apr 8 00:59:49 2016 From: senthil at uthcode.com (Senthil Kumaran) Date: Thu, 7 Apr 2016 21:59:49 -0700 Subject: [docs] Possible typo in docs In-Reply-To: References: Message-ID: Replying again. The docs as it stands is correct. The entry_finder is merely used as pointer to the lastest task and the task itself is not removed from the heapq. Removing the task using entry_pop.() would not be affecting this as it is anyways overridden in line 6 in the add_task. So, no change is needed here. Thank you, Senthil On Thu, Apr 7, 2016 at 8:40 PM, Senthil Kumaran wrote: > Hello Andrew, > > You are right. The task should not be pop'ed out of the entry_finder > dictionary. I prefer the 2nd approach over the 1st one where the task is > re-added back to the dictionary. > > def remove_task(task): > 'Mark an existing task as REMOVED. Raise KeyError if not found.' > entry_finder[task][-1] = REMOVED > > I will correct it in the docs. > > -- > Senthil > > > On Wed, Apr 6, 2016 at 3:42 AM, Andrew McFarland < > andrew.mcfarland at outlook.com> wrote: > >> page in question: https://docs.python.org/2/library/heapq.html >> >> section: * 8.4.2. Priority Queue Implementation Notes* >> >> Currently: >> >> >> def remove_task(task): >> 'Mark an existing task as REMOVED. Raise KeyError if not found.' >> entry = entry_finder.pop(task) >> entry[-1] = REMOVED >> >> >> As it stands, 'task' is removed from dictionary 'entry_finder' and never >> replaced which is not the intention in my opinion. >> >> Possible fixes: >> >> 1. >> def remove_task(task): >> 'Mark an existing task as REMOVED. Raise KeyError if not found.' >> entry = entry_finder.pop(task) >> entry[-1] = REMOVED >> entry_finder[task] = entry >> >> >> 2. >> def remove_task(task): >> 'Mark an existing task as REMOVED. Raise KeyError if not found.' >> entry_finder[task][-1] = REMOVED >> >> >> Sincerely, >> AM >> >> >> >> >> _______________________________________________ >> 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 Fri Apr 8 03:00:16 2016 From: report at bugs.python.org (JoshN) Date: Fri, 08 Apr 2016 07:00:16 +0000 Subject: [docs] [issue26703] Socket state corrupts when original socket object goes out of scope in a different thread In-Reply-To: <1459966025.84.0.875779742702.issue26703@psf.upfronthosting.co.za> Message-ID: <1460098816.78.0.286142885167.issue26703@psf.upfronthosting.co.za> JoshN added the comment: Josh/Martin/Antoine: Thank you for the tips - I was not aware of the underlying mechanics, especially the separate abstraction layers. I did RTFM up and down before posting this, to be sure. My apologies for the inconvenience. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 8 04:58:54 2016 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 08 Apr 2016 08:58:54 +0000 Subject: [docs] [issue26703] Socket state corrupts when original socket object goes out of scope in a different thread In-Reply-To: <1459966025.84.0.875779742702.issue26703@psf.upfronthosting.co.za> Message-ID: <1460105934.32.0.211176573565.issue26703@psf.upfronthosting.co.za> Antoine Pitrou added the comment: No need to apologize :) Perhaps we need to make the docs a bit clearer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 8 05:56:53 2016 From: report at bugs.python.org (Erwin Mayer) Date: Fri, 08 Apr 2016 09:56:53 +0000 Subject: [docs] [issue18820] json.dump() ignores its 'default' option when serializing dictionary keys In-Reply-To: <1377253830.03.0.463497944995.issue18820@psf.upfronthosting.co.za> Message-ID: <1460109413.03.0.471130587404.issue18820@psf.upfronthosting.co.za> Erwin Mayer added the comment: Will this be merged? I also believe it is an unexpected behavior to not serialize dictionary keys when the default option is used. ---------- nosy: +Erwin Mayer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 8 06:02:16 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 08 Apr 2016 10:02:16 +0000 Subject: [docs] [issue18820] json.dump() ignores its 'default' option when serializing dictionary keys In-Reply-To: <1377253830.03.0.463497944995.issue18820@psf.upfronthosting.co.za> Message-ID: <1460109736.19.0.421289791641.issue18820@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- assignee: docs at python -> components: -Documentation versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 8 07:01:10 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 08 Apr 2016 11:01:10 +0000 Subject: [docs] [issue18820] json.dump() ignores its 'default' option when serializing dictionary keys In-Reply-To: <1377253830.03.0.463497944995.issue18820@psf.upfronthosting.co.za> Message-ID: <1460113270.07.0.660647406947.issue18820@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also https://github.com/simplejson/simplejson/issues/42 https://github.com/simplejson/simplejson/issues/100 https://github.com/simplejson/simplejson/issues/103 And allowing non-string keys leads to other issue: https://github.com/simplejson/simplejson/issues/77 Thus there is an argument for disallowing serializing non-string keys. ---------- nosy: +bob.ippolito, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 8 08:41:34 2016 From: report at bugs.python.org (Erwin Mayer) Date: Fri, 08 Apr 2016 12:41:34 +0000 Subject: [docs] [issue18820] json.dump() ignores its 'default' option when serializing dictionary keys In-Reply-To: <1377253830.03.0.463497944995.issue18820@psf.upfronthosting.co.za> Message-ID: <1460119294.28.0.857451806495.issue18820@psf.upfronthosting.co.za> Erwin Mayer added the comment: Regarding the issues mentioned in https://github.com/simplejson/simplejson/issues/77, they already apply with the current implementation anyway (true is serialized as 'true'), so users must already be careful. The JSONEncoder with default parameters could definitely keep rejecting complex keys, but an optional 'encode_complex_keys=False' parameter could be added to __init__ to provide this functionality. There would be zero performance impact as the parameter check would only be done if all else has failed instead of raising the TypeError (the same way _skipkeys does). In that respect, the patch of this issue would need to be amended (and the C version would also need to be changed). I am trying to fork the json core module to achieve this (to not have to wait for the next Python release, assuming it gets implemented), if you are familiar with the packaging process of core modules into standalone modules, your advice would be much appreciated (and could well help others contribute to Python): http://stackoverflow.com/questions/36498527/how-to-create-a-customized-version-of-a-core-python-module-that-includes-c-code ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 9 00:08:08 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 09 Apr 2016 04:08:08 +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: <1460174888.76.0.289348903053.issue25314@psf.upfronthosting.co.za> Martin Panter added the comment: Patch with the outstanding change for const, plus an extra fix under the main description. ---------- Added file: http://bugs.python.org/file42407/store_const.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 9 00:15:07 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 09 Apr 2016 04:15:07 +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: <1460175307.53.0.348602884486.issue25314@psf.upfronthosting.co.za> Changes by Martin Panter : Removed file: http://bugs.python.org/file42407/store_const.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 9 00:15:45 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 09 Apr 2016 04:15:45 +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: <1460175345.49.0.419879336762.issue25314@psf.upfronthosting.co.za> Changes by Martin Panter : Added file: http://bugs.python.org/file42408/store_const.v2.patch _______________________________________ Python tracker _______________________________________ From vadmium+py at gmail.com Sat Apr 9 00:24:07 2016 From: vadmium+py at gmail.com (vadmium+py at gmail.com) Date: Sat, 09 Apr 2016 04:24:07 -0000 Subject: [docs] Documentation: argparse's actions store_{true, false} default to False/True (undocumented) (issue 25314) Message-ID: <20160409042407.14994.33906@psf.upfronthosting.co.za> https://bugs.python.org/review/25314/diff/16913/Doc/library/argparse.rst File Doc/library/argparse.rst (right): https://bugs.python.org/review/25314/diff/16913/Doc/library/argparse.rst#newcode924 Doc/library/argparse.rst:924: keyword argument must be given. For other actions, is defaults to ``None``. Should be ?it defaults to None? https://bugs.python.org/review/25314/ From report at bugs.python.org Sat Apr 9 02:07:56 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 09 Apr 2016 06:07:56 +0000 Subject: [docs] [issue17264] Update Building C and C++ Extensions with distutils documentation In-Reply-To: <1361424697.21.0.435186366661.issue17264@psf.upfronthosting.co.za> Message-ID: <20160409060751.16627.99670.0165D0B6@psf.io> Roundup Robot added the comment: New changeset ca6f174f5932 by Berker Peksag in branch '3.5': Issue #17264: Fix cross refs and a markup error in extending/building.rst https://hg.python.org/cpython/rev/ca6f174f5932 New changeset 7f7988ea908f by Berker Peksag in branch 'default': Issue #17264: Fix cross refs and a markup error in extending/building.rst https://hg.python.org/cpython/rev/7f7988ea908f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 9 02:08:31 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 09 Apr 2016 06:08:31 +0000 Subject: [docs] [issue17264] Update Building C and C++ Extensions with distutils documentation In-Reply-To: <1361424697.21.0.435186366661.issue17264@psf.upfronthosting.co.za> Message-ID: <1460182111.27.0.835534732385.issue17264@psf.upfronthosting.co.za> Berker Peksag added the comment: bad92d696866 has already been removed all Python 1.4 and 2.0 references. I fixed a markup error and two broken references. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> behavior versions: +Python 3.5, Python 3.6 -Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 9 03:11:50 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 09 Apr 2016 07:11:50 +0000 Subject: [docs] [issue16679] Add advice about non-ASCII wsgiref PATH_INFO In-Reply-To: <1355473710.36.0.278942451351.issue16679@psf.upfronthosting.co.za> Message-ID: <1460185910.38.0.336239322123.issue16679@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- title: Wrong URL path decoding -> Add advice about non-ASCII wsgiref PATH_INFO _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 9 08:02:31 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 09 Apr 2016 12:02:31 +0000 Subject: [docs] [issue10289] Document magic methods called by built-in functions In-Reply-To: <1288655696.94.0.809001507215.issue10289@psf.upfronthosting.co.za> Message-ID: <1460203351.83.0.804360470196.issue10289@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 9 09:01:49 2016 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 09 Apr 2016 13:01:49 +0000 Subject: [docs] [issue10289] Document magic methods called by built-in functions In-Reply-To: <1288655696.94.0.809001507215.issue10289@psf.upfronthosting.co.za> Message-ID: <1460206909.8.0.878309962266.issue10289@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: -BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 9 20:55:03 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 10 Apr 2016 00:55:03 +0000 Subject: [docs] [issue10289] Document magic methods called by built-in functions In-Reply-To: <1288655696.94.0.809001507215.issue10289@psf.upfronthosting.co.za> Message-ID: <1460249702.83.0.607268258393.issue10289@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Most of the proposed update look reasonable updates and would improve the documentation. That said, please take care to not accidentally document and unintentionally guarantee implementation details rather than language requirements (leaving freedom for future changes to implementation and freedom for IronPython, PyPy, and Jython to use their best possible implementations). Sizeof is a CPython specific implementation detail. I also have reservations about class.__instancecheck__() and class.__subclasscheck__() which are more appropriately described in a section on abstract base classes than for the otherwise simple and clear docs for isinstance() and issubclass(). The sort() method does guarantee use of __lt__ but other tools that make comparisons make or may not follow that lead (i.e. heapq used to use __le__ and collections.abc.Set uses both __le__ and __ge__). Accordingly, there is a PEP 8 recommendation to use @functools.total_ordering rather than supplying just a single rich comparison method). One other thought is to keep the additions as brief as possible to not distract from the main message of each section; keeping the docs primarily focused on what a function does rather than how it does it, and remembering that making the docs more lengthly impairs their utility for everyday use. Our docs are already much more chatty than equivalents in Java and Go (it used to take five minutes to read the docs for the builtin functions and now it takes an hour). There is also a matter of keeping the docs approachable for normal people. For most folks, saying that hex(num) returns a string with the number in hexadecimal would suffice. Adding notes about the exact case of the letters, handling of negatives, use of __int__ and __index__, and comparisons with string formatting, and multiple examples beats a dead horse and makes a simple tool seem more complex. Though I think this so go forward, I'm marking it with "low" priority because we don't have any evidence that users have found the current docs to be inadequate -- they have served well over Python's long history. Cases we've gone into details like __format__ or __next__ were there because they we essential to the tool; in contrast, it is unlikely that a user would ever need to know the sys.getsizeof() delegated its work to __sizeof__. ---------- nosy: +rhettinger priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 9 23:55:08 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 10 Apr 2016 03:55:08 +0000 Subject: [docs] [issue15984] Wrong documentation for PyUnicode_FromObject() and PyUnicode_FromEncodedObject() In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za> Message-ID: <1460260508.62.0.284633989177.issue15984@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a modified patch that avoids ?coercion? and is hopefully more explicit. I also fixed the comment in Include/unicodeobject.h. ---------- nosy: +martin.panter stage: needs patch -> patch review versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4 Added file: http://bugs.python.org/file42418/from_object_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 10 00:08:20 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 10 Apr 2016 04:08:20 +0000 Subject: [docs] [issue15984] Wrong documentation for PyUnicode_FromObject() and PyUnicode_FromEncodedObject() In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za> Message-ID: <1460261300.29.0.161097566845.issue15984@psf.upfronthosting.co.za> Changes by Martin Panter : Removed file: http://bugs.python.org/file42418/from_object_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 10 00:10:05 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 10 Apr 2016 04:10:05 +0000 Subject: [docs] [issue15984] Wrong documentation for PyUnicode_FromObject() and PyUnicode_FromEncodedObject() In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za> Message-ID: <1460261405.95.0.600827832193.issue15984@psf.upfronthosting.co.za> Changes by Martin Panter : Added file: http://bugs.python.org/file42419/from_object_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 10 06:44:10 2016 From: report at bugs.python.org (Ned Deily) Date: Sun, 10 Apr 2016 10:44:10 +0000 Subject: [docs] [issue26706] Update OpenSSL version in readme In-Reply-To: <1459974987.74.0.0926215654006.issue26706@psf.upfronthosting.co.za> Message-ID: <1460285050.74.0.537088072212.issue26706@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From storchaka at gmail.com Sun Apr 10 07:06:50 2016 From: storchaka at gmail.com (storchaka at gmail.com) Date: Sun, 10 Apr 2016 11:06:50 -0000 Subject: [docs] Wrong documentation for PyUnicode_FromObject() (issue 15984) Message-ID: <20160410110650.7706.41860@psf.upfronthosting.co.za> Reviewers: , http://bugs.python.org/review/15984/diff/16922/Doc/c-api/unicode.rst File Doc/c-api/unicode.rst (right): http://bugs.python.org/review/15984/diff/16922/Doc/c-api/unicode.rst#newcode730 Doc/c-api/unicode.rst:730: Copy a Unicode subtype object to a new base Unicode object if necessary. The term "base Unicode object" is not used anywhere else. The documentation for PyUnicode_Check() and PyUnicode_CheckExact() say just about a Unicode object and an instance of a Unicode subtype. Please review this at http://bugs.python.org/review/15984/ Affected files: Doc/c-api/unicode.rst Include/unicodeobject.h # HG changeset patch # Parent 4e186581fea7f82ce4688560e577d059eafccf01 diff -r 4e186581fea7 Doc/c-api/unicode.rst --- a/Doc/c-api/unicode.rst Wed May 01 00:17:45 2013 +0200 +++ b/Doc/c-api/unicode.rst Sun Apr 10 04:09:49 2016 +0000 @@ -727,8 +727,11 @@ .. c:function:: PyObject* PyUnicode_FromObject(PyObject *obj) - Shortcut for ``PyUnicode_FromEncodedObject(obj, NULL, "strict")`` which is used - throughout the interpreter whenever coercion to Unicode is needed. + Copy a Unicode subtype object to a new base Unicode object if necessary. + If *obj* is already a base Unicode object, return the reference with + incremented refcount. + + Objects other than Unicode or its subtypes will cause a :exc:`TypeError`. Locale Encoding diff -r 4e186581fea7 Include/unicodeobject.h --- a/Include/unicodeobject.h Wed May 01 00:17:45 2013 +0200 +++ b/Include/unicodeobject.h Sun Apr 10 04:09:49 2016 +0000 @@ -864,14 +864,11 @@ const char *errors /* error handling */ ); -/* Coerce obj to an Unicode object and return a reference with +/* Copy a Unicode subtype object to a new base Unicode object if necessary. + + If obj is already a base Unicode object, return the reference with *incremented* refcount. - Unicode objects are passed back as-is (subclasses are converted to - true Unicode objects), all other objects are delegated to - PyUnicode_FromEncodedObject(obj, NULL, "strict") which results in - using UTF-8 encoding as basis for decoding the object. - The API returns NULL in case of an error. The caller is responsible for decref'ing the returned objects. From report at bugs.python.org Sun Apr 10 07:07:46 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 10 Apr 2016 11:07:46 +0000 Subject: [docs] [issue15984] Wrong documentation for PyUnicode_FromObject() and PyUnicode_FromEncodedObject() In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za> Message-ID: <1460286466.0.0.72374978265.issue15984@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added a comment on Rietveld. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 10 22:47:21 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Apr 2016 02:47:21 +0000 Subject: [docs] [issue14456] Relation between threads and signals unclear In-Reply-To: <1333149178.59.0.333821086904.issue14456@psf.upfronthosting.co.za> Message-ID: <20160411024717.11838.98224.540BC77A@psf.io> Roundup Robot added the comment: New changeset 73050563053f by Martin Panter in branch '3.5': Issue #14456: Remove contradiction about blocking signals from bad merge https://hg.python.org/cpython/rev/73050563053f New changeset a8dbe6016a31 by Martin Panter in branch 'default': Issue #14456: Merge signal doc fix from 3.5 https://hg.python.org/cpython/rev/a8dbe6016a31 ---------- _______________________________________ Python tracker _______________________________________ From freely.given.org at gmail.com Sun Apr 10 17:36:02 2016 From: freely.given.org at gmail.com (Freely-Given.org) Date: Mon, 11 Apr 2016 09:36:02 +1200 Subject: [docs] 'namereplace' Message-ID: <570AC742.1090508@gmail.com> https://docs.python.org/3/library/functions.html doesn't warn that 'namereplace' was new in Python 3.5 (it seems). Thanks, Robert. From nevimov at gmail.com Mon Apr 11 04:49:49 2016 From: nevimov at gmail.com (Alex) Date: Mon, 11 Apr 2016 15:49:49 +0700 Subject: [docs] A typo in the unittest.mock docs Message-ID: <570B652D.4020708@gmail.com> https://docs.python.org/3/library/unittest.mock.html#magic-mock ... > Methods and their defaults: > ... > __len__:1 > ... Should be __len__:0 From berker.peksag at gmail.com Mon Apr 11 05:23:42 2016 From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=) Date: Mon, 11 Apr 2016 12:23:42 +0300 Subject: [docs] A typo in the unittest.mock docs In-Reply-To: <570B652D.4020708@gmail.com> References: <570B652D.4020708@gmail.com> Message-ID: On Mon, Apr 11, 2016 at 11:49 AM, Alex wrote: > https://docs.python.org/3/library/unittest.mock.html#magic-mock > ... > >> Methods and their defaults: >> ... >> __len__:1 >> ... > > Should be __len__:0 Hi Alex, Good catch, thanks for the report. Fixed in https://hg.python.org/cpython/rev/83f267ffb862 --Berker From report at bugs.python.org Mon Apr 11 05:39:53 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Apr 2016 09:39:53 +0000 Subject: [docs] [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <20160411093947.16631.42576.8F4A9DFE@psf.io> Roundup Robot added the comment: New changeset ce721df212cf by Serhiy Storchaka in branch '3.5': Issue #25910: Fixed dead links in the docs. https://hg.python.org/cpython/rev/ce721df212cf New changeset 14e00e7e4d51 by Georg Brandl in branch '2.7': Closes #25910: fix dead and permanently redirected links in the docs. Thanks to SilentGhost for the patch. https://hg.python.org/cpython/rev/14e00e7e4d51 New changeset 00addbb47c5c by Serhiy Storchaka in branch '2.7': Issue #25910: Fixed dead links in the docs. https://hg.python.org/cpython/rev/00addbb47c5c New changeset 15c4557af8e0 by Serhiy Storchaka in branch 'default': Issue #25910: Fixed dead links in the docs. https://hg.python.org/cpython/rev/15c4557af8e0 ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 11 05:40:43 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Apr 2016 09:40:43 +0000 Subject: [docs] [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <1460367643.52.0.632102179483.issue25910@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Following dead links left: Doc/library/xmlrpc.client.rst (line 42) broken http://ontosys.com/xml-rpc/extensions.php - Doc/license.rst (line 22) broken http://www.zope.com/ - (line 131) broken http://www.pythonlabs.com/logos.html - HTTP Error 404: Not Found Doc/using/windows.rst (line 271) broken http://www.swaroopch.com/notes/python/#install_windows - Anchor 'install_windows' not found Doc/whatsnew/2.1.rst (line 543) broken http://www.vex.net/parnassus/ - HTTP Error 404: Not Found Doc/whatsnew/2.6.rst (line 174) broken http://svn.python.org/view/tracker/importer/ - HTTP Error 404: Not Found (line 193) broken http://svn.python.org/view/tracker/importer/ - HTTP Error 404: Not Found Doc/whatsnew/2.7.rst (line 1529) broken http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT - Anchor 'CIPHER_LIST_FORMAT' not found (line 1618) broken http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT - Anchor 'CIPHER_LIST_FORMAT' not found ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 11 05:50:05 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Apr 2016 09:50:05 +0000 Subject: [docs] [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <1460368205.31.0.483532098396.issue25910@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: fixed -> stage: resolved -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 11 06:31:21 2016 From: report at bugs.python.org (SilentGhost) Date: Mon, 11 Apr 2016 10:31:21 +0000 Subject: [docs] [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <1460370681.66.0.213726055291.issue25910@psf.upfronthosting.co.za> SilentGhost added the comment: Licence text shouldn't be touched, I think. http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT became https://www.openssl.org/docs/manmaster/apps/ciphers.html#CIPHER-LIST-FORMAT If Martin still have the importer code somewhere, he probably could provide an up to date link. ---------- _______________________________________ Python tracker _______________________________________ From berker.peksag at gmail.com Mon Apr 11 06:50:24 2016 From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=) Date: Mon, 11 Apr 2016 13:50:24 +0300 Subject: [docs] 'namereplace' In-Reply-To: <570AC742.1090508@gmail.com> References: <570AC742.1090508@gmail.com> Message-ID: On Mon, Apr 11, 2016 at 12:36 AM, Freely-Given.org wrote: > https://docs.python.org/3/library/functions.html doesn't warn that > 'namereplace' was new in Python 3.5 (it seems). Hi Robert, Thank you for your report. Fixed in https://hg.python.org/cpython/rev/3735a033791b --Berker From report at bugs.python.org Mon Apr 11 07:33:39 2016 From: report at bugs.python.org (Martin Panter) Date: Mon, 11 Apr 2016 11:33:39 +0000 Subject: [docs] [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <1460374419.32.0.832450896647.issue25910@psf.upfronthosting.co.za> Martin Panter added the comment: The bug tracker importer still exists if you know what revision to look it up in: ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 11 10:38:56 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 11 Apr 2016 14:38:56 +0000 Subject: [docs] [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <20160411143851.11585.5170.945E7467@psf.io> Roundup Robot added the comment: New changeset bb10867ffe28 by Serhiy Storchaka in branch '3.5': Issue #25910: Fixed more links in the docs. https://hg.python.org/cpython/rev/bb10867ffe28 New changeset 61c7deea9e6a by Serhiy Storchaka in branch '2.7': Issue #25910: Fixed more links in the docs. https://hg.python.org/cpython/rev/61c7deea9e6a New changeset e3c9a47a83fb by Serhiy Storchaka in branch 'default': Issue #25910: Fixed more links in the docs. https://hg.python.org/cpython/rev/e3c9a47a83fb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 11 10:40:19 2016 From: report at bugs.python.org (SilentGhost) Date: Mon, 11 Apr 2016 14:40:19 +0000 Subject: [docs] [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <1460385619.93.0.061523730652.issue25910@psf.upfronthosting.co.za> SilentGhost added the comment: Serhiy, the OpenSSL links are now https ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 11 10:56:48 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Apr 2016 14:56:48 +0000 Subject: [docs] [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <1460386607.95.0.402639145537.issue25910@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed links to "A Byte of Python" and OpenSSL. Not fixed dead links: http://www.zope.com/ http://www.pythonlabs.com/logos.html (http://www.pythonlabs.com/ exists but is not too useful) http://www.vex.net/parnassus/ (looks as this project is dead) http://ontosys.com/xml-rpc/extensions.php (sad, this was a specification) http://svn.python.org/view/tracker/importer/ (removed in r88981 and not moved to https://hg.python.org/tracker) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 11 10:59:41 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Apr 2016 14:59:41 +0000 Subject: [docs] [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <1460386781.34.0.435947108585.issue25910@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Serhiy, the OpenSSL links are now https They works with http. Some links (including python.org) are now redirected from http to https. It may be worth to add https explicitly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 11 11:00:54 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Apr 2016 15:00:54 +0000 Subject: [docs] [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <1460386854.65.0.328530543356.issue25910@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +barry, tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 11 14:28:22 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Apr 2016 18:28:22 +0000 Subject: [docs] [issue26736] Use HTTPS protocol in links Message-ID: <1460399300.6.0.985736947814.issue26736@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch makes links in the docs to use the HTTPS protocol if possible. All changed links are tested manually. ---------- assignee: docs at python components: Documentation files: links_https.patch keywords: patch messages: 263197 nosy: alex, christian.heimes, docs at python, dstufft, georg.brandl, giampaolo.rodola, janssen, pitrou, serhiy.storchaka, tim.golden priority: normal severity: normal stage: patch review status: open title: Use HTTPS protocol in links type: security versions: Python 2.7, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file42435/links_https.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 11 14:36:20 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 11 Apr 2016 18:36:20 +0000 Subject: [docs] [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <1460399780.57.0.40772484844.issue25910@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For XML-RPC extensions we can use a web archive: https://web.archive.org/web/20130120074804/http://ontosys.com/xml-rpc/extensions.php. There are precedences of using it for other dead links. Opened separate issue26736 for https-zation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 11 15:36:29 2016 From: report at bugs.python.org (STINNER Victor) Date: Mon, 11 Apr 2016 19:36:29 +0000 Subject: [docs] [issue26736] Use HTTPS protocol in links In-Reply-To: <1460399300.6.0.985736947814.issue26736@psf.upfronthosting.co.za> Message-ID: <1460403389.75.0.791230339815.issue26736@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From john23gordon at gmail.com Mon Apr 11 15:34:59 2016 From: john23gordon at gmail.com (John Gordon) Date: Mon, 11 Apr 2016 12:34:59 -0700 Subject: [docs] possible doc bug: 6.2.1. Regular Expression Syntax, *?, +?, ?? Message-ID: I'm a Python newbie and am very reluctant to submit a doc bug since I don't know what I'm doing yet. But I'm trying to learn to use re.search and am using your doc. I can't figure out how the text I colored red below can be accurate. Besides its logic not making sense to me, I tried running it and it doesn't work: .*? doesn't match

. If I'm wrong I need to understand why. ============ DOC BUG (maybe): https://docs.python.org/3/library/re.html 6.2.1. Regular Expression Syntax > > > **?, +?, ?? *The '*', '+', and '?' qualifiers are all greedy; they match > as much text as possible. Sometimes this behaviour isn?t desired; if the RE > <.*> is matched against '

title

', it will match the entire string, > and not just '

'. Adding '?' after the qualifier makes it perform the > match in non-greedy or minimal fashion; as few characters as possible will > be matched. *Using .*? in the previous expression will match only '

'.* > > I tried the following and none returned

: >>> ttt = re.search('.*?','

title

') >>> ttt = re.search('(.*?)','

title

') >>> ttt = re.search(r'(.*?)','

title

') Thank you for your time! John Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: From report at bugs.python.org Mon Apr 11 21:55:44 2016 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 12 Apr 2016 01:55:44 +0000 Subject: [docs] [issue11205] Evaluation order of dictionary display is different from reference manual. In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za> Message-ID: <1460426143.83.0.300920806395.issue11205@psf.upfronthosting.co.za> Nick Coghlan added the comment: Temporarily reopening this as a docs bug - I think it's worth mentioning in the "Porting to Python 3.5" section of the What's New docs and as a "version changed" note in the dis module docs, as even though it's obscure, anyone that was inadvertently relying on the prior deviation from the spec is going to be confused by the behavioural change in 3.5. (The specific case where this came up was Russell Keith-Magee encountering the semantic change in BUILD_MAP's expectations for argument order on the stack for his VOD bytecode transpiler) ---------- assignee: -> docs at python components: +Documentation -Interpreter Core nosy: +docs at python priority: high -> normal resolution: fixed -> stage: resolved -> needs patch status: closed -> open versions: +Python 3.5 -Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 12 00:29:03 2016 From: report at bugs.python.org (Luiz Poleto) Date: Tue, 12 Apr 2016 04:29:03 +0000 Subject: [docs] [issue26699] locale.str docstring is incorrect: "Convert float to integer" In-Reply-To: <1459927789.02.0.138982751213.issue26699@psf.upfronthosting.co.za> Message-ID: <1460435343.57.0.854995995904.issue26699@psf.upfronthosting.co.za> Changes by Luiz Poleto : ---------- keywords: +patch Added file: http://bugs.python.org/file42440/issue26699.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 12 01:48:39 2016 From: report at bugs.python.org (Georg Brandl) Date: Tue, 12 Apr 2016 05:48:39 +0000 Subject: [docs] [issue26736] Use HTTPS protocol in links In-Reply-To: <1460399300.6.0.985736947814.issue26736@psf.upfronthosting.co.za> Message-ID: <1460440119.11.0.820186767972.issue26736@psf.upfronthosting.co.za> Georg Brandl added the comment: +1 ---------- _______________________________________ Python tracker _______________________________________ From georg at python.org Tue Apr 12 01:53:08 2016 From: georg at python.org (Georg Brandl) Date: Tue, 12 Apr 2016 07:53:08 +0200 Subject: [docs] possible doc bug: 6.2.1. Regular Expression Syntax, *?, +?, ?? In-Reply-To: References: Message-ID: <570C8D44.6090702@python.org> On 04/11/2016 09:34 PM, John Gordon wrote: > I'm a Python newbie and am very reluctant to submit a doc bug since I don't know > what I'm doing yet. > > But I'm trying to learn to use re.search and am using your doc. > > I can't figure out how the text I colored red below can be accurate. Besides its > logic not making sense to me, I tried running it and it doesn't work: .*? > doesn't match

. > > If I'm wrong I need to understand why. > > ============ > > DOC BUG (maybe): > https://docs.python.org/3/library/re.html > > 6.2.1. Regular Expression Syntax > > **?, +?, ?? > *The '*', '+', and '?' qualifiers are all greedy; they match as much text as > possible. Sometimes this behaviour isn?t desired; if the RE <.*> is matched > against '

title

', it will match the entire string, and not just > '

'. Adding '?' after the qualifier makes it perform the match in > non-greedy or minimal fashion; as few characters as possible will be > matched. *Using .*? in the previous expression will match only '

'.** > ** > * > > > I tried the following and none returned

: > >>>> ttt = re.search('.*?','

title

') >>>> ttt = re.search('(.*?)','

title

') >>>> ttt = re.search(r'(.*?)','

title

') Hi John, this is indeed confusingly worded; it should give the whole expression, i.e. ``<.*?>``. Also, it should probably refrain from using HTML in a regex example altogether, as parsing HTML/XML with regexes is one of the classic "I thought I'd use regex, now I have two problems" cases. I've changed the example now to be a bit less specific, and clarified the replacement regex. Thanks for the report! Georg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From report at bugs.python.org Tue Apr 12 01:55:33 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 12 Apr 2016 05:55:33 +0000 Subject: [docs] [issue26736] Use HTTPS protocol in links In-Reply-To: <1460399300.6.0.985736947814.issue26736@psf.upfronthosting.co.za> Message-ID: <1460440533.65.0.556894889869.issue26736@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If these changes are acceptable, we should change the :rfc:, :pep:, etc roles to produce links with https. I was not sure that these changes are worth, it was just interesting to me to research how many links support the HTTPS protocol now. ---------- _______________________________________ Python tracker _______________________________________ From john23gordon at gmail.com Tue Apr 12 01:19:48 2016 From: john23gordon at gmail.com (John Gordon) Date: Mon, 11 Apr 2016 22:19:48 -0700 Subject: [docs] Fwd: possible doc bug: 6.2.1. Regular Expression Syntax, *?, +?, ?? Message-ID: Never mind. I figured it out. I see that the last sentence about using .*? is meant to be used inside the RE <.*> mentioned in the second sentence. Confusing but another website explained it then I reread your paragraph and understood what you meant. - John Gordon ---------- Forwarded message ---------- From: John Gordon Date: Mon, Apr 11, 2016 at 12:34 PM Subject: possible doc bug: 6.2.1. Regular Expression Syntax, *?, +?, ?? To: docs at python.org I'm a Python newbie and am very reluctant to submit a doc bug since I don't know what I'm doing yet. But I'm trying to learn to use re.search and am using your doc. I can't figure out how the text I colored red below can be accurate. Besides its logic not making sense to me, I tried running it and it doesn't work: .*? doesn't match

. If I'm wrong I need to understand why. ============ DOC BUG (maybe): https://docs.python.org/3/library/re.html 6.2.1. Regular Expression Syntax > > > **?, +?, ?? *The '*', '+', and '?' qualifiers are all greedy; they match > as much text as possible. Sometimes this behaviour isn?t desired; if the RE > <.*> is matched against '

title

', it will match the entire string, > and not just '

'. Adding '?' after the qualifier makes it perform the > match in non-greedy or minimal fashion; as few characters as possible will > be matched. *Using .*? in the previous expression will match only '

'.* > > I tried the following and none returned

: >>> ttt = re.search('.*?','

title

') >>> ttt = re.search('(.*?)','

title

') >>> ttt = re.search(r'(.*?)','

title

') Thank you for your time! John Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: From report at bugs.python.org Tue Apr 12 09:25:07 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 12 Apr 2016 13:25:07 +0000 Subject: [docs] [issue20699] Document that binary IO classes work with bytes-likes objects In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <1460467506.92.0.354702598883.issue20699@psf.upfronthosting.co.za> Martin Panter added the comment: After thinking about Issue 26720 (see also Issue 15994), I think it might be worth documenting not only that bytes-like objects may be passed, but in some cases the class should not be access the object after the method returns. This applies to at least RawIOBase.readinto() and especially RawIOBase.write(). If you want to save the write() data in memory, you have to make a copy, because the original may be lost when BufferedWriter overwrites its internal buffeer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 12 10:52:56 2016 From: report at bugs.python.org (supriyanto maftuh,st) Date: Tue, 12 Apr 2016 14:52:56 +0000 Subject: [docs] [issue26699] locale.str docstring is incorrect: "Convert float to integer" In-Reply-To: <1459927789.02.0.138982751213.issue26699@psf.upfronthosting.co.za> Message-ID: <1460472776.78.0.433528390336.issue26699@psf.upfronthosting.co.za> Changes by supriyanto maftuh,st : ---------- nosy: +supriyanto maftuh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 12 11:34:15 2016 From: report at bugs.python.org (supriyanto maftuh,st) Date: Tue, 12 Apr 2016 15:34:15 +0000 Subject: [docs] [issue24136] document PEP 448: unpacking generalization In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1460475255.53.0.760017668845.issue24136@psf.upfronthosting.co.za> supriyanto maftuh,st added the comment: Hy ---------- components: +Benchmarks, Build, IO, Unicode, Windows, XML, email hgrepos: +336 nosy: +barry, brett.cannon, ezio.melotti, haypo, paul.moore, pitrou, r.david.murray, steve.dower, supriyanto maftuh, supriyanto maftuh,st, tim.golden, zach.ware versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 12 11:40:57 2016 From: report at bugs.python.org (supriyanto maftuh,st) Date: Tue, 12 Apr 2016 15:40:57 +0000 Subject: [docs] [issue24557] Refactor LibreSSL / EGD detection In-Reply-To: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za> Message-ID: <1460475656.81.0.197280393547.issue24557@psf.upfronthosting.co.za> supriyanto maftuh,st added the comment: Easy to review with issues phyton, maintenanca by supriyanto maftuh ---------- assignee: -> docs at python components: +2to3 (2.x to 3.x conversion tool), Argument Clinic, Benchmarks, Cross-Build, Demos and Tools, Devguide, Distutils, Documentation, Extension Modules, IDLE, IO, Installation, Interpreter Core, Macintosh, Regular Expressions, Tests, Tkinter, Unicode, Windows, XML, asyncio, ctypes, email hgrepos: +337 nosy: +Alex.Willmer, barry, brett.cannon, docs at python, dstufft, eric.araujo, ezio.melotti, gvanrossum, haypo, larry, mrabarnett, ned.deily, paul.moore, pitrou, r.david.murray, ronaldoussoren, steve.dower, supriyanto maftuh, supriyanto maftuh,st, tim.golden, willingc, yselivanov, zach.ware versions: +Python 3.2, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 12 11:58:43 2016 From: report at bugs.python.org (supriyanto maftuh,st) Date: Tue, 12 Apr 2016 15:58:43 +0000 Subject: [docs] [issue15984] Wrong documentation for PyUnicode_FromObject() and PyUnicode_FromEncodedObject() In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za> Message-ID: <1460476723.69.0.922634598927.issue15984@psf.upfronthosting.co.za> Changes by supriyanto maftuh,st : ---------- components: +Build, Tests, Unicode, Windows, XML hgrepos: +341 nosy: +ezio.melotti, paul.moore, steve.dower, supriyanto maftuh, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 12 11:59:06 2016 From: report at bugs.python.org (Brian Curtin) Date: Tue, 12 Apr 2016 15:59:06 +0000 Subject: [docs] [issue15984] Wrong documentation for PyUnicode_FromObject() and PyUnicode_FromEncodedObject() In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za> Message-ID: <1460476746.16.0.406339869866.issue15984@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- nosy: -brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 12 12:19:03 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 12 Apr 2016 16:19:03 +0000 Subject: [docs] [issue24136] document PEP 448: unpacking generalization In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1460477943.63.0.847372354388.issue24136@psf.upfronthosting.co.za> Berker Peksag added the comment: supriyanto maftuh,st, please don't play with tracker items. ---------- components: -Benchmarks, Build, IO, Unicode, Windows, XML, email versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 12 12:19:28 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 12 Apr 2016 16:19:28 +0000 Subject: [docs] [issue24136] document PEP 448: unpacking generalization In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1460477968.38.0.460700064343.issue24136@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- Removed message: http://bugs.python.org/msg263250 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 12 12:23:45 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 12 Apr 2016 16:23:45 +0000 Subject: [docs] [issue24557] Refactor LibreSSL / EGD detection In-Reply-To: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za> Message-ID: <1460478225.7.0.53341351134.issue24557@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- components: -2to3 (2.x to 3.x conversion tool), Argument Clinic, Benchmarks, Build, Cross-Build, Demos and Tools, Devguide, Distutils, Documentation, Extension Modules, IDLE, IO, Installation, Interpreter Core, Macintosh, Regular Expressions, Tests, Tkinter, Unicode, Windows, XML, asyncio, ctypes, email stage: -> patch review versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 12 12:26:06 2016 From: report at bugs.python.org (SilentGhost) Date: Tue, 12 Apr 2016 16:26:06 +0000 Subject: [docs] [issue24557] Refactor LibreSSL / EGD detection In-Reply-To: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za> Message-ID: <1460478366.04.0.634038204219.issue24557@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- Removed message: http://bugs.python.org/msg263251 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 12 12:42:39 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 12 Apr 2016 16:42:39 +0000 Subject: [docs] [issue15984] Wrong documentation for PyUnicode_FromObject() and PyUnicode_FromEncodedObject() In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za> Message-ID: <1460479359.16.0.865787234901.issue15984@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- components: -Build, Tests, Unicode, Windows, XML _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 12 13:41:15 2016 From: report at bugs.python.org (Brett Cannon) Date: Tue, 12 Apr 2016 17:41:15 +0000 Subject: [docs] [issue24136] document PEP 448: unpacking generalization In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1460482875.33.0.186746278301.issue24136@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: -brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 12 15:05:58 2016 From: report at bugs.python.org (Zachary Ware) Date: Tue, 12 Apr 2016 19:05:58 +0000 Subject: [docs] [issue15984] Wrong documentation for PyUnicode_FromObject() and PyUnicode_FromEncodedObject() In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za> Message-ID: <1460487958.73.0.335274860481.issue15984@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- hgrepos: -341 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 12 15:07:42 2016 From: report at bugs.python.org (Zachary Ware) Date: Tue, 12 Apr 2016 19:07:42 +0000 Subject: [docs] [issue24136] document PEP 448: unpacking generalization In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1460488062.78.0.362189418377.issue24136@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- hgrepos: -336 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 12 15:14:04 2016 From: report at bugs.python.org (Zachary Ware) Date: Tue, 12 Apr 2016 19:14:04 +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: <1460488444.51.0.859221322322.issue25496@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- hgrepos: -330 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 13 00:32:33 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 Apr 2016 04:32:33 +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: <20160413043229.41613.99767.968E4554@psf.io> Roundup Robot added the comment: New changeset b1f3fe320adf by Martin Panter in branch '3.5': Issue #25496: Document compresslevel defaults to 9, by Hamza T Khan https://hg.python.org/cpython/rev/b1f3fe320adf New changeset a04455866ec7 by Martin Panter in branch 'default': Issue #25496: Merge tarfile doc from 3.5 https://hg.python.org/cpython/rev/a04455866ec7 New changeset 4b9d70d3ba1b by Martin Panter in branch '2.7': Issue #25496: Document compresslevel defaults to 9, by Hamza T Khan https://hg.python.org/cpython/rev/4b9d70d3ba1b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 13 00:32:33 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 13 Apr 2016 04:32:33 +0000 Subject: [docs] [issue25910] Fixing links in documentation In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za> Message-ID: <20160413043229.41613.12349.79431341@psf.io> Roundup Robot added the comment: New changeset 4b65bee79dab by Georg Brandl in branch '2.7': Update susp-ignore file (#25910). https://hg.python.org/cpython/rev/4b65bee79dab ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 13 02:05:50 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 13 Apr 2016 06:05:50 +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: <1460527549.99.0.430990315027.issue25496@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for the patch Hamza ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From senthil at uthcode.com Wed Apr 13 02:09:35 2016 From: senthil at uthcode.com (senthil at uthcode.com) Date: Wed, 13 Apr 2016 06:09:35 -0000 Subject: [docs] locale.str docstring is incorrect: "Convert float to integer" (issue 26699) Message-ID: <20160413060935.3347.20714@psf.upfronthosting.co.za> Thanks for the patch, poleto. Looks good to me. http://bugs.python.org/review/26699/ From report at bugs.python.org Wed Apr 13 02:17:23 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 13 Apr 2016 06:17:23 +0000 Subject: [docs] [issue26699] locale.str docstring is incorrect: "Convert float to integer" In-Reply-To: <1459927789.02.0.138982751213.issue26699@psf.upfronthosting.co.za> Message-ID: <1460528243.2.0.715818176905.issue26699@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Thanks. Fixed in https://hg.python.org/cpython/rev/2b35ef6a9853 https://hg.python.org/cpython/rev/ad5b079565ad https://hg.python.org/cpython/rev/125d27d9cf9b ---------- nosy: +orsenthil resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 13 07:18:43 2016 From: report at bugs.python.org (Martin Panter) Date: Wed, 13 Apr 2016 11:18:43 +0000 Subject: [docs] [issue15984] Wrong documentation for PyUnicode_FromObject() and PyUnicode_FromEncodedObject() In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za> Message-ID: <1460546323.09.0.804495807587.issue15984@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a new version where I use the phrase ?true Unicode object?. ---------- Added file: http://bugs.python.org/file42452/from_object_v4.patch _______________________________________ Python tracker _______________________________________ From vadmium+py at gmail.com Wed Apr 13 07:14:52 2016 From: vadmium+py at gmail.com (vadmium+py at gmail.com) Date: Wed, 13 Apr 2016 11:14:52 -0000 Subject: [docs] Wrong documentation for PyUnicode_FromObject() (issue 15984) Message-ID: <20160413111452.27666.28698@psf.upfronthosting.co.za> https://bugs.python.org/review/15984/diff/16922/Doc/c-api/unicode.rst File Doc/c-api/unicode.rst (right): https://bugs.python.org/review/15984/diff/16922/Doc/c-api/unicode.rst#newcode730 Doc/c-api/unicode.rst:730: Copy a Unicode subtype object to a new base Unicode object if necessary. On 2016/04/10 13:06:50, storchaka wrote: > The term "base Unicode object" is not used anywhere else. The documentation for > PyUnicode_Check() and PyUnicode_CheckExact() say just about a Unicode object and > an instance of a Unicode subtype. The original comment in unicodeobject.h uses ?true Unicode object?, so I will try that. I was trying to avoid it saying it copies a subtype to another object of the subtype. https://bugs.python.org/review/15984/ From report at bugs.python.org Wed Apr 13 07:57:41 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 13 Apr 2016 11:57:41 +0000 Subject: [docs] [issue15984] Wrong documentation for PyUnicode_FromObject() and PyUnicode_FromEncodedObject() In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za> Message-ID: <1460548661.57.0.185950145619.issue15984@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. Thank you Martin for this improvement. ---------- assignee: docs at python -> martin.panter stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From mnikulyak at gmail.com Wed Apr 13 09:37:45 2016 From: mnikulyak at gmail.com (Maksym Nikulyak) Date: Wed, 13 Apr 2016 16:37:45 +0300 Subject: [docs] =?utf-8?q?An_typo_in_Python_=C2=BB_Python_2=2E7=2E9_docume?= =?utf-8?b?bnRhdGlvbiDCuyBUdXRvcmlhbCDCuyA2LjMuIFRoZSBkaXIoKSBGdW5j?= =?utf-8?q?tion?= Message-ID: Hi, there is a typo in the following listing: >>> a = [1, 2, 3, 4, 5] >>> import fibo >>> fib = fibo.fib >>> dir() ['__builtins__', '__name__', '__package__', 'a', 'fib', 'fibo', 'sys'] In the last line of the listing, the 'sys' item must not be in the list. Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From report at bugs.python.org Wed Apr 13 12:07:41 2016 From: report at bugs.python.org (SilentGhost) Date: Wed, 13 Apr 2016 16:07:41 +0000 Subject: [docs] [issue26747] types.InstanceType only for old style class only in 2.7 In-Reply-To: <1460561340.28.0.563389556375.issue26747@psf.upfronthosting.co.za> Message-ID: <1460563661.77.0.939270823291.issue26747@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 13 14:49:03 2016 From: report at bugs.python.org (Luiz Poleto) Date: Wed, 13 Apr 2016 18:49:03 +0000 Subject: [docs] [issue26749] Update devguide to include Fedora's DNF Message-ID: <1460573343.29.0.391562448207.issue26749@psf.upfronthosting.co.za> New submission from Luiz Poleto: Starting with Fedora 22, yum is no longer the default packaging tool, being replaced by the new DNF (Dandified Yum). Section 1.1.3.1 of the devguide, Build dependencies, has instructions to install system headers using popular Linux distributions, including Fedora, however, it only covers using yum to do it. This section should be updated to include the usage of the new DNF packaging tool to perform that task. ---------- assignee: docs at python components: Documentation messages: 263350 nosy: docs at python, poleto priority: normal severity: normal status: open title: Update devguide to include Fedora's DNF type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 13 14:51:06 2016 From: report at bugs.python.org (Luiz Poleto) Date: Wed, 13 Apr 2016 18:51:06 +0000 Subject: [docs] [issue26749] Update devguide to include Fedora's DNF In-Reply-To: <1460573343.29.0.391562448207.issue26749@psf.upfronthosting.co.za> Message-ID: <1460573466.7.0.705673261872.issue26749@psf.upfronthosting.co.za> Luiz Poleto added the comment: The attached patch contains the instructions on how to use DNF to install the system headers. ---------- keywords: +patch Added file: http://bugs.python.org/file42457/issue26749.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 13 15:10:51 2016 From: report at bugs.python.org (Gabriel Devenyi) Date: Wed, 13 Apr 2016 19:10:51 +0000 Subject: [docs] [issue16399] argparse: append action with default list adds to list instead of overriding In-Reply-To: <1351992623.71.0.851432414607.issue16399@psf.upfronthosting.co.za> Message-ID: <1460574651.38.0.566454239485.issue16399@psf.upfronthosting.co.za> Gabriel Devenyi added the comment: >From what I can tell a workaround for this still isn't documented. ---------- nosy: +Gabriel Devenyi _______________________________________ Python tracker _______________________________________ From steve.katzman at purestorage.com Wed Apr 13 17:26:27 2016 From: steve.katzman at purestorage.com (Steve Katzman) Date: Wed, 13 Apr 2016 14:26:27 -0700 Subject: [docs] Hard to parse, understand, or believe statement in 2.1 "Invoking the Interpreter." Message-ID: The bold part of the following statement, from the 2.1 "Invoking the Interpreter" page of the tutorial, is hard to follow. "Some Python modules are also useful as scripts. These can be invoked using python -m module [arg] ..., which executes the source file for *module* *as if you had spelled out its full name on the command line."* Does it mean "as if you had spelled out the source file on the command line?" or perhaps "as if you had spelled out the full name of the script imbedded in the module?" It seems to read as though "its full name" refers to the name of the module typed in the invocation. Is this correct - does "name" in this context mean something different from the module name? Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From report at bugs.python.org Thu Apr 14 05:16:42 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 14 Apr 2016 09:16:42 +0000 Subject: [docs] [issue26749] Update devguide to include Fedora's DNF In-Reply-To: <1460573343.29.0.391562448207.issue26749@psf.upfronthosting.co.za> Message-ID: <1460625402.77.0.764520755327.issue26749@psf.upfronthosting.co.za> Berker Peksag added the comment: Committed in 0ed2497e5aa4. Thanks for the patch, Luiz. ---------- components: +Devguide -Documentation nosy: +berker.peksag, ezio.melotti, willingc resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 14 05:17:09 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 14 Apr 2016 09:17:09 +0000 Subject: [docs] [issue26749] Update devguide to include Fedora's DNF In-Reply-To: <1460573343.29.0.391562448207.issue26749@psf.upfronthosting.co.za> Message-ID: <20160414091457.19493.76264.A7269803@psf.io> Roundup Robot added the comment: New changeset 0ed2497e5aa4 by Berker Peksag in branch 'default': Issue #26749: Update devguide to include DNF package manager https://hg.python.org/devguide/rev/0ed2497e5aa4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 14 08:25:57 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Apr 2016 12:25:57 +0000 Subject: [docs] [issue15984] Wrong documentation for PyUnicode_FromObject() and PyUnicode_FromEncodedObject() In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za> Message-ID: <1460636757.52.0.858669515529.issue15984@psf.upfronthosting.co.za> STINNER Victor added the comment: from_object_v4.patch LGTM, nice enhancement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 14 08:50:42 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 14 Apr 2016 12:50:42 +0000 Subject: [docs] [issue26747] types.InstanceType only for old style class only in 2.7 In-Reply-To: <1460561340.28.0.563389556375.issue26747@psf.upfronthosting.co.za> Message-ID: <20160414125032.8336.75848.B8B58E5D@psf.io> Roundup Robot added the comment: New changeset b684298671f9 by Berker Peksag in branch '2.7': Issue #26747: Document that InstanceTypes only works for old-style classes https://hg.python.org/cpython/rev/b684298671f9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 14 08:51:40 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 14 Apr 2016 12:51:40 +0000 Subject: [docs] [issue26747] types.InstanceType only for old style class only in 2.7 In-Reply-To: <1460561340.28.0.563389556375.issue26747@psf.upfronthosting.co.za> Message-ID: <1460638300.48.0.110139940673.issue26747@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks! ---------- nosy: +berker.peksag resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 14 08:52:19 2016 From: report at bugs.python.org (STINNER Victor) Date: Thu, 14 Apr 2016 12:52:19 +0000 Subject: [docs] [issue26638] Avoid warnings about missing CLI options when building documentation In-Reply-To: <1458881380.09.0.599104229044.issue26638@psf.upfronthosting.co.za> Message-ID: <1460638339.46.0.926901334261.issue26638@psf.upfronthosting.co.za> STINNER Victor added the comment: > FTR the warnings that I am fixing were apparently enabled in Sphinx 1.3.4, reverted in 1.3.6, and added in 1.4. Would it be possible to turn off the warning? Doc/using/cmdline.py uses ".. cmdoption::". If we cannot turn off the warning on option, maybe we should use a new :cmdoption:`xxx` which wouldn't emit a warning? I'm not strongly opposed to doc-warnings.patch. I understand that Sphinx expects the exact option, for example -W, whereas the doc uses option with parameter like -Wd. Sphinx is unable to link to the option. Maybe we need something like :cmdoption:`-Wd <-W>`: display -Wd but link to -W? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 14 09:23:32 2016 From: report at bugs.python.org (Luiz Poleto) Date: Thu, 14 Apr 2016 13:23:32 +0000 Subject: [docs] [issue26749] Update devguide to include Fedora's DNF In-Reply-To: <1460625402.77.0.764520755327.issue26749@psf.upfronthosting.co.za> Message-ID: Luiz Poleto added the comment: Nice! Thanks! On Thu, Apr 14, 2016, 5:16 AM Berker Peksag wrote: > > Berker Peksag added the comment: > > Committed in 0ed2497e5aa4. Thanks for the patch, Luiz. > > ---------- > components: +Devguide -Documentation > nosy: +berker.peksag, ezio.melotti, willingc > resolution: -> fixed > stage: -> resolved > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From tanqi at bytedance.com Thu Apr 14 09:35:15 2016 From: tanqi at bytedance.com (=?UTF-8?B?6LCt5aWH?=) Date: Thu, 14 Apr 2016 21:35:15 +0800 Subject: [docs] python Documentation bugs Message-ID: Hi ? I find bug for the use of keyword ?with?, as follow: with open('workfile', 'r') as f: read_data = f.read() f.closed url:https://docs.python.org/2/tutorial/inputoutput.html f.closed is not necessary? as ?with? is very good handling exceptions Thinks? -- Growth-RD F2-403 ?? TEL?18513622028 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at timgolden.me.uk Thu Apr 14 09:44:50 2016 From: mail at timgolden.me.uk (Tim Golden) Date: Thu, 14 Apr 2016 14:44:50 +0100 Subject: [docs] python Documentation bugs In-Reply-To: References: Message-ID: <570F9ED2.4040003@timgolden.me.uk> On 14/04/2016 14:35, ?? wrote: > Hi ? > I find bug for the use of keyword ?with?, as follow: > > with open('workfile', 'r') as f: > read_data = f.read() > f.closed > > url:https://docs.python.org/2/tutorial/inputoutput.html > > f.closed is not necessary? as ?with? is very good handling exceptions I'm afraid you misunderstand: the "f.closed" line isn't *calling* a function (and the function would be, in any case, "f.close()" without final d). It's showing the f.closed attribute to demonstrate that the file is in fact closed. TJG From report at bugs.python.org Thu Apr 14 11:27:08 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 14 Apr 2016 15:27:08 +0000 Subject: [docs] [issue26706] Update OpenSSL version in readme In-Reply-To: <1459974987.74.0.0926215654006.issue26706@psf.upfronthosting.co.za> Message-ID: <20160414152335.8354.84653.0F5EC6F1@psf.io> Roundup Robot added the comment: New changeset 4936b2723471 by Zachary Ware in branch '3.5': Issue #26706: Update OpenSSL version in PCbuild/readme.txt https://hg.python.org/cpython/rev/4936b2723471 New changeset 430f5a23a853 by Zachary Ware in branch 'default': Closes #26706: Merge with 3.5 https://hg.python.org/cpython/rev/430f5a23a853 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 14 11:28:46 2016 From: report at bugs.python.org (Zachary Ware) Date: Thu, 14 Apr 2016 15:28:46 +0000 Subject: [docs] [issue26706] Update OpenSSL version in readme In-Reply-To: <1459974987.74.0.0926215654006.issue26706@psf.upfronthosting.co.za> Message-ID: <1460647726.32.0.907706594384.issue26706@psf.upfronthosting.co.za> Zachary Ware added the comment: Thanks, Shaun! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 14 19:24:15 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 14 Apr 2016 23:24:15 +0000 Subject: [docs] [issue26638] Avoid warnings about missing CLI options when building documentation In-Reply-To: <1458881380.09.0.599104229044.issue26638@psf.upfronthosting.co.za> Message-ID: <1460676255.19.0.526689084285.issue26638@psf.upfronthosting.co.za> Martin Panter added the comment: I?m not an expert on Sphinx. Maybe could help with disabling these warnings. Considering there are so many false positives, it might be best to disable the warning. Though my patch does have a few genuine improvements as well. I already used the :option:`-Wd <-W>` syntax in some cases; see Doc/library/warnings.rst for example. The problem in unittest.rst is I think Sphinx is trying to find a -W option defined within unittest.rst (with the unittest --buffer etc options), rather than the main Python options from using/cmdline.rst. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 14 23:35:29 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Apr 2016 03:35:29 +0000 Subject: [docs] [issue15984] Wrong documentation for PyUnicode_FromObject() and PyUnicode_FromEncodedObject() In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za> Message-ID: <20160415033526.19501.75844.A3387E72@psf.io> Roundup Robot added the comment: New changeset af655e73f7bd by Martin Panter in branch '3.5': Issue #15984: Correct PyUnicode_FromObject() and _FromEncodedObject() docs https://hg.python.org/cpython/rev/af655e73f7bd New changeset 570ada02d0f0 by Martin Panter in branch 'default': Issue #15984: Merge PyUnicode doc from 3.5 https://hg.python.org/cpython/rev/570ada02d0f0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 15 00:47:02 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 15 Apr 2016 04:47:02 +0000 Subject: [docs] [issue26535] Minor typo in the docs for struct.unpack In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za> Message-ID: <1460695622.75.0.960628481469.issue26535@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a new patch: * Use ?The buffer?s size in bytes? wording * Avoid brackets inside brackets * Fix the three unpack functions and corresponding methods * Also fix doc strings ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 15 00:48:08 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 15 Apr 2016 04:48:08 +0000 Subject: [docs] [issue15984] Wrong documentation for PyUnicode_FromObject() and PyUnicode_FromEncodedObject() In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za> Message-ID: <1460695688.61.0.284052822161.issue15984@psf.upfronthosting.co.za> Martin Panter added the comment: I also tweaked the PyUnicode_FromEncodedObject() documentation to avoid the word ?coerce? and to fix up outdated stuff. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 15 01:42:26 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Apr 2016 05:42:26 +0000 Subject: [docs] [issue26535] Minor typo in the docs for struct.unpack In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za> Message-ID: <1460698946.43.0.543327208905.issue26535@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Seems you forgot to send a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 15 02:00:59 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 15 Apr 2016 06:00:59 +0000 Subject: [docs] [issue26535] Minor typo in the docs for struct.unpack In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za> Message-ID: <1460700059.6.0.277401820251.issue26535@psf.upfronthosting.co.za> Martin Panter added the comment: Indeed, let me try again ---------- Added file: http://bugs.python.org/file42462/struct-size.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 15 03:24:46 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 15 Apr 2016 07:24:46 +0000 Subject: [docs] [issue26535] Minor typo in the docs for struct.unpack In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za> Message-ID: <1460705086.43.0.894288003478.issue26535@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- assignee: docs at python -> martin.panter stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 15 05:16:22 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 15 Apr 2016 09:16:22 +0000 Subject: [docs] [issue19444] mmap.mmap() allocates a file descriptor that isn't CLOEXEC In-Reply-To: <1383110349.25.0.857290073089.issue19444@psf.upfronthosting.co.za> Message-ID: <1460711782.72.0.687806551571.issue19444@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- assignee: docs at python -> components: -Documentation versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 15 07:21:51 2016 From: report at bugs.python.org (Ivan Pozdeev) Date: Fri, 15 Apr 2016 11:21:51 +0000 Subject: [docs] [issue26768] Fix instructions at WindowsCompilers for MSVC/SDKs Message-ID: <1460719311.17.0.00683602776456.issue26768@psf.upfronthosting.co.za> New submission from Ivan Pozdeev: Current instructions at https://wiki.python.org/moin/WindowsCompilers for a number of items are insufficient to make things work out of the box. This has lead to widespread confusion and a lot of vastly different and invariably hacky/unreliable/unmaintainable "alternative" guides on the Net (see e.g. the sheer volume of crappy advice at http://stackoverflow.com/questions/2817869/error-unable-to-find-vcvarsall-bat and http://stackoverflow.com/questions/4676728/value-error-trying-to-install-python-for-windows-extensions). The first patch fixes that for SDKs 6.1,7.0,7.1 (details are in the patch's Subject). The second one mentions VS Express' limitation that leads to an obscure error in distutils which resulted in https://bugs.python.org/issue7511 . Unlike other (all?) instructions circling around the Net, these are NOT hacks and are intended to be official recommendations. I tested them to work with 2.7 and 3.2 on an x32 with no prior development tools installed. I also checked other instructions applicable to these versions to be okay. I didn't touch the ''mingw'' section because, according to https://bugs.python.org/issue4709 , it can't really be officially supported as it is now. ---------- assignee: docs at python components: Build, Documentation, Windows files: 0001-fix-winsdk.patch keywords: patch messages: 263474 nosy: Ivan.Pozdeev, docs at python, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Fix instructions at WindowsCompilers for MSVC/SDKs type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file42468/0001-fix-winsdk.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 15 07:22:27 2016 From: report at bugs.python.org (Ivan Pozdeev) Date: Fri, 15 Apr 2016 11:22:27 +0000 Subject: [docs] [issue26768] Fix instructions at WindowsCompilers for MSVC/SDKs In-Reply-To: <1460719311.17.0.00683602776456.issue26768@psf.upfronthosting.co.za> Message-ID: <1460719347.6.0.304028034971.issue26768@psf.upfronthosting.co.za> Changes by Ivan Pozdeev : Added file: http://bugs.python.org/file42469/0002-VS-Express.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 15 07:29:45 2016 From: report at bugs.python.org (Ivan Pozdeev) Date: Fri, 15 Apr 2016 11:29:45 +0000 Subject: [docs] [issue26768] Fix instructions at WindowsCompilers for MSVC/SDKs In-Reply-To: <1460719311.17.0.00683602776456.issue26768@psf.upfronthosting.co.za> Message-ID: <1460719785.89.0.268354949413.issue26768@psf.upfronthosting.co.za> Ivan Pozdeev added the comment: I preferred DISTUTILS_USE_SDK to MSSDK because the latter is a hack intended for private, advanced use rather than as the standard way: it makes distutils stop guessing and rely on the user to set the environment correctly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 15 07:33:44 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 15 Apr 2016 11:33:44 +0000 Subject: [docs] [issue26768] Fix instructions at WindowsCompilers for MSVC/SDKs In-Reply-To: <1460719311.17.0.00683602776456.issue26768@psf.upfronthosting.co.za> Message-ID: <1460720024.16.0.055491765901.issue26768@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the detailed report and for the patch, Ivan. But since https://wiki.python.org/moin/WindowsCompilers is a wiki document, you can edit it yourself. Please send an email to pydotorg-www at python.org with your account name. See https://wiki.python.org/moin/FrontPage#use for details. ---------- nosy: +berker.peksag resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 15 07:53:42 2016 From: report at bugs.python.org (Ivan Pozdeev) Date: Fri, 15 Apr 2016 11:53:42 +0000 Subject: [docs] [issue26768] Fix instructions at WindowsCompilers for MSVC/SDKs In-Reply-To: <1460719311.17.0.00683602776456.issue26768@psf.upfronthosting.co.za> Message-ID: <1460721222.87.0.477775090445.issue26768@psf.upfronthosting.co.za> Ivan Pozdeev added the comment: I know it's a wiki. But this particular page is marked ImmutablePage and I couldn't edit it even after I registered, so I thought It's protected. I'll try the e-mail now. ---------- resolution: third party -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 15 07:54:20 2016 From: report at bugs.python.org (Ivan Pozdeev) Date: Fri, 15 Apr 2016 11:54:20 +0000 Subject: [docs] [issue26768] Fix instructions at WindowsCompilers for MSVC/SDKs In-Reply-To: <1460719311.17.0.00683602776456.issue26768@psf.upfronthosting.co.za> Message-ID: <1460721260.33.0.418439976586.issue26768@psf.upfronthosting.co.za> Changes by Ivan Pozdeev : ---------- resolution: -> third party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 15 07:55:47 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 15 Apr 2016 11:55:47 +0000 Subject: [docs] [issue20699] Document that binary IO classes work with bytes-likes objects In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <1460721344.46.0.383130391003.issue20699@psf.upfronthosting.co.za> Martin Panter added the comment: Here is an updated patch merged with recent changes. I also added a sentence to the RawIOBase.write() and BufferedIOBase.write() documentation about access to the buffer after the method returns. And I added tests for this. ---------- Added file: http://bugs.python.org/file42470/bytes-like-param.v5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 15 19:45:32 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 15 Apr 2016 23:45:32 +0000 Subject: [docs] [issue26535] Minor typo in the docs for struct.unpack In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za> Message-ID: <20160415234528.107504.61235.FA4C37C9@psf.io> Roundup Robot added the comment: New changeset 7889fcb0697b by Martin Panter in branch '3.5': Issue #26535: Correct docs regarding the struct buffer size https://hg.python.org/cpython/rev/7889fcb0697b New changeset 39dc2f39373d by Martin Panter in branch 'default': Issue #26535: Merge struct doc from 3.5 https://hg.python.org/cpython/rev/39dc2f39373d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 15 20:22:08 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 Apr 2016 00:22:08 +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: <20160416002157.12729.67722.949FA6B1@psf.io> Roundup Robot added the comment: New changeset c42a9233af04 by Martin Panter in branch '2.7': Issue #25314: Remove confused statement about const argument https://hg.python.org/cpython/rev/c42a9233af04 New changeset 59b8db278e3c by Martin Panter in branch '3.5': Issue #25314: Remove confused statement about const argument https://hg.python.org/cpython/rev/59b8db278e3c New changeset 7d61a991f405 by Martin Panter in branch 'default': Issue #25314: Merge argparse doc from 3.5 https://hg.python.org/cpython/rev/7d61a991f405 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 15 22:33:17 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 16 Apr 2016 02:33:17 +0000 Subject: [docs] [issue26535] Minor typo in the docs for struct.unpack In-Reply-To: <1457664319.61.0.475981364973.issue26535@psf.upfronthosting.co.za> Message-ID: <1460773997.93.0.107469892565.issue26535@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 16 00:04:57 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 16 Apr 2016 04:04:57 +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: <1460779497.41.0.975095652646.issue25314@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 16 03:47:28 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 Apr 2016 07:47:28 +0000 Subject: [docs] [issue26638] Avoid warnings about missing CLI options when building documentation In-Reply-To: <1458881380.09.0.599104229044.issue26638@psf.upfronthosting.co.za> Message-ID: <20160416074725.403.4946.97A3F1C4@psf.io> Roundup Robot added the comment: New changeset 23a884c32a39 by Martin Panter in branch '3.5': Issue #26638: Fix links to some CLI options and section headings https://hg.python.org/cpython/rev/23a884c32a39 New changeset 68b84643dffd by Martin Panter in branch 'default': Issue #26638: Merge link fixes from 3.5 https://hg.python.org/cpython/rev/68b84643dffd New changeset 3e0321584f23 by Martin Panter in branch '2.7': Issue #26638: Fix links to some CLI options https://hg.python.org/cpython/rev/3e0321584f23 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 16 06:42:30 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 16 Apr 2016 10:42:30 +0000 Subject: [docs] [issue26638] Avoid warnings about missing CLI options when building documentation In-Reply-To: <1458881380.09.0.599104229044.issue26638@psf.upfronthosting.co.za> Message-ID: <1460803350.4.0.895602152033.issue26638@psf.upfronthosting.co.za> Martin Panter added the comment: I committed the parts of my patch that improve real links in the end result. doc-warnings.v2.patch has the remaining changes which add exclamation marks to mask undefined options. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 16 06:46:17 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 16 Apr 2016 10:46:17 +0000 Subject: [docs] [issue26638] Avoid warnings about missing CLI options when building documentation In-Reply-To: <1458881380.09.0.599104229044.issue26638@psf.upfronthosting.co.za> Message-ID: <1460803577.49.0.268458095589.issue26638@psf.upfronthosting.co.za> Changes by Martin Panter : Added file: http://bugs.python.org/file42481/doc-warnings.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 16 06:47:30 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 16 Apr 2016 10:47:30 +0000 Subject: [docs] [issue26638] Avoid warnings about missing CLI options when building documentation In-Reply-To: <1458881380.09.0.599104229044.issue26638@psf.upfronthosting.co.za> Message-ID: <1460803650.4.0.2239081487.issue26638@psf.upfronthosting.co.za> Martin Panter added the comment: This patch disables the warning, but I tend to think it is not a good long-term solution. ---------- Added file: http://bugs.python.org/file42482/disable-warning.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 16 10:06:45 2016 From: report at bugs.python.org (Brandon Rhodes) Date: Sat, 16 Apr 2016 14:06:45 +0000 Subject: [docs] [issue26780] Illustrate both binary operator conventions in PEP-8 Message-ID: <1460815604.66.0.184242188494.issue26780@psf.upfronthosting.co.za> New submission from Brandon Rhodes: I am delighted to see that PEP-8 has pivoted to breaking long formulae before, rather than after, each binary operator! But I would like to pivot the PEP away from citing my own PyCon Canada talk as the authority on the matter, and toward citing Knuth himself. It would also be an enhancement for the PEP to show both options and make an argument for the practice, instead of simply asserting that one is better than the other. I therefore propose the attached patch. ---------- assignee: docs at python components: Documentation files: pep8-knuth.patch keywords: patch messages: 263554 nosy: barry, brandon-rhodes, docs at python, gvanrossum priority: normal severity: normal status: open title: Illustrate both binary operator conventions in PEP-8 Added file: http://bugs.python.org/file42487/pep8-knuth.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 16 10:08:37 2016 From: report at bugs.python.org (Brandon Rhodes) Date: Sat, 16 Apr 2016 14:08:37 +0000 Subject: [docs] [issue26780] Illustrate both binary operator conventions in PEP-8 In-Reply-To: <1460815604.66.0.184242188494.issue26780@psf.upfronthosting.co.za> Message-ID: <1460815717.44.0.597298531565.issue26780@psf.upfronthosting.co.za> Changes by Brandon Rhodes : Removed file: http://bugs.python.org/file42487/pep8-knuth.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 16 10:09:11 2016 From: report at bugs.python.org (Brandon Rhodes) Date: Sat, 16 Apr 2016 14:09:11 +0000 Subject: [docs] [issue26780] Illustrate both binary operator conventions in PEP-8 In-Reply-To: <1460815604.66.0.184242188494.issue26780@psf.upfronthosting.co.za> Message-ID: <1460815751.4.0.354922686541.issue26780@psf.upfronthosting.co.za> Changes by Brandon Rhodes : Added file: http://bugs.python.org/file42489/pep8-knuth.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 16 14:14:37 2016 From: report at bugs.python.org (Brandon Rhodes) Date: Sat, 16 Apr 2016 18:14:37 +0000 Subject: [docs] [issue26780] Illustrate both binary operator conventions in PEP-8 In-Reply-To: <1460815604.66.0.184242188494.issue26780@psf.upfronthosting.co.za> Message-ID: <1460830477.17.0.654752736917.issue26780@psf.upfronthosting.co.za> Brandon Rhodes added the comment: Another important objection against the current text is that it stacks a series of `and` and `or` operators at the same level of indentation, as though they naturally evaluate in the order the programmer writes them. In fact, they have different levels of precedence, and the code example violates the other sections of PEP-8 that ask for the creation of a visual distinction in code between different precedence levels. The example needs to pivot towards a series of operators which belong at the same precedence level. I have used `+` and `-` because they seemed more natural to form an example from than something like division and multiplication. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 16 14:14:59 2016 From: report at bugs.python.org (Brandon Rhodes) Date: Sat, 16 Apr 2016 18:14:59 +0000 Subject: [docs] [issue26780] Illustrate both binary operator conventions in PEP-8 In-Reply-To: <1460815604.66.0.184242188494.issue26780@psf.upfronthosting.co.za> Message-ID: <1460830499.43.0.652943608405.issue26780@psf.upfronthosting.co.za> Changes by Brandon Rhodes : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 16 15:28:03 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 16 Apr 2016 19:28:03 +0000 Subject: [docs] [issue25989] documentation version switcher is broken fro 2.6, 3.2, 3.3 In-Reply-To: <1451692017.71.0.123733949867.issue25989@psf.upfronthosting.co.za> Message-ID: <1460834883.61.0.153165163675.issue25989@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report, but as I said in the GitHub issue, the version switcher works as expected (we don't build docs of security-only-fix branches). ---------- nosy: +berker.peksag resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 16 16:14:29 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 16 Apr 2016 20:14:29 +0000 Subject: [docs] [issue24173] curses HOWTO/implementation disagreement In-Reply-To: <1431506529.99.0.82682445605.issue24173@psf.upfronthosting.co.za> Message-ID: <20160416201425.70527.2271.16B6C4B9@psf.io> Roundup Robot added the comment: New changeset 5c9cda2bdfd2 by Berker Peksag in branch '2.7': Issue #24173: Fix curses.wrapper link in curses HOWTO https://hg.python.org/cpython/rev/5c9cda2bdfd2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 16 16:15:17 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 16 Apr 2016 20:15:17 +0000 Subject: [docs] [issue24173] curses HOWTO/implementation disagreement In-Reply-To: <1431506529.99.0.82682445605.issue24173@psf.upfronthosting.co.za> Message-ID: <1460837717.5.0.203374027496.issue24173@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report! 3.x docs have already been updated. ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 16 17:12:32 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 16 Apr 2016 21:12:32 +0000 Subject: [docs] [issue26780] Illustrate both binary operator conventions in PEP-8 In-Reply-To: <1460815604.66.0.184242188494.issue26780@psf.upfronthosting.co.za> Message-ID: <1460841152.81.0.460743121792.issue26780@psf.upfronthosting.co.za> Guido van Rossum added the comment: Patch LGTM. Note that the and/or example was in the PEP before this discussion broke out. The discussion also at some point (before your Knuth quote was discovered) veered in the direction of making and/or a special case, perhaps because it's more likely that a long expression must be broken around and/or operators. And there were already examples of breaking after binary arithmetic operators elsewhere in the PEP (I think). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 17 11:39:17 2016 From: report at bugs.python.org (Ivan Levkivskyi) Date: Sun, 17 Apr 2016 15:39:17 +0000 Subject: [docs] [issue25987] collections.abc.Reversible In-Reply-To: <1451685633.1.0.273350637631.issue25987@psf.upfronthosting.co.za> Message-ID: <1460907557.3.0.347423566085.issue25987@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: I see that I forgot to include .. versionadded:: in the documentation. Will this go into 3.5.2 or in 3.6? ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 17 19:02:32 2016 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 17 Apr 2016 23:02:32 +0000 Subject: [docs] [issue25987] collections.abc.Reversible In-Reply-To: <1451685633.1.0.273350637631.issue25987@psf.upfronthosting.co.za> Message-ID: <1460934152.68.0.894570522342.issue25987@psf.upfronthosting.co.za> Guido van Rossum added the comment: Because it's a change to collections.abc, it goes in 3.6 only. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 17 21:55:02 2016 From: report at bugs.python.org (Antony Lee) Date: Mon, 18 Apr 2016 01:55:02 +0000 Subject: [docs] [issue26792] docstrings of runpy.run_{module, path} are rather sparse Message-ID: <1460944502.67.0.955110104065.issue26792@psf.upfronthosting.co.za> New submission from Antony Lee: $ pydoc runpy run_module(mod_name, init_globals=None, run_name=None, alter_sys=False) Execute a module's code without importing it Returns the resulting top level namespace dictionary run_path(path_name, init_globals=None, run_name=None) Execute code located at the specified filesystem location Returns the resulting top level namespace dictionary The file path may refer directly to a Python script (i.e. one that could be directly executed with execfile) or else it may refer to a zipfile or directory containing a top level __main__.py script. The meaning of the arguments should be documented (e.g. by copy-pasting the html docs). (And some sentences are missing final dots.) ---------- assignee: docs at python components: Documentation messages: 263638 nosy: Antony.Lee, docs at python priority: normal severity: normal status: open title: docstrings of runpy.run_{module,path} are rather sparse versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 18 01:26:12 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 Apr 2016 05:26:12 +0000 Subject: [docs] [issue25987] collections.abc.Reversible In-Reply-To: <1451685633.1.0.273350637631.issue25987@psf.upfronthosting.co.za> Message-ID: <20160418052602.88648.87702.884C3893@psf.io> Roundup Robot added the comment: New changeset 7d9f7d7a21ae by Georg Brandl in branch 'default': #25987: add versionadded to Reversible. https://hg.python.org/cpython/rev/7d9f7d7a21ae ---------- _______________________________________ Python tracker _______________________________________ From emilie at cs.ucsb.edu Sun Apr 17 18:43:43 2016 From: emilie at cs.ucsb.edu (Emilie Menard Barnard) Date: Sun, 17 Apr 2016 15:43:43 -0700 Subject: [docs] Doc Bug Message-ID: <8543D9D3-4C15-4EE2-B426-F8C411F424B4@cs.ucsb.edu> Hi there, I found a small typo in the documentation for 3.5 under turtle?s circle function explanation. It reads: "Draw a circle with given radius. The center is radius units left of the turtle? but it should read "Draw a circle with given radius. The center is radius units above the turtle? Thanks, Emilie -------------- next part -------------- An HTML attachment was scrubbed... URL: From report at bugs.python.org Mon Apr 18 09:48:11 2016 From: report at bugs.python.org (Marat Sharafutdinov) Date: Mon, 18 Apr 2016 13:48:11 +0000 Subject: [docs] [issue26795] Fix PEP 344 Python version Message-ID: <1460987291.12.0.969662098571.issue26795@psf.upfronthosting.co.za> New submission from Marat Sharafutdinov: Should be 3.0 instead of 2.5 ---------- assignee: docs at python components: Documentation files: pep-0344-version.patch keywords: patch messages: 263667 nosy: decaz, docs at python priority: normal severity: normal status: open title: Fix PEP 344 Python version type: enhancement Added file: http://bugs.python.org/file42505/pep-0344-version.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 18 09:56:17 2016 From: report at bugs.python.org (SilentGhost) Date: Mon, 18 Apr 2016 13:56:17 +0000 Subject: [docs] [issue26795] Fix PEP 344 Python version In-Reply-To: <1460987291.12.0.969662098571.issue26795@psf.upfronthosting.co.za> Message-ID: <1460987777.56.0.539564115077.issue26795@psf.upfronthosting.co.za> SilentGhost added the comment: I think the note at the top makes it perfectly clear that PEP 344 is superseded by PEP 3134 which has correct Python version. ---------- nosy: +SilentGhost resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 18 14:19:51 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 18 Apr 2016 18:19:51 +0000 Subject: [docs] [issue26615] Missing entry in WRAPPER_ASSIGNMENTS in update_wrapper's doc In-Reply-To: <1458704141.94.0.68234227835.issue26615@psf.upfronthosting.co.za> Message-ID: <20160418181948.7131.91870.FC6AD19F@psf.io> Roundup Robot added the comment: New changeset 11d8f5d1968d by Berker Peksag in branch '3.5': Issue #26615: Add missing __qualname__ entry to functools.update_wrapper() docs https://hg.python.org/cpython/rev/11d8f5d1968d New changeset ee9921b29fd8 by Berker Peksag in branch 'default': Issue #26615: Add missing __qualname__ entry to functools.update_wrapper() docs https://hg.python.org/cpython/rev/ee9921b29fd8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 18 14:21:42 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 18 Apr 2016 18:21:42 +0000 Subject: [docs] [issue26615] Missing entry in WRAPPER_ASSIGNMENTS in update_wrapper's doc In-Reply-To: <1458704141.94.0.68234227835.issue26615@psf.upfronthosting.co.za> Message-ID: <1461003702.67.0.948680020395.issue26615@psf.upfronthosting.co.za> Berker Peksag added the comment: __qualname__ was added to WRAPPER_ASSIGNMENTS in 963e98f5ad31 (issue 13544). Thanks for the patch! ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 18 20:01:54 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 19 Apr 2016 00:01:54 +0000 Subject: [docs] [issue23251] mention in time.sleep() docs that it does not block other Python threads In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za> Message-ID: <1461024114.79.0.329071711205.issue23251@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 18 20:07:35 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 19 Apr 2016 00:07:35 +0000 Subject: [docs] [issue13826] Having a shlex example in the subprocess.Popen docs is confusing In-Reply-To: <1326983115.48.0.551767400168.issue13826@psf.upfronthosting.co.za> Message-ID: <1461024455.39.0.307411582417.issue13826@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +easy stage: -> needs patch versions: +Python 3.5, Python 3.6 -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 19 08:25:44 2016 From: report at bugs.python.org (Paul Moore) Date: Tue, 19 Apr 2016 12:25:44 +0000 Subject: [docs] [issue26805] Refer to types.SimpleNamespace in namedtuple documentation Message-ID: <1461068744.46.0.957777609901.issue26805@psf.upfronthosting.co.za> New submission from Paul Moore: People often look towards collections.namedtuple when all they actually want is "named attribute" access to a collection of values, without needing a tuple subclass, or positional access. In these cases, types.SimpleNamespace may be a better fit. I suggest adding the following pointer to the top of the namedtuple documentation: """ For simple uses, where the only requirement is to be able to refer to a set of values by name using attribute-style access, the :ref:`types.SimpleNamespace` type may be a suitable alternative to using a namedtuple. """ ---------- assignee: docs at python components: Documentation messages: 263733 nosy: docs at python, paul.moore priority: normal severity: normal status: open title: Refer to types.SimpleNamespace in namedtuple documentation type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 19 08:29:00 2016 From: report at bugs.python.org (Chris Angelico) Date: Tue, 19 Apr 2016 12:29:00 +0000 Subject: [docs] [issue26805] Refer to types.SimpleNamespace in namedtuple documentation In-Reply-To: <1461068744.46.0.957777609901.issue26805@psf.upfronthosting.co.za> Message-ID: <1461068940.44.0.424316998767.issue26805@psf.upfronthosting.co.za> Changes by Chris Angelico : ---------- nosy: +Rosuav _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 19 08:36:38 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 19 Apr 2016 12:36:38 +0000 Subject: [docs] [issue26805] Refer to types.SimpleNamespace in namedtuple documentation In-Reply-To: <1461068744.46.0.957777609901.issue26805@psf.upfronthosting.co.za> Message-ID: <1461069398.67.0.82174197494.issue26805@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +easy stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 19 09:09:54 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 19 Apr 2016 13:09:54 +0000 Subject: [docs] [issue23710] C API doc for PyObject_HEAD is outdated In-Reply-To: <1426776099.01.0.644113037586.issue23710@psf.upfronthosting.co.za> Message-ID: <1461071394.91.0.617805222538.issue23710@psf.upfronthosting.co.za> Berker Peksag added the comment: Docs of PyObject_HEAD and friends have already been fixed in 760c5cfacbaa. https://docs.python.org/3/extending/newtypes.html still needs to be updated to mention ob_base: This is what a Noddy object will contain?in this case, nothing more than what every Python object contains?a refcount and a pointer to a type object. These are the fields the PyObject_HEAD macro brings in. ---------- keywords: +easy nosy: +berker.peksag stage: -> needs patch type: -> behavior versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 19 09:10:41 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 19 Apr 2016 13:10:41 +0000 Subject: [docs] [issue9014] Incorrect documentation of the PyObject_HEAD macro In-Reply-To: <1276718330.85.0.16685449654.issue9014@psf.upfronthosting.co.za> Message-ID: <1461071441.01.0.354362381052.issue9014@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: commit review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 19 09:13:16 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 19 Apr 2016 13:13:16 +0000 Subject: [docs] [issue11233] clarifying Availability: Unix In-Reply-To: <1297969399.53.0.187875867799.issue11233@psf.upfronthosting.co.za> Message-ID: <1461071596.95.0.319014486525.issue11233@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: needs patch -> patch review type: -> enhancement versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 19 09:41:06 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 19 Apr 2016 13:41:06 +0000 Subject: [docs] [issue22297] 2.7 json encoding broken for enums In-Reply-To: <1409310034.91.0.63329091583.issue22297@psf.upfronthosting.co.za> Message-ID: <1461073265.98.0.573334771669.issue22297@psf.upfronthosting.co.za> Berker Peksag added the comment: -1 from me, too. ---------- nosy: +berker.peksag stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 19 09:44:09 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Apr 2016 13:44:09 +0000 Subject: [docs] [issue26805] Refer to types.SimpleNamespace in namedtuple documentation In-Reply-To: <1461068744.46.0.957777609901.issue26805@psf.upfronthosting.co.za> Message-ID: <1461073449.32.0.349983675487.issue26805@psf.upfronthosting.co.za> STINNER Victor added the comment: LGTM. I was going to push your sugestion when I saw that you are allowed to push yourself. See my attached patch: * I fixed :ref:`types.SimpleNamespace` => you have to use :class:`...` * I replaced "may be" with "can be" (I'm not confortable with "may", but it's up to you) ---------- keywords: +patch nosy: +haypo Added file: http://bugs.python.org/file42520/collections.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 19 10:02:06 2016 From: report at bugs.python.org (Paul Moore) Date: Tue, 19 Apr 2016 14:02:06 +0000 Subject: [docs] [issue26805] Refer to types.SimpleNamespace in namedtuple documentation In-Reply-To: <1461068744.46.0.957777609901.issue26805@psf.upfronthosting.co.za> Message-ID: <1461074526.82.0.728625121386.issue26805@psf.upfronthosting.co.za> Paul Moore added the comment: Thanks Victor. I'll sort this out this evening when I get to my PC with access to the CPython repo. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 19 10:53:32 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Apr 2016 14:53:32 +0000 Subject: [docs] [issue11233] clarifying Availability: Unix In-Reply-To: <1297969399.53.0.187875867799.issue11233@psf.upfronthosting.co.za> Message-ID: <1461077612.74.0.240613605755.issue11233@psf.upfronthosting.co.za> STINNER Victor added the comment: I like the idea of a single place where the Availability is described, and adding a link to this place. availability-directive.patch LGTM. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 19 11:33:42 2016 From: report at bugs.python.org (Yoni Lavi) Date: Tue, 19 Apr 2016 15:33:42 +0000 Subject: [docs] [issue22558] Missing doc links to source code In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1461080022.59.0.76569236859.issue22558@psf.upfronthosting.co.za> Changes by Yoni Lavi : ---------- nosy: +Yoni Lavi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 19 13:09:24 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 19 Apr 2016 17:09:24 +0000 Subject: [docs] [issue1612012] builtin compile() doc needs PyCF_DONT_IMPLY_DEDENT Message-ID: <1461085764.26.0.343806399829.issue1612012@psf.upfronthosting.co.za> Berker Peksag added the comment: A similar request (issue 12207 - "Document ast.PyCF_ONLY_AST") was rejected in 2012. ---------- nosy: +berker.peksag resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 19 14:20:11 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 19 Apr 2016 18:20:11 +0000 Subject: [docs] [issue26805] Refer to types.SimpleNamespace in namedtuple documentation In-Reply-To: <1461068744.46.0.957777609901.issue26805@psf.upfronthosting.co.za> Message-ID: <20160419181913.107502.94499.D543EDB6@psf.io> Roundup Robot added the comment: New changeset c3232d1d8ca0 by Paul Moore in branch 'default': Mention types.SimpleNamespace in collections.namedtuple doc https://hg.python.org/cpython/rev/c3232d1d8ca0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 19 14:22:02 2016 From: report at bugs.python.org (Paul Moore) Date: Tue, 19 Apr 2016 18:22:02 +0000 Subject: [docs] [issue26805] Refer to types.SimpleNamespace in namedtuple documentation In-Reply-To: <1461068744.46.0.957777609901.issue26805@psf.upfronthosting.co.za> Message-ID: <1461090122.17.0.242495017771.issue26805@psf.upfronthosting.co.za> Changes by Paul Moore : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 19 15:22:09 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Apr 2016 19:22:09 +0000 Subject: [docs] [issue26805] Refer to types.SimpleNamespace in namedtuple documentation In-Reply-To: <1461068744.46.0.957777609901.issue26805@psf.upfronthosting.co.za> Message-ID: <1461093729.1.0.535784457933.issue26805@psf.upfronthosting.co.za> STINNER Victor added the comment: types.SimpleNamespace is also available on Python 3.5, you may also modify Python 3.5 doc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 19 15:54:44 2016 From: report at bugs.python.org (Paul Moore) Date: Tue, 19 Apr 2016 19:54:44 +0000 Subject: [docs] [issue26805] Refer to types.SimpleNamespace in namedtuple documentation In-Reply-To: <1461068744.46.0.957777609901.issue26805@psf.upfronthosting.co.za> Message-ID: <1461095684.35.0.687168977893.issue26805@psf.upfronthosting.co.za> Paul Moore added the comment: Ah, thanks. I probably did the commit the wrong way round in that case, as I committed to tip. How should I do the commit into 3.5? (I'm also somewhat confused by the fact that hg describes the 3.5 branch as "inactive"...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 19 16:14:07 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 19 Apr 2016 20:14:07 +0000 Subject: [docs] [issue26805] Refer to types.SimpleNamespace in namedtuple documentation In-Reply-To: <1461095684.35.0.687168977893.issue26805@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I don't know what "inactive" means in Mercurial. Python 3.5 is actively developed (maintained): https://docs.python.org/devguide/#status-of-python-branches > How should I do the commit into 3.5? Update to 3.5 (hg up 3.5), transplant your change (hg transplant c3232d1d8ca0). Fix if needed. I don't recall if you need to commit or not (commit if you get the patch as local changes). Then update to default (hg update default), and merge 3.5 (hg merge 3.5). Commit. https://docs.python.org/devguide/devcycle.html#branches ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 19 16:36:16 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 19 Apr 2016 20:36:16 +0000 Subject: [docs] [issue26805] Refer to types.SimpleNamespace in namedtuple documentation In-Reply-To: <1461068744.46.0.957777609901.issue26805@psf.upfronthosting.co.za> Message-ID: <1461098176.76.0.600273809947.issue26805@psf.upfronthosting.co.za> Berker Peksag added the comment: Or if you don't want to use any hg extension: hg update 3.5 hg import --no-c http://bugs.python.org/file42520/collections.patch hg commit hg update default hg merge 3.5 hg revert -ar default hg resolve -am hg commit (Null merge (hg merge 3.5 and later) is step documented at https://docs.python.org/devguide/faq.html?#how-do-i-make-a-null-merge) ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 19 18:00:01 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 19 Apr 2016 22:00:01 +0000 Subject: [docs] [issue26805] Refer to types.SimpleNamespace in namedtuple documentation In-Reply-To: <1461068744.46.0.957777609901.issue26805@psf.upfronthosting.co.za> Message-ID: <20160419215957.88648.75456.2E053A59@psf.io> Roundup Robot added the comment: New changeset 3115b6ce1006 by Paul Moore in branch '3.5': Mention types.SimpleNamespace in collections.namedtuple doc https://hg.python.org/cpython/rev/3115b6ce1006 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 19 22:28:29 2016 From: report at bugs.python.org (Yoni Lavi) Date: Wed, 20 Apr 2016 02:28:29 +0000 Subject: [docs] [issue22558] Missing doc links to source code In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za> Message-ID: <1461119309.01.0.971873164456.issue22558@psf.upfronthosting.co.za> Yoni Lavi added the comment: I went over all the library rst files and added a link to the source for each of the modules. Also, I standardized the structure of the headers in all of the files to be in the following order: """ .. module .. moduleauthor .. sectionauthor .. versionadded **Source code:** .. testsetup .. index -------------- """ This'll be my first Python patch. Please let me know if I chose to go into too large of a scope and should split this, or if there's anything else I can improve. Also, since I'm modifying most of these files anyway, this might be a good opportunity to modify the header structure I mentioned above. Thanks ---------- keywords: +patch Added file: http://bugs.python.org/file42527/mywork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 20 02:15:35 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 20 Apr 2016 06:15:35 +0000 Subject: [docs] [issue26780] Illustrate both binary operator conventions in PEP-8 In-Reply-To: <1460815604.66.0.184242188494.issue26780@psf.upfronthosting.co.za> Message-ID: <20160420061532.26075.85780.3AC3293F@psf.io> Roundup Robot added the comment: New changeset 9afe77ad549b by Senthil Kumaran in branch 'default': PEP-8 Update on Knuth style breaking of a long formula. #issue26780 https://hg.python.org/peps/rev/9afe77ad549b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 20 02:17:58 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 20 Apr 2016 06:17:58 +0000 Subject: [docs] [issue26780] Illustrate both binary operator conventions in PEP-8 In-Reply-To: <1460815604.66.0.184242188494.issue26780@psf.upfronthosting.co.za> Message-ID: <1461133078.89.0.293396595427.issue26780@psf.upfronthosting.co.za> Senthil Kumaran added the comment: The patch is committed in changeset 9afe77ad549b. Thanks for update Brandon. Citing the original source and stating the rationale for this suggestion was a great addition. ---------- nosy: +orsenthil resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From kari.kinnunen at musicinfo.fi Tue Apr 19 07:19:15 2016 From: kari.kinnunen at musicinfo.fi (Kari Kinnunen) Date: Tue, 19 Apr 2016 14:19:15 +0300 Subject: [docs] possible bug Message-ID: <57161433.3020105@musicinfo.fi> Hi, I found a problem in my code. This line has no problem ... m = re.search("'(\\w+.\\w+)", str(args.rule[0])) ... until i add next line.. str = ".*(" Traceback (most recent call last): File "....py", line 332, in main() File "....py", line 122, in main m = re.search("'(\\w+.\\w+)", str(args.rule[0])) UnboundLocalError: local variable 'str' referenced before assignment If I remove 'str = ..' line, then everything is again ok. Best regards, Kari Kinnunen From report at bugs.python.org Wed Apr 20 08:24:40 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 20 Apr 2016 12:24:40 +0000 Subject: [docs] [issue20001] pathlib inheritance diagram too large In-Reply-To: <1387221538.52.0.488414928183.issue20001@psf.upfronthosting.co.za> Message-ID: <1461155080.67.0.944188880462.issue20001@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +easy stage: -> needs patch type: -> enhancement versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From zachary.ware+pydocs at gmail.com Wed Apr 20 15:40:52 2016 From: zachary.ware+pydocs at gmail.com (Zachary Ware) Date: Wed, 20 Apr 2016 14:40:52 -0500 Subject: [docs] possible bug In-Reply-To: <57161433.3020105@musicinfo.fi> References: <57161433.3020105@musicinfo.fi> Message-ID: Hi Kari, On Tue, Apr 19, 2016 at 6:19 AM, Kari Kinnunen wrote: > Hi, > > I found a problem in my code. > > This line has no problem ... > > m = re.search("'(\\w+.\\w+)", str(args.rule[0])) > > ... until i add next line.. > > str = ".*(" > > Traceback (most recent call last): > File "....py", line 332, in > main() > File "....py", line 122, in main > m = re.search("'(\\w+.\\w+)", str(args.rule[0])) > UnboundLocalError: local variable 'str' referenced before assignment > > If I remove 'str = ..' line, then everything is again ok. This is because you're trying to both use the str() builtin and name a local variable "str". Function-local variables are somewhat special in Python: if there is an assignment to a particular name anywhere within the function, all uses of that name must come after a local assignment, even if the name is also available in an outer scope. Using the name of a builtin for a purpose other than referencing that builtin is called "shadowing", and is generally best avoided. In this case, just use a different name for ".*(" instead of 'str', such as 'string' or simple 's' (although an appropriately descriptive name would be even better). For future reference, this mailing list is actually for discussion of Python's documentation and any inaccuracies found within the docs, not for general bug reports or usage questions like this. Anything like this is perfectly welcome at python-list at python.org, though! Regards, -- Zach From report at bugs.python.org Wed Apr 20 17:17:37 2016 From: report at bugs.python.org (Alexey Gorshkov) Date: Wed, 20 Apr 2016 21:17:37 +0000 Subject: [docs] [issue16679] Add advice about non-ASCII wsgiref PATH_INFO In-Reply-To: <1355473710.36.0.278942451351.issue16679@psf.upfronthosting.co.za> Message-ID: <1461187057.44.0.372042694904.issue16679@psf.upfronthosting.co.za> Alexey Gorshkov added the comment: I'm from Issue 26808. I'd like to see some explanation on: how about QUERY_STRING value? Why only PATH_INFO is encoded in such a manner, but QUERY_STRING is passed without any changes and does not requires any latin-1 to utf-8 recodings? ---------- nosy: +animus _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 20 22:50:13 2016 From: report at bugs.python.org (Luiz Poleto) Date: Thu, 21 Apr 2016 02:50:13 +0000 Subject: [docs] [issue25461] Unclear language (the word ineffective) in the documentation for os.walk In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za> Message-ID: <1461207013.51.0.169377950887.issue25461@psf.upfronthosting.co.za> Luiz Poleto added the comment: The Doc/library/os.rst bit in the current patch fails to apply in all versions specified in this bug report (it seems that it was generated before the commit that included an earlier version of it). ---------- nosy: +luiz.poleto _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 20 23:53:25 2016 From: report at bugs.python.org (Graham Dumpleton) Date: Thu, 21 Apr 2016 03:53:25 +0000 Subject: [docs] [issue16679] Add advice about non-ASCII wsgiref PATH_INFO In-Reply-To: <1355473710.36.0.278942451351.issue16679@psf.upfronthosting.co.za> Message-ID: <1461210805.59.0.721587110347.issue16679@psf.upfronthosting.co.za> Graham Dumpleton added the comment: As I commented on Issue 26808, it actually looks to me like the QUERY_STRING is processed fine and it is actually PATH_INFO that is not. I am confused at this point. I hate dealing with these WSGI level details now. :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 21 00:58:10 2016 From: report at bugs.python.org (Martin Panter) Date: Thu, 21 Apr 2016 04:58:10 +0000 Subject: [docs] [issue16679] Add advice about non-ASCII wsgiref PATH_INFO In-Reply-To: <1355473710.36.0.278942451351.issue16679@psf.upfronthosting.co.za> Message-ID: <1461214690.42.0.395585643105.issue16679@psf.upfronthosting.co.za> Martin Panter added the comment: PEP 3333 defers to a draft CGI specification for PATH_INFO and QUERY_STRING: . (Dunno why it didn?t reference the final RFC 3875 instead, published 2004.) Anyway, both draft and final RFCs say ?PATH_INFO is not URL-encoded?, but ?the QUERY_STRING variable contains a URL-encoded search or parameter string?. Graham, maybe you are seeing Latin-1 code points in PATH_INFO that have been translated from the %XX URL syntax, and QUERY_STRING retaining the original %XX syntax. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 21 01:16:09 2016 From: report at bugs.python.org (Graham Dumpleton) Date: Thu, 21 Apr 2016 05:16:09 +0000 Subject: [docs] [issue16679] Add advice about non-ASCII wsgiref PATH_INFO In-Reply-To: <1355473710.36.0.278942451351.issue16679@psf.upfronthosting.co.za> Message-ID: <1461215769.25.0.114013932381.issue16679@psf.upfronthosting.co.za> Graham Dumpleton added the comment: What I get in Apache for: http://127.0.0.1:8000/a=???? in Safari browser is: 'REQUEST_URI': '/a=%D1%82%D0%B5%D1%81%D1%82', 'PATH_INFO': '/a=\xc3\x91\\x82\xc3\x90\xc2\xb5\xc3\x91\\x81\xc3\x91\\x82', Where as for curl see: 'REQUEST_URI': '/a=\xc3\x91\\x82\xc3\x90\xc2\xb5\xc3\x91\\x81\xc3\x91\\x82', 'PATH_INFO': '/a=\xc3\x91\\x82\xc3\x90\xc2\xb5\xc3\x91\\x81\xc3\x91\\x82', For: http://127.0.0.1:8000/?a=???? in Safari get: 'REQUEST_URI': '/?a=%D1%82%D0%B5%D1%81%D1%82', 'PATH_INFO': '/' 'QUERY_STRING': 'a=%D1%82%D0%B5%D1%81%D1%82', and curl: 'REQUEST_URI': '/?a=\xc3\x91\\x82\xc3\x90\xc2\xb5\xc3\x91\\x81\xc3\x91\\x82', 'PATH_INFO': '/', 'QUERY_STRING': 'a=\xc3\x91\\x82\xc3\x90\xc2\xb5\xc3\x91\\x81\xc3\x91\\x82', So yes curl sends as bytes rather than encoded, expected that. Gunicorn on: http://127.0.0.1:8000/a=???? sees for Safari: 'PATH_INFO': '/a=?\x82???\x81?\x82', 'QUERY_STRING': '', 'RAW_URI': '/a=%D1%82%D0%B5%D1%81%D1%82', and curl: 'PATH_INFO': '/a=?\x91?\x82?\x90???\x91?\x81?\x91?\x82', 'QUERY_STRING': '', 'RAW_URI': '/a=?\x82???\x81?\x82', Gunicorn on: http://127.0.0.1:8000/?a=???? sees for Safari: 'PATH_INFO': '/', 'QUERY_STRING': 'a=%D1%82%D0%B5%D1%81%D1%82', 'RAW_URI': '/?a=%D1%82%D0%B5%D1%81%D1%82', and curl: 'PATH_INFO': '/', 'QUERY_STRING': 'a=?\x82???\x81?\x82', 'RAW_URI': '/?a=?\x82???\x81?\x82', So in Apache I get through UTF-8 byte string as Latin-1. So can see multi byte characters. Gunicorn is doing something different when gets raw bytes from curl. As does wsgiref. Showed Gunicorn as it has RAW_URI which is supposed to be the same as REQUEST_URI in Apache, but actually isn't showing the same there either. Whatever is happening, mod_wsgi still gives a good outcome. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 21 01:51:03 2016 From: report at bugs.python.org (Ken Miura) Date: Thu, 21 Apr 2016 05:51:03 +0000 Subject: [docs] [issue26813] Wrong Japanese translation of "Adverb" on Documentation Message-ID: <1461217863.36.0.239729021285.issue26813@psf.upfronthosting.co.za> New submission from Ken Miura: In Japanese Python document, English word "Adverb" is translated to "????", but it's "??" actually. http://docs.python.jp/2/library/re.html#finding-all-adverbs http://docs.python.jp/2/library/re.html#finding-all-adverbs-and-their-positions ---------- assignee: docs at python components: Documentation messages: 263881 nosy: Ken Miura, docs at python priority: normal severity: normal status: open title: Wrong Japanese translation of "Adverb" on Documentation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 21 02:16:40 2016 From: report at bugs.python.org (INADA Naoki) Date: Thu, 21 Apr 2016 06:16:40 +0000 Subject: [docs] [issue26813] Wrong Japanese translation of "Adverb" on Documentation In-Reply-To: <1461217863.36.0.239729021285.issue26813@psf.upfronthosting.co.za> Message-ID: <1461219400.71.0.0104497487312.issue26813@psf.upfronthosting.co.za> INADA Naoki added the comment: Thank you for reporting. Japanese translation team has own issue tracker in Github. I copied this issue to https://github.com/python-doc-ja/python-doc-ja/issues/733 ---------- nosy: +naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 21 02:26:04 2016 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 21 Apr 2016 06:26:04 +0000 Subject: [docs] [issue26813] Wrong Japanese translation of "Adverb" on Documentation In-Reply-To: <1461217863.36.0.239729021285.issue26813@psf.upfronthosting.co.za> Message-ID: <1461219964.32.0.361776432543.issue26813@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> third party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 21 09:31:25 2016 From: report at bugs.python.org (Thomas Guettler) Date: Thu, 21 Apr 2016 13:31:25 +0000 Subject: [docs] [issue26817] Docs for StringIO should link to io.BytesIO Message-ID: <1461245485.84.0.279459146406.issue26817@psf.upfronthosting.co.za> New submission from Thomas Guettler: I think a warning at the top of StringIO docs is needed. And it should link to io.BytesIO. Maybe even deprecate StringIO and cStringIO in Python2? StringIO docs: https://docs.python.org/2/library/stringio.html io.BytesIO docs: https://docs.python.org/2/library/io.html#io.BytesIO I would like to see this at the top of StringIO: {{{ Please use io.BytesIO and io.StringIO since this module is not supported in Python3 }} ---------- assignee: docs at python components: Documentation messages: 263917 nosy: docs at python, guettli priority: normal severity: normal status: open title: Docs for StringIO should link to io.BytesIO versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 21 09:49:25 2016 From: report at bugs.python.org (Berker Peksag) Date: Thu, 21 Apr 2016 13:49:25 +0000 Subject: [docs] [issue12743] C API marshalling doc contains XXX In-Reply-To: <1313160183.82.0.137409262179.issue12743@psf.upfronthosting.co.za> Message-ID: <1461246565.27.0.301924248731.issue12743@psf.upfronthosting.co.za> Berker Peksag added the comment: Since 4059e871e74e, PyMarshal_ReadLongFromFile and PyMarshal_ReadShortFromFile can return -1 on error. Return values of those functions were already documented in acb4d43955f6. Some of the usages also check return value of PyErr_Occurred(): https://hg.python.org/cpython/rev/11958c69a4b2#l2.7 I removed the outdated paragraph and add a sentence about using PyErr_Occurred(). ---------- keywords: +patch nosy: +berker.peksag, haypo stage: needs patch -> patch review versions: +Python 3.5, Python 3.6 Added file: http://bugs.python.org/file42555/issue12743.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 21 13:55:05 2016 From: report at bugs.python.org (Andrew Clover) Date: Thu, 21 Apr 2016 17:55:05 +0000 Subject: [docs] [issue16679] Add advice about non-ASCII wsgiref PATH_INFO In-Reply-To: <1355473710.36.0.278942451351.issue16679@psf.upfronthosting.co.za> Message-ID: <1461261305.6.0.692296553328.issue16679@psf.upfronthosting.co.za> Andrew Clover added the comment: > Why only PATH_INFO is encoded in such a manner, but QUERY_STRING is passed without any changes and does not requires any latin-1 to utf-8 recodings? Laziness: QUERY_STRING should be pure-ASCII, making any such transcoding a no-op. In principle a user agent *can* submit non-ASCII characters in a query string without %-encoding them, but it's not standards-conformant and most browsers don't usually do it (exception: apparently curl as above), so it's not worth adding a layer of hopefully-fixing-but-potentially-mangling to this variable to support a situation that shouldn't arise for normal requests. PATH_INFO only requires special handling because of the sad, sad historical artefact of the CGI spec requiring it to have URL-decoding applied to it at the gateway, thus making the non-ASCII characters pop out of the percentage woodwork. @Graham can you share more about how those test results were generated and displayed? The Gunicorn results are about what I would expect - the double-decoding of PATH_INFO is arguably undesirable when curl submits raw bytes, but ultimately that's an unspecified situation so I don't really case. The output from Apache, on the other hand, is odd - something appears to have mangled the results at the reporting stage as not only is there double-decoding but also some double-backslashes. It looks like the strings have been put through ascii(repr()) or something? ---------- nosy: +Andrew Clover _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 21 15:07:41 2016 From: report at bugs.python.org (Jonathan Booth) Date: Thu, 21 Apr 2016 19:07:41 +0000 Subject: [docs] [issue26821] array module "minimum size in bytes" table is wrong for int/long Message-ID: <1461265661.42.0.761639464385.issue26821@psf.upfronthosting.co.za> New submission from Jonathan Booth: https://docs.python.org/3.5/library/array.html describes the 'I' and 'i' typecodes as being minimum-size in bytes of 2. The interpreter disagrees: >>> import array >>> a = array.array('i') >>> a.itemsize 4 There is also a bug with the 'L' and 'l' long typecodes, which document as min-size of 4 bytes but are 8 bytes in the interpreter. That could be a bug in cPython itself though, as if 'L' should be 8 bytes, that disagrees with the type code sizing from the struct module, where it is 4 bytes, just like integers. I checked documentation for all versions of python and it matches -- I did not check all python interpreters to see they match, but 2.7 and 3.5 did. ---------- assignee: docs at python components: Documentation messages: 263931 nosy: Jonathan Booth, docs at python priority: normal severity: normal status: open title: array module "minimum size in bytes" table is wrong for int/long 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 Thu Apr 21 15:54:39 2016 From: report at bugs.python.org (Graham Dumpleton) Date: Thu, 21 Apr 2016 19:54:39 +0000 Subject: [docs] [issue16679] Add advice about non-ASCII wsgiref PATH_INFO In-Reply-To: <1355473710.36.0.278942451351.issue16679@psf.upfronthosting.co.za> Message-ID: <1461268479.21.0.0628001576877.issue16679@psf.upfronthosting.co.za> Graham Dumpleton added the comment: Double back slashes would possibly be an artefact of the some mess that happens when logging out through the Apache error log. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 21 16:36:08 2016 From: report at bugs.python.org (random832) Date: Thu, 21 Apr 2016 20:36:08 +0000 Subject: [docs] [issue26821] array module "minimum size in bytes" table is wrong for int/long In-Reply-To: <1461265661.42.0.761639464385.issue26821@psf.upfronthosting.co.za> Message-ID: <1461270968.04.0.0972980027032.issue26821@psf.upfronthosting.co.za> random832 added the comment: It says *minimum* size for a reason. The *actual* sizes of the types used in array are platform-dependent. 2 is the smallest that an int can be (it is probably not that size on any currently supported platforms, but would have been in DOS), and 4 is the smallest size a long can be (any 32-bit python build, and I think also any build on Windows, will have it be this size). ---------- nosy: +random832 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 21 18:25:03 2016 From: report at bugs.python.org (Jonathan Booth) Date: Thu, 21 Apr 2016 22:25:03 +0000 Subject: [docs] [issue26821] array module "minimum size in bytes" table is wrong for int/long In-Reply-To: <1461265661.42.0.761639464385.issue26821@psf.upfronthosting.co.za> Message-ID: <1461277503.01.0.139322535648.issue26821@psf.upfronthosting.co.za> Jonathan Booth added the comment: Ugly -- if I know I'm dealing with 4-byte data, I can't just specify 'I' or 'L' because it'll be wrong on some platform? Maybe the bug is really the module's design. Seems I need to look elsewhere for other reasons (array seems to want to copy memory, rather than sharing it, so I can't get two arrays one int, one byte with the same backing memory where changes to one effect the other), but that's all the more argument for me to switch off array anyway. In any case, take it as the documentation wasn't particularly clear. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 22 01:08:56 2016 From: report at bugs.python.org (Georg Brandl) Date: Fri, 22 Apr 2016 05:08:56 +0000 Subject: [docs] [issue26821] array module "minimum size in bytes" table is wrong for int/long In-Reply-To: <1461265661.42.0.761639464385.issue26821@psf.upfronthosting.co.za> Message-ID: <1461301736.42.0.0901839317311.issue26821@psf.upfronthosting.co.za> Georg Brandl added the comment: Indeed, I don't think the `array` module is much used anymore. If you're looking to serialize or deserialize fixed-size formats, you'll probably want the `struct` module. It has both native and fixed-size modes. For anything else involving arrays (mostly, but not exclusively, of numbers), just use numpy. It has a much more developed system of data types for its arrays, and supports views. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 22 01:22:21 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 22 Apr 2016 05:22:21 +0000 Subject: [docs] [issue26821] array module "minimum size in bytes" table is wrong for int/long In-Reply-To: <1461265661.42.0.761639464385.issue26821@psf.upfronthosting.co.za> Message-ID: <1461302541.68.0.643379416425.issue26821@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > I can't get two arrays one int, one byte with the same backing memory where changes to one effect the other For this case you can use an array or bytearray + memoryview. I think this issue can be closed. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 22 01:27:21 2016 From: report at bugs.python.org (Georg Brandl) Date: Fri, 22 Apr 2016 05:27:21 +0000 Subject: [docs] [issue26821] array module "minimum size in bytes" table is wrong for int/long In-Reply-To: <1461265661.42.0.761639464385.issue26821@psf.upfronthosting.co.za> Message-ID: <1461302841.61.0.65663521978.issue26821@psf.upfronthosting.co.za> Georg Brandl added the comment: Agreed. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 22 08:08:15 2016 From: report at bugs.python.org (Herbert) Date: Fri, 22 Apr 2016 12:08:15 +0000 Subject: [docs] [issue26827] PyObject *PyInit_myextention -> PyMODINIT_FUNC PyInit_myextention Message-ID: <1461326895.36.0.898462963597.issue26827@psf.upfronthosting.co.za> New submission from Herbert: I think PyObject *PyInit_myextention(void) should be PyMODINIT_FUNC PyInit_myextention(void) on https://docs.python.org/3/howto/cporting.html#module-initialization-and-state It didn't work for me until I replaced this with a message in the about 'undefined PyInit_myextention'. However, when I used nm to inspect the .so object file, I fond the PyInit_myextention (but probably with the wrong return type). Moreover, whenever I would remove the same .so importing resulted in a different error complaining that the module does not exist (strongly suggesting that I did not mix up .so files). Good luck! ---------- assignee: docs at python components: Documentation messages: 264005 nosy: docs at python, prinsherbert priority: normal severity: normal status: open title: PyObject *PyInit_myextention -> PyMODINIT_FUNC PyInit_myextention versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 22 08:09:57 2016 From: report at bugs.python.org (Herbert) Date: Fri, 22 Apr 2016 12:09:57 +0000 Subject: [docs] [issue26827] PyObject *PyInit_myextention -> PyMODINIT_FUNC PyInit_myextention In-Reply-To: <1461326895.36.0.898462963597.issue26827@psf.upfronthosting.co.za> Message-ID: <1461326997.03.0.74413294796.issue26827@psf.upfronthosting.co.za> Herbert added the comment: The exact error was: ImportError: dynamic module does not define init function (PyInit_myextension) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 22 10:03:54 2016 From: report at bugs.python.org (Ethan Furman) Date: Fri, 22 Apr 2016 14:03:54 +0000 Subject: [docs] [issue26829] update docs: when creating classes a new dict is created for the final class object Message-ID: <1461333834.83.0.0321229546915.issue26829@psf.upfronthosting.co.za> New submission from Ethan Furman: https://docs.python.org/3/reference/datamodel.html#creating-the-class-object This section should mention that the final class is created with a new dict(), and all key/value pairs from the dict used during creation are copied over. ---------- assignee: docs at python components: Documentation messages: 264016 nosy: docs at python, ethan.furman priority: normal severity: normal status: open title: update docs: when creating classes a new dict is created for the final class object versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 22 11:48:34 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 22 Apr 2016 15:48:34 +0000 Subject: [docs] [issue26827] PyObject *PyInit_myextention -> PyMODINIT_FUNC PyInit_myextention In-Reply-To: <1461326895.36.0.898462963597.issue26827@psf.upfronthosting.co.za> Message-ID: <1461340114.34.0.228244617883.issue26827@psf.upfronthosting.co.za> Brett Cannon added the comment: https://docs.python.org/3/extending/extending.html#the-module-s-method-table-and-initialization-function documents what Herbert discovered wrong in the porting docs. ---------- keywords: +easy nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 22 11:49:11 2016 From: report at bugs.python.org (Brett Cannon) Date: Fri, 22 Apr 2016 15:49:11 +0000 Subject: [docs] [issue26827] PyObject *PyInit_myextention -> PyMODINIT_FUNC PyInit_myextention In-Reply-To: <1461326895.36.0.898462963597.issue26827@psf.upfronthosting.co.za> Message-ID: <1461340151.7.0.190878129079.issue26827@psf.upfronthosting.co.za> Brett Cannon added the comment: And in case my comment wasn't obvious, Herbert is right about the error in the docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 22 20:47:43 2016 From: report at bugs.python.org (Martin Panter) Date: Sat, 23 Apr 2016 00:47:43 +0000 Subject: [docs] [issue16679] Add advice about non-ASCII wsgiref PATH_INFO In-Reply-To: <1355473710.36.0.278942451351.issue16679@psf.upfronthosting.co.za> Message-ID: <1461372463.48.0.534497443582.issue16679@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 22 22:03:04 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 23 Apr 2016 02:03:04 +0000 Subject: [docs] [issue23806] documentation for no_proxy is missing from the python3 urllib documentation In-Reply-To: <1427640986.55.0.996928918568.issue23806@psf.upfronthosting.co.za> Message-ID: <1461376984.7.0.585477364931.issue23806@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +easy versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 22 23:35:49 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Apr 2016 03:35:49 +0000 Subject: [docs] [issue23806] documentation for no_proxy is missing from the python3 urllib documentation In-Reply-To: <1427640986.55.0.996928918568.issue23806@psf.upfronthosting.co.za> Message-ID: <20160423033546.381.15342.E377F2F1@psf.io> Roundup Robot added the comment: New changeset 5424a559ddea by Senthil Kumaran in branch '3.5': Issue23806 - Document the no_proxy environment variable in Python 3 docs. https://hg.python.org/cpython/rev/5424a559ddea New changeset 103fb8be940b by Senthil Kumaran in branch 'default': merge 3.5 https://hg.python.org/cpython/rev/103fb8be940b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 22 23:37:59 2016 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 23 Apr 2016 03:37:59 +0000 Subject: [docs] [issue23806] documentation for no_proxy is missing from the python3 urllib documentation In-Reply-To: <1427640986.55.0.996928918568.issue23806@psf.upfronthosting.co.za> Message-ID: <1461382679.55.0.186323689816.issue23806@psf.upfronthosting.co.za> Senthil Kumaran added the comment: no_proxy is applicable to ProxyHandler of the python 3. I've documented this in the corresponding section. ---------- nosy: +orsenthil resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 23 02:43:32 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Apr 2016 06:43:32 +0000 Subject: [docs] [issue26827] PyObject *PyInit_myextention -> PyMODINIT_FUNC PyInit_myextention In-Reply-To: <1461326895.36.0.898462963597.issue26827@psf.upfronthosting.co.za> Message-ID: <20160423064328.26189.27314.94AAC9F0@psf.io> Roundup Robot added the comment: New changeset 188af2b4945a by Benjamin Peterson in branch '3.5': fix python 3 mod init function declaration (closes #26827) https://hg.python.org/cpython/rev/188af2b4945a New changeset df0e900b8860 by Benjamin Peterson in branch 'default': merge 3.5 (#26827) https://hg.python.org/cpython/rev/df0e900b8860 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 23 02:49:22 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Apr 2016 06:49:22 +0000 Subject: [docs] [issue26827] PyObject *PyInit_myextention -> PyMODINIT_FUNC PyInit_myextention In-Reply-To: <1461326895.36.0.898462963597.issue26827@psf.upfronthosting.co.za> Message-ID: <20160423064919.15818.18212.55BF5C6F@psf.io> Roundup Robot added the comment: New changeset 8d6bd32a56a8 by Benjamin Peterson in branch '2.7': fix python 3 mod init function declaration (closes #26827) https://hg.python.org/cpython/rev/8d6bd32a56a8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 23 16:00:26 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 23 Apr 2016 20:00:26 +0000 Subject: [docs] [issue1283110] Give __len__() advice for "don't know" Message-ID: <1461441626.04.0.360407459239.issue1283110@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 23 18:51:22 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Apr 2016 22:51:22 +0000 Subject: [docs] [issue20112] The documentation for http.server error_message_format is inadequate. In-Reply-To: <1388701952.2.0.132957137739.issue20112@psf.upfronthosting.co.za> Message-ID: <20160423225118.119498.33367.6CDE8E43@psf.io> Roundup Robot added the comment: New changeset a912ca4f507b by Berker Peksag in branch '3.5': Issue #20112: Improve BaseHTTPRequestHandler.error_message_format documentation https://hg.python.org/cpython/rev/a912ca4f507b New changeset baed33df1aed by Berker Peksag in branch 'default': Issue #20112: Improve BaseHTTPRequestHandler.error_message_format documentation https://hg.python.org/cpython/rev/baed33df1aed ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 23 18:52:23 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 23 Apr 2016 22:52:23 +0000 Subject: [docs] [issue20112] The documentation for http.server error_message_format is inadequate. In-Reply-To: <1388701952.2.0.132957137739.issue20112@psf.upfronthosting.co.za> Message-ID: <1461451943.65.0.154672113328.issue20112@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Anastasia. ---------- nosy: +berker.peksag resolution: -> fixed stage: needs patch -> resolved status: open -> closed versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 23 19:59:31 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 23 Apr 2016 23:59:31 +0000 Subject: [docs] [issue21382] Signal module doesnt raises ValueError Exception In-Reply-To: <1398759436.39.0.420418396293.issue21382@psf.upfronthosting.co.za> Message-ID: <20160423235926.31833.28776.27076379@psf.io> Roundup Robot added the comment: New changeset 1fcf68e6f4c7 by Berker Peksag in branch '3.5': Issue #21382: Clarify signal.signal() documentation on Windows https://hg.python.org/cpython/rev/1fcf68e6f4c7 New changeset 3e27b21e3a7d by Berker Peksag in branch 'default': Issue #21382: Clarify signal.signal() documentation on Windows https://hg.python.org/cpython/rev/3e27b21e3a7d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 23 19:59:58 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 23 Apr 2016 23:59:58 +0000 Subject: [docs] [issue21382] Signal module doesnt raises ValueError Exception In-Reply-To: <1398759436.39.0.420418396293.issue21382@psf.upfronthosting.co.za> Message-ID: <1461455998.77.0.39138202283.issue21382@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 23 20:06:49 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Apr 2016 00:06:49 +0000 Subject: [docs] [issue18353] PyUnicode_WRITE_CHAR macro definition missing In-Reply-To: <1372873387.67.0.379053408423.issue18353@psf.upfronthosting.co.za> Message-ID: <20160424000646.21466.95581.314E4708@psf.io> Roundup Robot added the comment: New changeset 29e555e5956b by Berker Peksag in branch '3.5': Issue #18353: Remove PyUnicode_WRITE_CHAR macro link from c-api/unicode.rst https://hg.python.org/cpython/rev/29e555e5956b New changeset 8c53fdc011a3 by Berker Peksag in branch 'default': Issue #18353: Remove PyUnicode_WRITE_CHAR macro link from c-api/unicode.rst https://hg.python.org/cpython/rev/8c53fdc011a3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 23 20:07:37 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 24 Apr 2016 00:07:37 +0000 Subject: [docs] [issue18353] PyUnicode_WRITE_CHAR macro definition missing In-Reply-To: <1372873387.67.0.379053408423.issue18353@psf.upfronthosting.co.za> Message-ID: <1461456457.35.0.929531898984.issue18353@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report Wolf and thanks for the patch Corey. ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed type: compile error -> behavior versions: +Python 3.5, Python 3.6 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 23 20:13:51 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Apr 2016 00:13:51 +0000 Subject: [docs] [issue18572] Remove redundant note about surrogates in string escape doc In-Reply-To: <1374941533.84.0.352957238503.issue18572@psf.upfronthosting.co.za> Message-ID: <20160424001346.90477.26763.86932010@psf.io> Roundup Robot added the comment: New changeset 79e7808c3941 by Berker Peksag in branch '3.5': Issue #18572: Remove redundant note about surrogates in string escape doc https://hg.python.org/cpython/rev/79e7808c3941 New changeset ee815d3535f5 by Berker Peksag in branch 'default': Issue #18572: Remove redundant note about surrogates in string escape doc https://hg.python.org/cpython/rev/ee815d3535f5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 23 20:14:43 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 24 Apr 2016 00:14:43 +0000 Subject: [docs] [issue18572] Remove redundant note about surrogates in string escape doc In-Reply-To: <1374941533.84.0.352957238503.issue18572@psf.upfronthosting.co.za> Message-ID: <1461456883.52.0.0192925852969.issue18572@psf.upfronthosting.co.za> Berker Peksag added the comment: I removed the sentence in 3.5 and default branches. ---------- nosy: +berker.peksag resolution: -> fixed stage: needs patch -> resolved status: open -> closed versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 23 20:21:24 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Apr 2016 00:21:24 +0000 Subject: [docs] [issue19731] Fix copyright footer In-Reply-To: <1385173768.12.0.946242825352.issue19731@psf.upfronthosting.co.za> Message-ID: <20160424002115.391.68696.7D7B76D3@psf.io> Roundup Robot added the comment: New changeset 7cb3364952d5 by Berker Peksag in branch '3.5': Issue #19731: Update copyright year in docs.p.o footer https://hg.python.org/cpython/rev/7cb3364952d5 New changeset fa0a941728a8 by Berker Peksag in branch 'default': Issue #19731: Update copyright year in docs.p.o footer https://hg.python.org/cpython/rev/fa0a941728a8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 23 20:25:11 2016 From: report at bugs.python.org (Berker Peksag) Date: Sun, 24 Apr 2016 00:25:11 +0000 Subject: [docs] [issue19731] Fix copyright footer In-Reply-To: <1385173768.12.0.946242825352.issue19731@psf.upfronthosting.co.za> Message-ID: <1461457511.88.0.574869873827.issue19731@psf.upfronthosting.co.za> Berker Peksag added the comment: 2001 is also appears in python.org footer. ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 24 00:16:35 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Apr 2016 04:16:35 +0000 Subject: [docs] [issue23806] documentation for no_proxy is missing from the python3 urllib documentation In-Reply-To: <1427640986.55.0.996928918568.issue23806@psf.upfronthosting.co.za> Message-ID: <20160424041632.26362.43985.0986F1D1@psf.io> Roundup Robot added the comment: New changeset 5ad93528c39c by Martin Panter in branch '3.5': Issue #23806: Update susp-ignored.csv https://hg.python.org/cpython/rev/5ad93528c39c New changeset cb38785acc8d by Martin Panter in branch 'default': Issue #23806: Merge susp-ignored.csv from 3.5 https://hg.python.org/cpython/rev/cb38785acc8d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 24 00:55:46 2016 From: report at bugs.python.org (Roundup Robot) Date: Sun, 24 Apr 2016 04:55:46 +0000 Subject: [docs] [issue24911] Context manager of socket.socket is not documented In-Reply-To: <1440189246.69.0.0632097129757.issue24911@psf.upfronthosting.co.za> Message-ID: <20160424045542.21466.22673.E8C9FA45@psf.io> Roundup Robot added the comment: New changeset d5f7980dd654 by Martin Panter in branch '3.5': Issue #24911: All socket objects are context managers; update examples https://hg.python.org/cpython/rev/d5f7980dd654 New changeset 711201953505 by Martin Panter in branch 'default': Issue #24911: Merge socket context manager doc from 3.5 https://hg.python.org/cpython/rev/711201953505 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 24 02:23:24 2016 From: report at bugs.python.org (Martin Panter) Date: Sun, 24 Apr 2016 06:23:24 +0000 Subject: [docs] [issue24911] Context manager of socket.socket is not documented In-Reply-To: <1440189246.69.0.0632097129757.issue24911@psf.upfronthosting.co.za> Message-ID: <1461479004.95.0.975594097531.issue24911@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 24 19:27:22 2016 From: report at bugs.python.org (Edward Segall) Date: Sun, 24 Apr 2016 23:27:22 +0000 Subject: [docs] [issue26842] Python Tutorial 4.7.1: Need to explain default parameter lifetime Message-ID: <1461540442.59.0.34324123093.issue26842@psf.upfronthosting.co.za> New submission from Edward Segall: I am using the tutorial to learn Python. I know many other languages, and I've taught programming language theory, but even so I found the warning in Section 4.7.1 about Default Argument Values to be confusing. After I spent some effort investigating what actually happens, I realized that the warning is incomplete. I'll suggest a fix below, after explaining what concerns me. Here is the warning in question: ----------------------------------------------------------------- Important warning: The default value is evaluated only once. This makes a difference when the default is a mutable object such as a list, dictionary, or instances of most classes. ... def f(a, L=[]): L.append(a) return L print(f(1)) print(f(2)) print(f(3)) This will print [1] [1, 2] [1, 2, 3] ----------------------------------------------------------------- It's clear from this example that values are carried from one function invocation to another. That's pretty unusual behavior for a "traditional" function, but it's certainly not unheard of -- in C/C++/Java, you can preserve state across invocations by declaring that a local variable has static lifetime. When using this capability, though, it's essential to understand exactly what's happening -- or at least well enough to anticipate its behavior under a range of conditions. I don't believe the warning and example are sufficient to convey such an understanding. After playing with it for a while, I've concluded the following: "regular" local variables have the usual behavior (called "automatic" lifetime in C/C++ jargon), as do the function's formal parameters, EXCEPT when a default value is defined. Each default value is stored in a location that has static lifetime, and THAT is the reason it matters that (per the warning) the expression defining the default value is evaluated only once. This is very unfamiliar behavior -- I don't think I have used another modern language with this feature. So I think it's important that the explanation be very clear. I would like to suggest revising the warning and example to something more like the following: ----------------------------------------------------------------- Important warning: When you define a function with a default argument value, the expression defining the default value is evaluated only once, but the resultant value persists as long as the function is defined. If this value is a mutable object such as a list, dictionary, or instance of most classes, it is possible to change that object after the function is defined, and if you do that, the new (mutated) value will subsequently be used as the default value. For example, the following function accepts two arguments: def f(a, L=[]): L.append(a) return L This function is defined with a default value for its second formal parameter, called L. The expression that defines the default value denotes an empty list. When the function is defined, this expression is evaluated once. The resultant list is saved as the default value for L. Each time the function is called, it appends the first argument to the second one by invoking the second argument's append method. If we call the function with two arguments, the default value is not used. Instead, the list that is passed in as the second argument is modified. However, if we call the function with one argument, the default value is modified. Consider the following sequence of calls. First, we define a list and pass it in each time as the second argument. This list accumulates the first arguments, as follows: myList=[] print(f(0, myList)) print(f(1, myList)) This will print: [0] [0, 1] As you can see, myList is being used to accumulate the values passed in to the first as the first argument. If we then use the default value by passing in only one argument, as follows: print(f(2)) print(f(3)) we will see: [2] [2, 3] Here, the two invocations appended values to to the default list. Let's continue, this time going back to myList: print(f(4,myList)) Now the result will be: [0, 1, 4] because myList still contains the earlier values. The default value still has its earlier values too, as we can see here: print(f(5)) [2, 3, 5] To summarize, there are two distinct cases: 1) When the function is invoked with an argument list that includes a value for L, that L (the one being passed in) is changed by the function. 2) When the function is invoked with an argument list that does not include a value for L, the default value for L is changed, and that change persists through future invocations. ----------------------------------------------------------------- I hope this is useful. I realize it is much longer than the original. I had hoped to make it shorter, but when I did I found I was glossing over important details. ---------- assignee: docs at python components: Documentation messages: 264135 nosy: docs at python, esegall priority: normal severity: normal status: open title: Python Tutorial 4.7.1: Need to explain default parameter lifetime type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 25 02:36:56 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 25 Apr 2016 06:36:56 +0000 Subject: [docs] [issue23662] Cookie.domain is undocumented In-Reply-To: <1426345280.31.0.365548742215.issue23662@psf.upfronthosting.co.za> Message-ID: <1461566216.87.0.462794909321.issue23662@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +easy stage: -> needs patch type: -> enhancement versions: +Python 3.6 -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 25 04:24:50 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 25 Apr 2016 08:24:50 +0000 Subject: [docs] [issue26842] Python Tutorial 4.7.1: Need to explain default parameter lifetime In-Reply-To: <1461540442.59.0.34324123093.issue26842@psf.upfronthosting.co.za> Message-ID: <1461572690.17.0.444168828407.issue26842@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > I hope this is useful. I realize it is much longer than the original. There lies the difficultly. The purpose of the tutorial is to quickly introduce the language, not to take someone deeply down a rabbit hole. The docs tend to be worded in an affirmative manner showing cases of the language being used properly, giving a brief warning where necessary. Further explorations should be left as FAQs. I think we could add a FAQ link or somesuch to the existing warning but the main flow shouldn't be interrupted (many on the topics in the tutorial could warrant entire blog posts and scores of StackOverflow entries, but the tutorial itself aspires to be a "short and sweet" quick tour around the language. The utility and approachability of the tutorial would be undermined by overexpanding each new topic. This is especially important in the early sections of the tutorial (i.e. section 4). Also, I don't really like the provided explanation, "there are two cases ...". The actual execution model has one case (default arguments are evaluated once when the function is defined) and there are many ways to use it. Lastly, this is only one facet of parameter specification and parameter passing. Other facets include, variable length argument lists, keyword-only arguments, annotations, etc. Any expanded coverage should occur later in the tutorial and cover all the facets collectively. ---------- nosy: +rhettinger priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 25 07:32:25 2016 From: report at bugs.python.org (Roundup Robot) Date: Mon, 25 Apr 2016 11:32:25 +0000 Subject: [docs] [issue23662] Cookie.domain is undocumented In-Reply-To: <1426345280.31.0.365548742215.issue23662@psf.upfronthosting.co.za> Message-ID: <20160425113216.24440.33452.4C633716@psf.io> Roundup Robot added the comment: New changeset 1fdaa71d47f5 by Berker Peksag in branch '3.5': Issue #23662: Document default value of RFC 2109 attributes https://hg.python.org/cpython/rev/1fdaa71d47f5 New changeset b3ad9c002bb8 by Berker Peksag in branch 'default': Issue #23662: Document default value of RFC 2109 attributes https://hg.python.org/cpython/rev/b3ad9c002bb8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 25 07:35:20 2016 From: report at bugs.python.org (Berker Peksag) Date: Mon, 25 Apr 2016 11:35:20 +0000 Subject: [docs] [issue23662] Cookie.domain is undocumented In-Reply-To: <1426345280.31.0.365548742215.issue23662@psf.upfronthosting.co.za> Message-ID: <1461584120.13.0.711330772702.issue23662@psf.upfronthosting.co.za> Berker Peksag added the comment: Actually, it's already documented at https://docs.python.org/3.5/library/http.cookies.html#http.cookies.Morsel. I just added a note about the default value of domain. ---------- nosy: +berker.peksag resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From saul.spatz at gmail.com Mon Apr 25 10:14:31 2016 From: saul.spatz at gmail.com (Saul Spatz) Date: Mon, 25 Apr 2016 09:14:31 -0500 Subject: [docs] Python 3.5.1 Documentation Bug Message-ID: Hi, In the documentation for os.mkdir, it says, "If the directory already exists, OSError is raised." On my Mac at least, FileExistsError is raised and isinstance(FileExistsError, OSError) returns False. Saul -------------- next part -------------- An HTML attachment was scrubbed... URL: From zachary.ware+pydocs at gmail.com Mon Apr 25 10:29:00 2016 From: zachary.ware+pydocs at gmail.com (Zachary Ware) Date: Mon, 25 Apr 2016 09:29:00 -0500 Subject: [docs] Python 3.5.1 Documentation Bug In-Reply-To: References: Message-ID: Hi Saul, On Mon, Apr 25, 2016 at 9:14 AM, Saul Spatz wrote: > Hi, > > In the documentation for os.mkdir, it says, "If the directory already > exists, OSError is raised." On my Mac at least, FileExistsError is raised > and isinstance(FileExistsError, OSError) returns False. You are correct that it should say FileExistsError instead of OSError, and has now been fixed. However, FileExistsError is a subclass of OSError, so catching OSError would work. Try either `issubclass(FileExistsError, OSError)` or `isinstance(FileExistsError(), OSError())`. Thanks for the report! -- Zach From saul.spatz at gmail.com Mon Apr 25 10:46:12 2016 From: saul.spatz at gmail.com (Saul Spatz) Date: Mon, 25 Apr 2016 09:46:12 -0500 Subject: [docs] Python 3.5.1 Documentation Bug In-Reply-To: References: Message-ID: Hi Zachary, Thanks for the clarification. I should have realized you have to call the constructors in isinstance. Saul On Mon, Apr 25, 2016 at 9:29 AM, Zachary Ware wrote: > Hi Saul, > > On Mon, Apr 25, 2016 at 9:14 AM, Saul Spatz wrote: > > Hi, > > > > In the documentation for os.mkdir, it says, "If the directory already > > exists, OSError is raised." On my Mac at least, FileExistsError is > raised > > and isinstance(FileExistsError, OSError) returns False. > > You are correct that it should say FileExistsError instead of OSError, > and has now been fixed. However, FileExistsError is a subclass of > OSError, so catching OSError would work. Try either > `issubclass(FileExistsError, OSError)` or > `isinstance(FileExistsError(), OSError())`. > > Thanks for the report! > -- > Zach > -------------- next part -------------- An HTML attachment was scrubbed... URL: From report at bugs.python.org Mon Apr 25 13:08:47 2016 From: report at bugs.python.org (Edward Segall) Date: Mon, 25 Apr 2016 17:08:47 +0000 Subject: [docs] [issue26842] Python Tutorial 4.7.1: Need to explain default parameter lifetime In-Reply-To: <1461540442.59.0.34324123093.issue26842@psf.upfronthosting.co.za> Message-ID: <1461604127.51.0.101130929166.issue26842@psf.upfronthosting.co.za> Edward Segall added the comment: I agree with most of your points: A tutorial should be brief and should not go down rabbit holes. Expanded discussion of default parameter behavior would probably fit better with the other facets of parameter speceification and parameter passing, perhaps as a FAQ. But I also believe a change to the current presentation is needed. Perhaps it would be best to introduce default arguments using simple numerical types, and refer to a separate explanation (perhaps as a FAQ) of the complexities associated with using mutable objects as defaults. > Also, I don't really like the provided explanation, "there are two cases ...". The actual execution model has one case (default arguments are evaluated once when the function is defined) and there are many ways to use it. The distinction between the two cases lies in storage of the result, not in argument evaluation. In the non-default case, the result is stored in a caller-provided object, while in the default case, the result is stored in a callee-provided object. This results in different behaviors (as the example makes clear); hence the two cases are not the same. This distinction is important to new users because it's necessary to think of them differently, and because (to me, at least) one of them is very non-intuitive. In both cases, the change made to the object is a side effect of the function. In the non-default case, this side effect is directly visible to the caller, but in the default case, it is only indirectly visible. Details like this are probably obvious to people who are very familiar with both call by object reference and to Python's persistent lifetime of default argument objects, but I don't think that group fits the target audience for a tutorial. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 25 23:15:40 2016 From: report at bugs.python.org (Luke) Date: Tue, 26 Apr 2016 03:15:40 +0000 Subject: [docs] [issue26847] filter docs unclear wording Message-ID: <1461640540.65.0.428299683802.issue26847@psf.upfronthosting.co.za> New submission from Luke: The current docs for both filter and itertools.filterfalse use the following wording (emphasis added): all elements that are false are removed returns the items that are false This could be confusing for a new Python programmer, because the actual behaviour is that elements are equality-compared, not identity-compared. Suggested wording: "are equal to False" https://docs.python.org/3.5/library/functions.html#filter https://docs.python.org/3.5/library/itertools.html#itertools.filterfalse ---------- assignee: docs at python components: Documentation messages: 264206 nosy: docs at python, unfamiliarplace priority: normal severity: normal status: open title: filter docs unclear wording type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 00:01:43 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 26 Apr 2016 04:01:43 +0000 Subject: [docs] [issue26847] filter docs unclear wording In-Reply-To: <1461640540.65.0.428299683802.issue26847@psf.upfronthosting.co.za> Message-ID: <1461643303.82.0.971813643764.issue26847@psf.upfronthosting.co.za> Josh Rosenberg added the comment: "are equal to False" would be wrong though. Any "falsy" value is preserved by filterfalse, and removed by filter. They need not be equal to False (the bool singleton); empty containers (e.g. (), [], {}, "") are all considered false, and behave as such, despite not being equal to False. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 00:02:24 2016 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 26 Apr 2016 04:02:24 +0000 Subject: [docs] [issue26847] filter docs unclear wording In-Reply-To: <1461640540.65.0.428299683802.issue26847@psf.upfronthosting.co.za> Message-ID: <1461643344.18.0.507761925377.issue26847@psf.upfronthosting.co.za> Josh Rosenberg added the comment: That's why lower case "false" is used, not "False"; the former is the loose definition, the latter is the strict singleton. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 00:22:02 2016 From: report at bugs.python.org (Luke) Date: Tue, 26 Apr 2016 04:22:02 +0000 Subject: [docs] [issue26847] filter docs unclear wording In-Reply-To: <1461640540.65.0.428299683802.issue26847@psf.upfronthosting.co.za> Message-ID: <1461644522.81.0.575078374949.issue26847@psf.upfronthosting.co.za> Luke added the comment: josh, we're saying the same thing but misunderstanding each other. :) I realize that they can be empty containers, etc., and that's why I think "equal to False" is appropriate -- because those things *are* equal to False: >>> [] == False True >>> 0 == False True etc. However, they are not identical to False: >>> [] is False False >>> 0 is False False And that's why I think the wording "are false" is potentially misleading. Perhaps there's a better wording than "equal to False" (compares equivalently to False? or simply: are falsey? :p), but anyhow, we're identifying the same behaviour here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 01:44:46 2016 From: report at bugs.python.org (Georg Brandl) Date: Tue, 26 Apr 2016 05:44:46 +0000 Subject: [docs] [issue26847] filter docs unclear wording In-Reply-To: <1461640540.65.0.428299683802.issue26847@psf.upfronthosting.co.za> Message-ID: <1461649486.44.0.626465176902.issue26847@psf.upfronthosting.co.za> Georg Brandl added the comment: You didn't test your examples: >>> [] == False False False is not equal to the "empty value" of any other type than other numeric types. (This is mostly because of how booleans were originally introduced to Python.) "is false", on the other hand, is the conventional shorthand for `bool(x) == False`. ---------- nosy: +georg.brandl resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 02:15:02 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 26 Apr 2016 06:15:02 +0000 Subject: [docs] [issue26512] Vocabulary: Using "integral" in library/stdtypes.html In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za> Message-ID: <1461651302.15.0.700764625771.issue26512@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 03:10:09 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 26 Apr 2016 07:10:09 +0000 Subject: [docs] [issue16394] Reducing tee() memory footprint In-Reply-To: <1351955719.4.0.453680036148.issue16394@psf.upfronthosting.co.za> Message-ID: <20160426071005.13103.6510.E9221192@psf.io> Roundup Robot added the comment: New changeset f09306f9fa6f by Raymond Hettinger in branch 'default': Issue #16394: Note the tee() pure python equivalent is only a rough approximation. https://hg.python.org/cpython/rev/f09306f9fa6f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 03:11:17 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 26 Apr 2016 07:11:17 +0000 Subject: [docs] [issue16394] Reducing tee() memory footprint In-Reply-To: <1351955719.4.0.453680036148.issue16394@psf.upfronthosting.co.za> Message-ID: <1461654677.81.0.439842852948.issue16394@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 03:37:22 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 26 Apr 2016 07:37:22 +0000 Subject: [docs] [issue26842] Python Tutorial 4.7.1: Need to explain default parameter lifetime In-Reply-To: <1461540442.59.0.34324123093.issue26842@psf.upfronthosting.co.za> Message-ID: <1461656242.92.0.226127923921.issue26842@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Sorry but I'm going to reject this one. I tried out the text on a Python class that I'm currently teaching and the learners found the text to be clear enough (though some were jarred by the choice of *L* as the variable name) and they all got the essential points (the default variable is evaluated once and what they should do if you don't want the default value to be shared between subsequent calls). ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 03:38:26 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 Apr 2016 07:38:26 +0000 Subject: [docs] [issue26512] Vocabulary: Using "integral" in library/stdtypes.html In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za> Message-ID: <1461656306.39.0.469449051179.issue26512@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a v3 patch for Python 3, addressing everyone?s comments: Fix the leftover table markup Link math.trunc(x) etc syntax to the main documentation Hide numbers module prefix from Integral class name Change ?integral float? ? ~numbers.Integral Add emphasis for *n* parameter Change int ? Integral in doc strings ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file42593/stdtypes-integral.v3.py3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 03:38:58 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 Apr 2016 07:38:58 +0000 Subject: [docs] [issue26512] Vocabulary: Using "integral" in library/stdtypes.html In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za> Message-ID: <1461656338.2.0.612019550396.issue26512@psf.upfronthosting.co.za> Changes by Martin Panter : Removed file: http://bugs.python.org/file42593/stdtypes-integral.v3.py3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 03:39:20 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 Apr 2016 07:39:20 +0000 Subject: [docs] [issue26512] Vocabulary: Using "integral" in library/stdtypes.html In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za> Message-ID: <1461656360.18.0.914016080807.issue26512@psf.upfronthosting.co.za> Changes by Martin Panter : Added file: http://bugs.python.org/file42594/stdtypes-integral.v3.py3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 03:59:24 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 26 Apr 2016 07:59:24 +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: <20160426075921.13107.99784.5C1FD5D0@psf.io> Roundup Robot added the comment: New changeset aba647a34ed4 by Raymond Hettinger in branch '2.7': Issue #23986: Note that the in-operator for lists and tuples check identity before equality. https://hg.python.org/cpython/rev/aba647a34ed4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 04:00:31 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 26 Apr 2016 08:00:31 +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: <1461657631.44.0.661448376342.issue23986@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 04:09:48 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 26 Apr 2016 08:09:48 +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: <20160426080937.122104.30523.AC2AA1BC@psf.io> Roundup Robot added the comment: New changeset ba87f7f246e0 by Raymond Hettinger in branch '2.7': Issue #24715: Improve sort stability example https://hg.python.org/cpython/rev/ba87f7f246e0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 04:11:35 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 26 Apr 2016 08:11:35 +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: <20160426081134.27739.76276.87980355@psf.io> Roundup Robot added the comment: New changeset ae1e55102449 by Raymond Hettinger in branch '3.5': Issue #24715: Improve sort stability example https://hg.python.org/cpython/rev/ae1e55102449 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 04:11:50 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 26 Apr 2016 08:11: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: <1461658310.37.0.462851791623.issue24715@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 04:21:59 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 Apr 2016 08:21:59 +0000 Subject: [docs] [issue26512] Vocabulary: Using "integral" in library/stdtypes.html In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za> Message-ID: <1461658919.3.0.394551032458.issue26512@psf.upfronthosting.co.za> Martin Panter added the comment: Here is the Python 2 version. The difference is that floor() and ceil() return an ?integer as a float?, and I didn?t touch the doc strings. ---------- Added file: http://bugs.python.org/file42595/stdtypes-integral.v3.py2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 04:22:05 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 26 Apr 2016 08:22:05 +0000 Subject: [docs] [issue24296] Queue documentation note needed In-Reply-To: <1432729321.3.0.0746320695027.issue24296@psf.upfronthosting.co.za> Message-ID: <1461658925.25.0.00515447528402.issue24296@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 04:24:10 2016 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 26 Apr 2016 08:24:10 +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: <1461659050.52.0.54212351116.issue26020@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 05:29:53 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 26 Apr 2016 09:29:53 +0000 Subject: [docs] [issue26512] Vocabulary: Using "integral" in library/stdtypes.html In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za> Message-ID: <1461662993.54.0.644387397924.issue26512@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 07:48:55 2016 From: report at bugs.python.org (Roundup Robot) Date: Tue, 26 Apr 2016 11:48:55 +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: <20160426114848.102814.72058.B5771199@psf.io> Roundup Robot added the comment: New changeset 44f888e47ab0 by Martin Panter in branch '2.7': Issue #20598: Replace trivial split() calls with lists in argparse docs https://hg.python.org/cpython/rev/44f888e47ab0 New changeset 49561532504c by Martin Panter in branch '3.5': Issue #20598: Replace trivial split() calls with lists in argparse docs https://hg.python.org/cpython/rev/49561532504c New changeset 14cb17682831 by Martin Panter in branch 'default': Issue #20598: Merge argparse docs from 3.5 https://hg.python.org/cpython/rev/14cb17682831 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 08:44:12 2016 From: report at bugs.python.org (Martin Panter) Date: Tue, 26 Apr 2016 12:44:12 +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: <1461674651.97.0.521002618315.issue20598@psf.upfronthosting.co.za> Martin Panter added the comment: I committed my simpler patch. I hope that is okay :) ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 09:06:41 2016 From: report at bugs.python.org (Luke) Date: Tue, 26 Apr 2016 13:06:41 +0000 Subject: [docs] [issue26847] filter docs unclear wording In-Reply-To: <1461640540.65.0.428299683802.issue26847@psf.upfronthosting.co.za> Message-ID: <1461676001.96.0.536468219812.issue26847@psf.upfronthosting.co.za> Luke added the comment: For shame! ... I deserved that callout. :S My examples should have included the cast to bool, which is indeed not the same as the values' being "equal to False" in themselves... I didn't realize that "is false" was conventional shorthand for that cast and comparison. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 09:40:10 2016 From: report at bugs.python.org (STINNER Victor) Date: Tue, 26 Apr 2016 13:40:10 +0000 Subject: [docs] [issue20598] argparse docs: '7'.split() is confusing magic In-Reply-To: <1461674651.97.0.521002618315.issue20598@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Thanks. The doc looks better like that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 10:03:45 2016 From: report at bugs.python.org (Berker Peksag) Date: Tue, 26 Apr 2016 14:03:45 +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: <1461679425.62.0.117206300433.issue20598@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 11:26:58 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Apr 2016 15:26:58 +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: <1461684418.12.0.798284505875.issue26020@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- components: +Interpreter Core -Documentation nosy: +serhiy.storchaka stage: patch review -> commit review type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 11:30:26 2016 From: report at bugs.python.org (Neil Girdhar) Date: Tue, 26 Apr 2016 15:30:26 +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: <1461684626.92.0.571517259737.issue26020@psf.upfronthosting.co.za> Neil Girdhar added the comment: Please don't forget to fix BUILD_SET_UNPACK to match. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 11:32:21 2016 From: report at bugs.python.org (Neil Girdhar) Date: Tue, 26 Apr 2016 15:32:21 +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: <1461684741.85.0.906176844514.issue26020@psf.upfronthosting.co.za> Neil Girdhar added the comment: Also, please add the following test: "{*{True, 1}}" Should be True. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 11:41:10 2016 From: report at bugs.python.org (Xiang Zhang) Date: Tue, 26 Apr 2016 15:41:10 +0000 Subject: [docs] [issue26864] urllib.request no_proxy check differs from curl In-Reply-To: <1461681827.76.0.743158989172.issue26864@psf.upfronthosting.co.za> Message-ID: <1461685270.52.0.37127486693.issue26864@psf.upfronthosting.co.za> Xiang Zhang added the comment: No, urllib.request does not handle the no_proxy environment in case-sensitive way. It first checks if any environment_variable.lower() ends with "_proxy", and then checks if there is any environment_variable ends with "_proxy". So it works as a case insensitive check, but the lowercase one will override others, e.g, no_proxy overrides no_PROXY. But the document is misleading, it should be clarified. ---------- assignee: -> docs at python components: +Documentation -Library (Lib) nosy: +docs at python, martin.panter, xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 11:54:52 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 26 Apr 2016 15:54:52 +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: <1461686092.42.0.614096598464.issue26020@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Please don't forget to fix BUILD_SET_UNPACK to match. Isn't it already correct? > Also, please add the following test: "{*{True, 1}}" Did you meant "{*{True}, *{1}}"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 11:55:08 2016 From: report at bugs.python.org (Daniel Morrison) Date: Tue, 26 Apr 2016 15:55:08 +0000 Subject: [docs] [issue26864] urllib.request no_proxy check differs from curl In-Reply-To: <1461681827.76.0.743158989172.issue26864@psf.upfronthosting.co.za> Message-ID: <1461686108.65.0.576943769263.issue26864@psf.upfronthosting.co.za> Daniel Morrison added the comment: I believe there was a misunderstanding. While the environment variable name is handled in a case insensitive way, the contents of the environment variable is not. Please see some examples below: >>> os.environ['no_proxy'] = 'example.com' >>> urllib.request.proxy_bypass('EXAMPLE.com') 0 >>> urllib.request.proxy_bypass('example.com') 1 Also to clarify the meaning of suffix check: >>> os.environ['no_proxy'] = 'example.com' >>> urllib.request.proxy_bypass('myexample.com') 1 My apologies for my lack of clarity. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 11:58:48 2016 From: report at bugs.python.org (Neil Girdhar) Date: Tue, 26 Apr 2016 15:58:48 +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: <1461686328.76.0.747789572679.issue26020@psf.upfronthosting.co.za> Neil Girdhar added the comment: Ah, sorry, I somehow went cross-eyed. Not sure offhand which test would test the BUILD_TUPLE_UNPACK, but I think you're right Serhiy. Could just add both? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 26 22:36:58 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 27 Apr 2016 02:36:58 +0000 Subject: [docs] [issue24147] Dialect class defaults are not documented. In-Reply-To: <1431133519.25.0.806037285537.issue24147@psf.upfronthosting.co.za> Message-ID: <1461724618.28.0.960808459038.issue24147@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 27 01:57:58 2016 From: report at bugs.python.org (Roundup Robot) Date: Wed, 27 Apr 2016 05:57:58 +0000 Subject: [docs] [issue26672] regrtest missing in the module name In-Reply-To: <1459336751.45.0.914074281653.issue26672@psf.upfronthosting.co.za> Message-ID: <20160427055754.12160.27455.3E95B921@psf.io> Roundup Robot added the comment: New changeset 2ef61a4747eb by Berker Peksag in branch '2.7': Issue #26672: Fix regrtest example in test.rst https://hg.python.org/cpython/rev/2ef61a4747eb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 27 01:58:37 2016 From: report at bugs.python.org (Berker Peksag) Date: Wed, 27 Apr 2016 05:58:37 +0000 Subject: [docs] [issue26672] regrtest missing in the module name In-Reply-To: <1459336751.45.0.914074281653.issue26672@psf.upfronthosting.co.za> Message-ID: <1461736717.65.0.787984646525.issue26672@psf.upfronthosting.co.za> Berker Peksag added the comment: Good catch, thanks for the report! ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 27 03:47:47 2016 From: report at bugs.python.org (Thomas Guettler) Date: Wed, 27 Apr 2016 07:47:47 +0000 Subject: [docs] [issue26869] unittest longMessage docs Message-ID: <1461743267.94.0.620093650485.issue26869@psf.upfronthosting.co.za> New submission from Thomas Guettler: The first message of the longMessage docs is confusing: https://docs.python.org/3/library/unittest.html#unittest.TestCase.longMessage > If set to True then .... This reads between the lines, that the default is False. But that was long ago in Python2. In Python3 the default is True (which I prefer to the old default). I think the docs should be like. And the term "normal message" is not defined. For new comers the "normal message" is what I get if you don't change the default, not the behaviour of the Python2 version :-) I think "normal message" should be replaced with "short message" or "diff message" .. I am unsure. What do you think? ---------- assignee: docs at python components: Documentation messages: 264359 nosy: docs at python, guettli priority: normal severity: normal status: open title: unittest longMessage docs versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From vadmium+py at gmail.com Tue Apr 26 03:40:37 2016 From: vadmium+py at gmail.com (vadmium+py at gmail.com) Date: Tue, 26 Apr 2016 07:40:37 -0000 Subject: [docs] Vocabulary: Using "integral" in library/stdtypes.html (issue 26512) Message-ID: <20160426074037.439.40864@psf.upfronthosting.co.za> https://bugs.python.org/review/26512/diff/16736/Doc/library/stdtypes.rst File Doc/library/stdtypes.rst (right): https://bugs.python.org/review/26512/diff/16736/Doc/library/stdtypes.rst#newcode364 Doc/library/stdtypes.rst:364: +--------------------+------------------------------------+--------+ On 2016/03/14 08:44:32, storchaka wrote: > Remained pluses are not needed. May be this is error. Done. https://bugs.python.org/review/26512/diff/16736/Doc/library/stdtypes.rst#newcode367 Doc/library/stdtypes.rst:367: | ``math.trunc(x)`` | *x* truncated to :class:`numbers.Integral` | On 2016/03/14 08:44:32, storchaka wrote: > I would write :class:`~numbers.Integral`. Done. https://bugs.python.org/review/26512/diff/16736/Doc/library/stdtypes.rst#newcode367 Doc/library/stdtypes.rst:367: | ``math.trunc(x)`` | *x* truncated to :class:`numbers.Integral` | On 2016/03/14 08:47:40, Georg wrote: > :func:`math.trunc(x) ` Done. https://bugs.python.org/review/26512/diff/16736/Doc/library/stdtypes.rst#newcode369 Doc/library/stdtypes.rst:369: | ``round(x[, n])`` | *x* rounded to n digits, | On 2016/03/14 08:44:32, storchaka wrote: > "n" should be emphasized as well as "x": *n*. Done. https://bugs.python.org/review/26512/diff/16736/Doc/library/stdtypes.rst#newcode373 Doc/library/stdtypes.rst:373: | ``math.floor(x)`` | the greatest integral float <= *x* | On 2016/03/14 22:29:25, vadmium wrote: > the greatest :class:`numbers.Integral` <= *x* Done. https://bugs.python.org/review/26512/ From report at bugs.python.org Wed Apr 27 13:35:15 2016 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 27 Apr 2016 17:35:15 +0000 Subject: [docs] [issue26869] unittest longMessage docs In-Reply-To: <1461743267.94.0.620093650485.issue26869@psf.upfronthosting.co.za> Message-ID: <1461778515.48.0.691545531762.issue26869@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Replace existing description with "This class attribute determines what happens when a custom failure message is passed as the msg argument to an assertXYY call that fails. If True, the default, the custom message is appended to the end of the standard failure message. If False, the custom message replaces the standard message. The standard failure message for each *assert method* contains useful information about the objects involved. For example the message from assertEqual shows the repr of the two unequal objects. It is usually easier to augment rather than replace this message The class setting can be overridden in individual test methods by assigning an instance attribute, self.longMessage, to True or False before calling the assert methods. New in version 3.1." ---------- nosy: +terry.reedy stage: -> needs patch type: -> behavior versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 28 00:36:54 2016 From: report at bugs.python.org (Luiz Poleto) Date: Thu, 28 Apr 2016 04:36:54 +0000 Subject: [docs] [issue25461] Unclear language (the word ineffective) in the documentation for os.walk In-Reply-To: <1445533538.52.0.421272081658.issue25461@psf.upfronthosting.co.za> Message-ID: <1461818214.34.0.761660337546.issue25461@psf.upfronthosting.co.za> Luiz Poleto added the comment: The change to os.rst is already committed so I modified the patch to remove it and keep only the change to os.py, which looks good and ready to be committed. ---------- Added file: http://bugs.python.org/file42635/issue25461.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 28 05:20:06 2016 From: report at bugs.python.org (Thomas Guettler) Date: Thu, 28 Apr 2016 09:20:06 +0000 Subject: [docs] [issue26869] unittest longMessage docs In-Reply-To: <1461743267.94.0.620093650485.issue26869@psf.upfronthosting.co.za> Message-ID: <1461835206.18.0.408362693717.issue26869@psf.upfronthosting.co.za> Thomas Guettler added the comment: Thank you for understanding my concern. > The standard failure message for each *assert method* contains useful > information about the objects involved. For example the message from > assertEqual shows the repr of the two unequal objects. It is usually > easier to augment rather than replace this message I think above is not needed. > The class setting can be overridden in individual test methods by > assigning an instance attribute, self.longMessage, to True or False > before calling the assert methods. I would add "the default value of the class gets reset before each test call". That is more explicit (I hope my text is what happens behind the scene) Again, thank you, that you care. Regards, Thomas G?ttler ---------- _______________________________________ Python tracker _______________________________________ From saul.spatz at gmail.com Thu Apr 28 11:11:42 2016 From: saul.spatz at gmail.com (Saul Spatz) Date: Thu, 28 Apr 2016 10:11:42 -0500 Subject: [docs] Python 3.5.1 Documentation Bug In-Reply-To: References: Message-ID: Hi Zachary, I learned the hard way that the current documentation, while correct, is incomplete. I think it should say something like, "If the directory already exists, FileExistsError is raised; if some previous element on the path does not, FileNotFoundError is raised." Saul On Mon, Apr 25, 2016 at 9:46 AM, Saul Spatz wrote: > Hi Zachary, > > Thanks for the clarification. I should have realized you have to call the > constructors in isinstance. > > Saul > > > On Mon, Apr 25, 2016 at 9:29 AM, Zachary Ware < > zachary.ware+pydocs at gmail.com> wrote: > >> Hi Saul, >> >> On Mon, Apr 25, 2016 at 9:14 AM, Saul Spatz wrote: >> > Hi, >> > >> > In the documentation for os.mkdir, it says, "If the directory already >> > exists, OSError is raised." On my Mac at least, FileExistsError is >> raised >> > and isinstance(FileExistsError, OSError) returns False. >> >> You are correct that it should say FileExistsError instead of OSError, >> and has now been fixed. However, FileExistsError is a subclass of >> OSError, so catching OSError would work. Try either >> `issubclass(FileExistsError, OSError)` or >> `isinstance(FileExistsError(), OSError())`. >> >> Thanks for the report! >> -- >> Zach >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From report at bugs.python.org Thu Apr 28 12:08:50 2016 From: report at bugs.python.org (mbarao) Date: Thu, 28 Apr 2016 16:08:50 +0000 Subject: [docs] [issue26874] Docstring error in divmod function Message-ID: <1461859730.5.0.461826994455.issue26874@psf.upfronthosting.co.za> New submission from mbarao: The documentation of the divmod function says that a tuple ((x-x%y)/y, x%y) is returned, but this is not correct anymore for python3. I think it should be ((x-x%y)//y, x%y) where an integer division is used. ---------- assignee: docs at python components: Documentation messages: 264434 nosy: docs at python, mbarao priority: normal severity: normal status: open title: Docstring error in divmod function type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 28 12:31:46 2016 From: report at bugs.python.org (Emanuel Barry) Date: Thu, 28 Apr 2016 16:31:46 +0000 Subject: [docs] [issue26874] Docstring error in divmod function In-Reply-To: <1461859730.5.0.461826994455.issue26874@psf.upfronthosting.co.za> Message-ID: <1461861106.38.0.024756295167.issue26874@psf.upfronthosting.co.za> Emanuel Barry added the comment: The documentation looks fine to me. Are you seeing any other place that I'm missing? https://docs.python.org/3/library/functions.html#divmod ---------- nosy: +ebarry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 28 12:56:43 2016 From: report at bugs.python.org (mbarao) Date: Thu, 28 Apr 2016 16:56:43 +0000 Subject: [docs] [issue26874] Docstring error in divmod function In-Reply-To: <1461859730.5.0.461826994455.issue26874@psf.upfronthosting.co.za> Message-ID: <1461862603.77.0.422286926602.issue26874@psf.upfronthosting.co.za> mbarao added the comment: See divmod.__doc__ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 28 13:37:13 2016 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 28 Apr 2016 17:37:13 +0000 Subject: [docs] [issue26875] mmap doc gives wrong code example Message-ID: <1461865033.17.0.77697230941.issue26875@psf.upfronthosting.co.za> New submission from Xiang Zhang: The code given in mmap doc import mmap with mmap.mmap(-1, 13) as mm: mm.write("Hello world!") should be mm.write(b"Hello world!") The *b* is left out and then causes exception. ---------- assignee: docs at python components: Documentation files: mmap_doc.patch keywords: patch messages: 264438 nosy: docs at python, xiang.zhang priority: normal severity: normal status: open title: mmap doc gives wrong code example Added file: http://bugs.python.org/file42641/mmap_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 28 14:01:37 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 28 Apr 2016 18:01:37 +0000 Subject: [docs] [issue26874] Docstring error in divmod function In-Reply-To: <1461859730.5.0.461826994455.issue26874@psf.upfronthosting.co.za> Message-ID: <1461866497.23.0.763692365119.issue26874@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +eric.smith, lemburg, mark.dickinson, stutzbach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 28 15:10:40 2016 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 28 Apr 2016 19:10:40 +0000 Subject: [docs] [issue26874] Docstring error in divmod function In-Reply-To: <1461859730.5.0.461826994455.issue26874@psf.upfronthosting.co.za> Message-ID: <1461870640.55.0.0273510348993.issue26874@psf.upfronthosting.co.za> Mark Dickinson added the comment: > I think it should be ((x-x%y)//y, x%y) where an integer division is used. How about simply (x//y, x%y)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 28 15:26:39 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 Apr 2016 19:26:39 +0000 Subject: [docs] [issue26874] Docstring error in divmod function In-Reply-To: <1461859730.5.0.461826994455.issue26874@psf.upfronthosting.co.za> Message-ID: <20160428192556.35283.66504.EEACDF45@psf.io> Roundup Robot added the comment: New changeset fb49082a75d1 by Zachary Ware in branch '2.7': Issue #26874: Make divmod docstring and full doc match https://hg.python.org/cpython/rev/fb49082a75d1 New changeset ef193be5c3cd by Zachary Ware in branch '3.5': Issue #26874: Fix divmod docstring https://hg.python.org/cpython/rev/ef193be5c3cd New changeset 28c89ebd6e5a by Zachary Ware in branch 'default': Closes #26874: Merge with 3.5 https://hg.python.org/cpython/rev/28c89ebd6e5a ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 28 15:28:45 2016 From: report at bugs.python.org (Zachary Ware) Date: Thu, 28 Apr 2016 19:28:45 +0000 Subject: [docs] [issue26874] Docstring error in divmod function In-Reply-To: <1461859730.5.0.461826994455.issue26874@psf.upfronthosting.co.za> Message-ID: <1461871725.2.0.229596921831.issue26874@psf.upfronthosting.co.za> Zachary Ware added the comment: If only I had reloaded the page before pushing... Btw, this was first reported in issue1209411, but only the docs were changed, not the docstring. ---------- nosy: +zach.ware resolution: fixed -> stage: resolved -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 28 15:40:47 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 Apr 2016 19:40:47 +0000 Subject: [docs] [issue26874] Docstring error in divmod function In-Reply-To: <1461859730.5.0.461826994455.issue26874@psf.upfronthosting.co.za> Message-ID: <20160428194036.18199.94644.D0CDA0DD@psf.io> Roundup Robot added the comment: New changeset 5a578ec4b3b3 by Zachary Ware in branch '2.7': Issue #26874: Simplify the divmod docstring. https://hg.python.org/cpython/rev/5a578ec4b3b3 New changeset 3edf8aa1ed97 by Zachary Ware in branch '3.5': Issue #26874: Simplify the divmod docstring https://hg.python.org/cpython/rev/3edf8aa1ed97 New changeset c6e285789963 by Zachary Ware in branch 'default': Closes #26874: Merge with 3.5 https://hg.python.org/cpython/rev/c6e285789963 ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 28 15:48:00 2016 From: report at bugs.python.org (Roundup Robot) Date: Thu, 28 Apr 2016 19:48:00 +0000 Subject: [docs] [issue26875] mmap doc gives wrong code example In-Reply-To: <1461865033.17.0.77697230941.issue26875@psf.upfronthosting.co.za> Message-ID: <20160428194757.13860.23379.5F653F32@psf.io> Roundup Robot added the comment: New changeset 5c8e1b98dc3f by Zachary Ware in branch '3.5': Issue #26875: Fix mmap example https://hg.python.org/cpython/rev/5c8e1b98dc3f New changeset aaf2ad84ae1c by Zachary Ware in branch 'default': Closes #26875: Merge with 3.5 https://hg.python.org/cpython/rev/aaf2ad84ae1c ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 28 15:48:43 2016 From: report at bugs.python.org (Zachary Ware) Date: Thu, 28 Apr 2016 19:48:43 +0000 Subject: [docs] [issue26875] mmap doc gives wrong code example In-Reply-To: <1461865033.17.0.77697230941.issue26875@psf.upfronthosting.co.za> Message-ID: <1461872923.16.0.496214651116.issue26875@psf.upfronthosting.co.za> Zachary Ware added the comment: Thanks for the report and patch! ---------- nosy: +zach.ware versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From konick781 at gmail.com Thu Apr 28 15:31:56 2016 From: konick781 at gmail.com (Timothy Konick) Date: Thu, 28 Apr 2016 15:31:56 -0400 Subject: [docs] Function and methods example error Message-ID: While studying python descriptors, I started reading: https://docs.python.org/3/howto/descriptor.html and noticed that the example is hasn't been updated since removing the "unbound methods" I think a small mention of this change and slight adjustment to the example maybe, include the mention from the NEWS.txt ( http://svn.python.org/projects/python/branches/py3k-importlib/Misc/NEWS) -------------- next part -------------- An HTML attachment was scrubbed... URL: From report at bugs.python.org Fri Apr 29 00:28:32 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 29 Apr 2016 04:28:32 +0000 Subject: [docs] [issue23453] Clarify bytes vs text with non-seeking tarfile stream In-Reply-To: <1423739998.49.0.706967373594.issue23453@psf.upfronthosting.co.za> Message-ID: <1461904112.82.0.793841250329.issue23453@psf.upfronthosting.co.za> Martin Panter added the comment: Looks like the _Stream docstring needs a similar fix regarding stdin and stdout. Also, it wouldn?t hurt to specify that the read() and write() methods should work with bytes, not text. ---------- title: Opening a stream with tarfile.open() triggers a TypeError: can't concat bytes to str error -> Clarify bytes vs text with non-seeking tarfile stream versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 29 00:53:15 2016 From: report at bugs.python.org (Martin Panter) Date: Fri, 29 Apr 2016 04:53:15 +0000 Subject: [docs] [issue10436] tarfile.extractfile in "r|" stream mode fails with filenames or members from getmembers() In-Reply-To: <1289931464.79.0.618120236196.issue10436@psf.upfronthosting.co.za> Message-ID: <1461905595.86.0.859600494704.issue10436@psf.upfronthosting.co.za> Martin Panter added the comment: David, if you are still interested, I think specific suggestions or patches would be welcome (even if Lars assigned this to himself five years ago). I also like the idea of separate low-level and random access layers (I also thought of this). One other problem with the documentation of this mode is it points to the Examples section, but it is not obvious why. The only example specific to non-seeking mode was removed in r63411, apparently because it was obsolete: The _only_ way to extract an uncompressed tar stream from ?sys.stdin?: tar = tarfile.open(mode="r|", fileobj=sys.stdin) for tarinfo in tar: tar.extract(tarinfo) ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 29 06:53:26 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 29 Apr 2016 10:53:26 +0000 Subject: [docs] [issue8491] Need readline command and keybinding information In-Reply-To: <1271879913.89.0.268262009322.issue8491@psf.upfronthosting.co.za> Message-ID: <1461927206.61.0.991141557703.issue8491@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +easy nosy: +martin.panter stage: -> needs patch type: -> enhancement versions: +Python 3.5, Python 3.6 -Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 29 07:41:47 2016 From: report at bugs.python.org (Roundup Robot) Date: Fri, 29 Apr 2016 11:41:47 +0000 Subject: [docs] [issue26322] Missing docs for typing.Set In-Reply-To: <1455050900.92.0.506743123977.issue26322@psf.upfronthosting.co.za> Message-ID: <20160429114143.13924.8582.BE448266@psf.io> Roundup Robot added the comment: New changeset 6cd8cd14f648 by Berker Peksag in branch '3.5': Issue #26322: Document typing.Set, patch by Joseph Moran https://hg.python.org/cpython/rev/6cd8cd14f648 New changeset d263dcfd9bb6 by Berker Peksag in branch 'default': Issue #26322: Document typing.Set, patch by Joseph Moran https://hg.python.org/cpython/rev/d263dcfd9bb6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 29 07:42:18 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 29 Apr 2016 11:42:18 +0000 Subject: [docs] [issue26322] Missing docs for typing.Set In-Reply-To: <1455050900.92.0.506743123977.issue26322@psf.upfronthosting.co.za> Message-ID: <1461930138.45.0.814429189545.issue26322@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks, Joseph! ---------- nosy: +berker.peksag resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 29 13:04:44 2016 From: report at bugs.python.org (Berker Peksag) Date: Fri, 29 Apr 2016 17:04:44 +0000 Subject: [docs] =?utf-8?q?=5Bissue18956=5D_Document_useful_functions_in_?= =?utf-8?b?4oCYcHlkb2PigJkgbW9kdWxl?= In-Reply-To: <1378532336.08.0.216765249116.issue18956@psf.upfronthosting.co.za> Message-ID: <1461949484.73.0.295967064494.issue18956@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Make generally useful pydoc functions public _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 29 17:02:59 2016 From: report at bugs.python.org (Zachary Ware) Date: Fri, 29 Apr 2016 21:02:59 +0000 Subject: [docs] [issue26887] Erratum in https://docs.python.org/2.6/library/multiprocessing.html In-Reply-To: <1461963405.27.0.843692247406.issue26887@psf.upfronthosting.co.za> Message-ID: <1461963779.71.0.419062361555.issue26887@psf.upfronthosting.co.za> Zachary Ware added the comment: The documentation for 2.6 is no longer maintained (and neither is 2.6 itself, so we highly recommend upgrading to at least 2.7 if at all possible), and this has already been fixed in 2.7. Thanks for the report anyway! ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, zach.ware resolution: -> out of date stage: -> resolved status: open -> closed versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 29 17:39:27 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 29 Apr 2016 21:39:27 +0000 Subject: [docs] [issue26889] Improve Doc/library/xmlrpc.client.rst In-Reply-To: <1461965955.82.0.756722302068.issue26889@psf.upfronthosting.co.za> Message-ID: <1461965967.28.0.279759495385.issue26889@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> docs at python components: +Documentation -Extension Modules nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 30 11:36:40 2016 From: report at bugs.python.org (Roundup Robot) Date: Sat, 30 Apr 2016 15:36:40 +0000 Subject: [docs] [issue21746] urlparse.BaseResult no longer exists In-Reply-To: <1402650592.68.0.838750531809.issue21746@psf.upfronthosting.co.za> Message-ID: <20160430153637.17957.20765.E9CF166B@psf.io> Roundup Robot added the comment: New changeset 6d49a7330c99 by Berker Peksag in branch '2.7': Issue #21746: Remove BaseResult reference from urlparse documentation https://hg.python.org/cpython/rev/6d49a7330c99 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 30 11:37:55 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 30 Apr 2016 15:37:55 +0000 Subject: [docs] [issue21746] urlparse.BaseResult no longer exists In-Reply-To: <1402650592.68.0.838750531809.issue21746@psf.upfronthosting.co.za> Message-ID: <1462030675.66.0.975988926141.issue21746@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Matthew. Python 3 documentation has already been updated. ---------- resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From 280145668 at qq.com Sat Apr 30 11:35:00 2016 From: 280145668 at qq.com (=?utf-8?B?5qWg5a2X5pWw6KGl5LiB5Lmf?=) Date: Sat, 30 Apr 2016 23:35:00 +0800 Subject: [docs] A mistake in a code snippet in `Descriptor HowTo Guide`? Message-ID: class Cell(object): . . . def getvalue(self, obj): "Recalculate cell before returning value" self.recalc() return obj._value value = property(getvalue) the instance method `getvalue` with a positional argument `obj` can't be used as `property(getvalue)`. the code snippet is above https://docs.python.org/3.4/howto/descriptor.html#functions-and-methods. -------------- next part -------------- An HTML attachment was scrubbed... URL: From storchaka at gmail.com Sat Apr 30 13:06:03 2016 From: storchaka at gmail.com (storchaka at gmail.com) Date: Sat, 30 Apr 2016 17:06:03 -0000 Subject: [docs] Improve Doc/library/xmlrpc.client.rst (issue 26889) Message-ID: <20160430170603.31339.7508@psf.upfronthosting.co.za> Reviewers: , http://bugs.python.org/review/26889/diff/17111/Doc/library/xmlrpc.client.rst File Doc/library/xmlrpc.client.rst (right): http://bugs.python.org/review/26889/diff/17111/Doc/library/xmlrpc.client.rst#newcode53 Doc/library/xmlrpc.client.rst:53: all clients and servers; see http://ontosys.com/xml-rpc/extensions.php for a Note that this link is dead. Should we use the Wayback Machine (https://web.archive.org/web/20130120074804/http://ontosys.com/xml-rpc/extensions.php)? http://bugs.python.org/review/26889/diff/17111/Doc/library/xmlrpc.client.rst#newcode84 Doc/library/xmlrpc.client.rst:84: | Name | Meaning | May be name columns "XML-RPC type" and "Python type"? Please review this at http://bugs.python.org/review/26889/ Affected files: Doc/library/xmlrpc.client.rst From report at bugs.python.org Sat Apr 30 14:39:36 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 30 Apr 2016 18:39:36 +0000 Subject: [docs] [issue1944] Document PyUnicode_* API In-Reply-To: <1201415203.65.0.272410099804.issue1944@psf.upfronthosting.co.za> Message-ID: <1462041575.98.0.249774534991.issue1944@psf.upfronthosting.co.za> Berker Peksag added the comment: Remaining undocumented functions: >From this issue: PyUnicode_RSplit PyUnicode_Partition PyUnicode_RPartition >From issue 10435: PyUnicode_IsIdentifier PyUnicode_Append PyUnicode_AppendAndDel PyUnicode_GetDefaultEncoding PyUnicode_FromOrdinal PyUnicode_Resize PyUnicode_GetMax PyUnicode_InternImmortal PyUnicode_CHECK_INTERNED >From issue 18688: Py_UNICODE_REPLACEMENT_CHARACTER PyUnicodeIter_Type PyUnicode_AsDecodedObject PyUnicode_AsDecodedUnicode PyUnicode_AsEncodedObject PyUnicode_AsEncodedUnicode PyUnicode_BuildEncodingMap ---------- keywords: -easy nosy: +berker.peksag stage: -> needs patch title: Documentation for PyUnicode_AsString (et al.) missing. -> Document PyUnicode_* API versions: +Python 3.5, Python 3.6 -Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 30 14:40:02 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 30 Apr 2016 18:40:02 +0000 Subject: [docs] [issue18688] Document undocumented Unicode object API In-Reply-To: <1375989166.23.0.200448183394.issue18688@psf.upfronthosting.co.za> Message-ID: <1462041602.78.0.744901102573.issue18688@psf.upfronthosting.co.za> Berker Peksag added the comment: This is a duplicate of issue 1944. ---------- nosy: +berker.peksag resolution: -> duplicate stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 30 14:41:21 2016 From: report at bugs.python.org (Berker Peksag) Date: Sat, 30 Apr 2016 18:41:21 +0000 Subject: [docs] [issue18688] Document undocumented Unicode object API In-Reply-To: <1375989166.23.0.200448183394.issue18688@psf.upfronthosting.co.za> Message-ID: <1462041681.76.0.0982291687006.issue18688@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- superseder: -> Document PyUnicode_* API _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 30 15:38:01 2016 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 30 Apr 2016 19:38:01 +0000 Subject: [docs] [issue1944] Document PyUnicode_* API In-Reply-To: <1201415203.65.0.272410099804.issue1944@psf.upfronthosting.co.za> Message-ID: <1462045081.39.0.300027405538.issue1944@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: PyUnicode_DecodeCodePageStateful Following functions likely should be wrapped with "#ifndef Py_LIMITED_API": _PyUnicode_ClearStaticStrings _PyUnicode_EQ _PyUnicode_FromId ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________